Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
On Sat, Sep 23, 2006 at 11:50:53PM +0100, [EMAIL PROTECTED] wrote: > Original Message > From: Rob Sims <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD" > Date: Fri, 22 Sep 2006 16:41:09 -0600 > >> I also have an empty directory: > >> poota:~# ls -l temp/ > >> total 0 > >> Then I mount the iso, loopback style: > >> mount image.iso temp/ -o loop > >What is the file system? Is it a compressed file system? Also, ls -l > >won't show you all files in temp; try ls -al, though that isn't the > >problem here. > Hi Rob. The filesystem that provides the mount point is ext3. As > for the iso file, "file" says that it's just "ISO 9660 CD-ROM > filesystem data. Once the iso is mounted (using loopack), > /proc/mounts says "/dev/loop0 /root/temp iso9660 ro 0 0" so I > assume the iso file really is just straight iso9660. Sounds like there may be some hard linked files. You won't be able to see that directly, but if you find some identical files, I'd suspect they share data space on the disc. mkisofs apparently will create such discs if it detects hard links on the source file system. -- Rob signature.asc Description: Digital signature
Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
Original Message
From: T <[EMAIL PROTECTED]>
Apparently from: [EMAIL PROTECTED]
To: debian-user@lists.debian.org
Subject: Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
Date: Fri, 22 Sep 2006 09:10:19 +0200
> On Fri, 22 Sep 2006 09:14:37 +0100, re2823 wrote:
>
> > I have a strange problem: I have an iso image file which (according to ls)
> > is 569M in size:
> >
> > ...
> >
> > Now for the problem...
> > The relevant line from "df -h":
> > poota:~# df -h
> > FilesystemSize Used Avail Use% Mounted on /root/image.iso
> > 569M 569M 0 100% /root/temp
> >
> > And the result from running "du -sh": poota:~# du -sh temp/
> > 1.1Gtemp/
> >
> > Just to really baffle me, I've burnt this iso image onto a 650MB CD-ROM,
> > mounted it, and it too has 1.1GB of data on it:
> >
> > poota:~# du -sh /media/cdrom0
> > 1.1G/media/cdrom0
> >
> > But the "df -h" output seems more reasonable: server:~# df -h
> > FilesystemSize Used Avail Use% Mounted on /dev/hdd
> > 569M 569M 0 100% /media/cdrom0
> >
> > Could anyone please tell me how there can be such a huge difference
> > between the output from df and du?
>
> Are you using some kind Live CD? This is actually quite normal for Live
> CDs.
>
No, sorry, no live CD. I'm running a plain-and-simple Debian
install (onto a hard-disk). The iso file "appears" to be a
standard ISO9660 data file ("file image.iso" says "ISO 9660
CD-ROM filesystem data" so I don't think it's anything special.
> > My real problem comes when I want to remove one small file from the file
> > system, and turn it back into an iso - the resulting iso image is 1.1GB
> > (and I can no longer write it to a CD!)
>
> It maybe helpful if you had indicated what CD you are using.
The CD that I'm using for this part is just a standard 70 min,
650MB blank cd-r.
They must
> be using some kind of compression. So,
Do you mean compression as in "zip, gzip, etc"? If so, I don't
see how that would make any difference to the size occupied by
the iso file and size of its contents. Surely 500MB of text files
takes up the same space as 500MB of gzip files - 500MB to be
precise!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
Original Message From: Rob Sims <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD" Date: Fri, 22 Sep 2006 16:41:09 -0600 >> I also have an empty directory: >> poota:~# ls -l temp/ >> total 0 >> >> Then I mount the iso, loopback style: >> mount image.iso temp/ -o loop >What is the file system? Is it a compressed file system? Also, ls -l >won't show you all files in temp; try ls -al, though that isn't the >problem here. Hi Rob. The filesystem that provides the mount point is ext3. As for the iso file, "file" says that it's just "ISO 9660 CD-ROM filesystem data. Once the iso is mounted (using loopack), /proc/mounts says "/dev/loop0 /root/temp iso9660 ro 0 0" so I assume the iso file really is just straight iso9660. Jaime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
On Fri, 22 Sep 2006 09:14:37 +0100, re2823 wrote: > I have a strange problem: I have an iso image file which (according to ls) > is 569M in size: > > ... > > Now for the problem... > The relevant line from "df -h": > poota:~# df -h > FilesystemSize Used Avail Use% Mounted on /root/image.iso > 569M 569M 0 100% /root/temp > > And the result from running "du -sh": poota:~# du -sh temp/ > 1.1Gtemp/ > > Just to really baffle me, I've burnt this iso image onto a 650MB CD-ROM, > mounted it, and it too has 1.1GB of data on it: > > poota:~# du -sh /media/cdrom0 > 1.1G/media/cdrom0 > > But the "df -h" output seems more reasonable: server:~# df -h > FilesystemSize Used Avail Use% Mounted on /dev/hdd > 569M 569M 0 100% /media/cdrom0 > > Could anyone please tell me how there can be such a huge difference > between the output from df and du? Are you using some kind Live CD? This is actually quite normal for Live CDs. > My real problem comes when I want to remove one small file from the file > system, and turn it back into an iso - the resulting iso image is 1.1GB > (and I can no longer write it to a CD!) It maybe helpful if you had indicated what CD you are using. They must be using some kind of compression. So, df count on file size reported by OS (HD/CD sectors), while du count on file sizes reported by themselves (byte count), thus, df reports compressed file sizes while du reports uncompressed file sizes. Check out the mkisofs -z option, for example. ,- | -z Generate special RRIP records for transparently compressed | files. This is only of use and interest for hosts that support | transparent decompression, such as Linux 2.4.14 or later. You | must specify the -R or -r options to enable RockRidge, and gen- | erate compressed files using the mkzftree utility before running | mkisofs. Note that transparent compression is a nonstandard | Rock Ridge extension. The resulting disks are only transpar- | ently readable if used on Linux. On other operating systems you | will need to call mkzftree by hand to decompress the files. `- Most Live CDs use other kind of compression, eg, squashfs. HTH tong -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
On Fri, Sep 22, 2006 at 09:14:37AM +0100, [EMAIL PROTECTED] wrote: > Hi all. > > I have a strange problem: I have an iso image file which > (according to ls) is 569M in size: > > poota:~# ls -lh image.iso > -rw-r--r-- 1 root root 569M 2006-09-12 15:12 image.iso > > I also have an empty directory: > poota:~# ls -l temp/ > total 0 > > Then I mount the iso, loopback style: > mount image.iso temp/ -o loop What is the file system? Is it a compressed file system? Also, ls -l won't show you all files in temp; try ls -al, though that isn't the problem here. -- Rob signature.asc Description: Digital signature
Re: df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
On 22.09.06 09:14, [EMAIL PROTECTED] wrote: > I have a strange problem: I have an iso image file which > (according to ls) is 569M in size: > > poota:~# ls -lh image.iso > -rw-r--r-- 1 root root 569M 2006-09-12 15:12 image.iso ... > Then I mount the iso, loopback style: > mount image.iso temp/ -o loop ... > The relevant line from "df -h": > poota:~# df -h > FilesystemSize Used Avail Use% Mounted on > /root/image.iso 569M 569M 0 100% /root/temp > > And the result from running "du -sh": > poota:~# du -sh temp/ > 1.1Gtemp/ ... > Could anyone please tell me how there can be such a huge > difference between the output from df and du? there probably is/are sparse files (containing much of empty space which was not used on the disk) > My real problem comes when I want to remove one small file from > the file system, and turn it back into an iso - the resulting iso > image is 1.1GB (and I can no longer write it to a CD!) you probably copied the rest of files elsewhere. Copy them with --sparse=always -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Remember half the people you know are below average. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
df and du disagree, or "How to get 1.1GB of data onto a 650MB CD"
Hi all. I have a strange problem: I have an iso image file which (according to ls) is 569M in size: poota:~# ls -lh image.iso -rw-r--r-- 1 root root 569M 2006-09-12 15:12 image.iso I also have an empty directory: poota:~# ls -l temp/ total 0 Then I mount the iso, loopback style: mount image.iso temp/ -o loop Now for the problem... The relevant line from "df -h": poota:~# df -h FilesystemSize Used Avail Use% Mounted on /root/image.iso 569M 569M 0 100% /root/temp And the result from running "du -sh": poota:~# du -sh temp/ 1.1Gtemp/ Just to really baffle me, I've burnt this iso image onto a 650MB CD-ROM, mounted it, and it too has 1.1GB of data on it: poota:~# du -sh /media/cdrom0 1.1G/media/cdrom0 But the "df -h" output seems more reasonable: server:~# df -h FilesystemSize Used Avail Use% Mounted on /dev/hdd 569M 569M 0 100% /media/cdrom0 Could anyone please tell me how there can be such a huge difference between the output from df and du? My real problem comes when I want to remove one small file from the file system, and turn it back into an iso - the resulting iso image is 1.1GB (and I can no longer write it to a CD!) Thanks, Jaime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
