Bug 234881 - Run from RAM ends up requiring crazy RAM if iso burned to a DVD
Run from RAM ends up requiring crazy RAM if iso burned to a DVD
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: LiveCD (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
David Lawrence
:
Depends On:
Blocks: Fedora7LiveCD
  Show dependency treegraph
 
Reported: 2007-04-02 14:29 EDT by Jeremy Katz
Modified: 2013-03-05 22:49 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-04 11:27:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2007-04-02 14:29:18 EDT
dd off of a DVD ends up dd'ing the entire 4+ gigs even if only 700-800 megs are
used for the filesystem.  This causes run from RAM to blow up with an OOM.
Comment 1 David Zeuthen 2007-04-02 14:40:38 EDT
Ideally we would write a small C program to dd the bits that also prints out
progress etc. 
Comment 2 David Zeuthen 2007-04-02 14:42:44 EDT
A simpler solution right now, however, is to use something like 

 SIZE=$((`cat /sys/block/sr0/size` * 2048))

Replace 2048 with 512 if the media is not a disc.
Comment 3 Jeremy Katz 2007-04-02 14:47:14 EDT
Ideally we wouldn't have to write anything and could just use standard utilities
and get progress :)  It'd be nice to have a cp with progress in a lot of cases,
really

But dd'ing (or even using a custom program) to go off of the block device is
somewhat fundamentally flawed.  The block device can actually have more data
than the filesystem due to cd writers padding out to the end of the device.  I
wonder if we'd be better off switching to just grabbing the filesystem image
(either squashfs.img or ext3fs.img) as those won't have that problem.  
Comment 4 David Zeuthen 2007-04-02 14:50:48 EDT
NUM_BLOCKS=$(cat /sys/$(udevinfo --query path --name=$CDROM_DEVICE)/size)

is even better I think. Back in the day this number wasn't exactly reliable
(especially when the media changed) although I think we're good now. HTH.
Comment 5 David Zeuthen 2007-04-02 14:52:38 EDT
(In reply to comment #3)
> I wonder if we'd be better off switching to just grabbing the filesystem image
> (either squashfs.img or ext3fs.img) as those won't have that problem.  

Yeah, copying squashfs.img to RAM sounds like a much better idea actually (you
don't want to copy ext3fs.img to RAM; it will require approx 3x times as much RAM).
Comment 6 Jeremy Katz 2007-04-02 14:55:56 EDT
(In reply to comment #5)
> (In reply to comment #3)
> > I wonder if we'd be better off switching to just grabbing the filesystem image
> > (either squashfs.img or ext3fs.img) as those won't have that problem.  
> 
> Yeah, copying squashfs.img to RAM sounds like a much better idea actually (you
> don't want to copy ext3fs.img to RAM; it will require approx 3x times as much
RAM).

ext3fs.img only in the case of it not being squashed.  Which shouldn't be
anything that anyone actually distributes I wouldn't think
Comment 7 David Zeuthen 2007-04-02 15:02:01 EDT
(In reply to comment #6)
> ext3fs.img only in the case of it not being squashed.  Which shouldn't be
> anything that anyone actually distributes I wouldn't think

Good point. We should support copying both to RAM then (with squashfs being
preferred to ext3fs).
Comment 8 David Zeuthen 2007-04-02 15:04:45 EDT
(In reply to comment #7)
> Good point. We should support copying both to RAM then (with squashfs being
> preferred to ext3fs).

(just to clarify; I'm not proposing more than _one_ "run to RAM" option here)

Comment 9 David Zeuthen 2007-04-02 15:49:21 EDT
Btw, if we do this (and I think we should), mayflower should make the OS export

 /dev/livecd_squashfs
 /dev/livecd_ext3fs

in addition to

 /dev/livecd

so the installer can pick this up; this is necessary to make the installer use
the in-RAM image when doing an install. Sounds good?
Comment 10 Jeremy Katz 2007-04-04 11:27:32 EDT
Implemented all of this

Note You need to log in before you can comment on or make changes to this bug.