Storage on Floppy

John Wildberger wildberger-iRg7kjdsKiH3fQ9qLvQP4Q at public.gmane.org
Wed Apr 14 21:57:57 UTC 2004


Thank you,Tim, for your detailed explanation. It might be a good read for all 
those  who suggested that the problem is in my system and not related to the 
nature of how data is stored. Answers like yours restores my faith into the 
real purpose of the TLUG: "Exploring Linux and helping each other to gain a 
better understanding."
John Wildberger

On Wednesday 14 April 2004 10:46 am, Tim Writer wrote:

> Time to clear this up.  The options sync, dirsync, etc. shouldn't have any
> effect on this behaviour.  Let me see if I can explain what's happening.
>
> I'm sure most users on this list are familiar with what happens when a
> filesystem runs out of inodes.  While df (without options) reports space is
> available, any attempt to create a file fails with an error message
> indicating the file system is full.  Using "df -i" tells you you're out of
> inodes, meaning there is space for the file data but no space for the
> directory entry or file name.
>
> This problem (the one that John is reporting) is the converse of the above
> problem.  Copying "large" files to the floppy has exhausted the data space
> but there's still inode space so he can create empty files until he runs
> out of inodes.
>
> Not convinced?  Try this test (as root).  Note, you don't need a floppy
> (USB or otherwise).
>
>     # Make a 1.44MB file
>     dd if=/dev/zero of=/var/tmp/xxx bs=1024 count=1440
>     # Put a DOS file system on it
>     mkdosfs /var/tmp/xxx
>     # Mount it
>     mount -t vfat -o loop /var/tmp/xxx /mnt
>     # Fill with 200kB files
>     for i in `seq 0 9`
>     do
>         dd if=/dev/hda of=/mnt/file$i bs=1024 count=200
>     done
>     # Take a look at what's there
>     ls -l /mnt
>     df /mnt
>     df -i /mnt
>     # Show that we can still create an empty file
>     touch /mnt/xxx
>
> This behaviour isn't specific to DOS file systems.  Repeat the above with
> mke2fs and you'll get the same behaviour.  Mounting with the sync and/or
> dirsync option makes no difference but note that dirsync is specific to
> msdos and vfat.
>
> For the nit pickers, the above discussion is somewhat simplified.  In
> truth, if the disk is full but inodes are available, you still might not be
> able to create an empty file because you need data space to store the file
> name. Since most (all?) file systems store file names within the data space
> of directories and most (all?) file systems pre-allocate data space in
> blocks, you will be able to create empty files until you run out of inodes
> or until you exhaust the data space of the target directory.

> I believe you but I'm having a harder time believing those who disagree
> with you.  Perhaps they are using a file manager or utility that removes
> any partially copied files.  I repeated the above tests using cp instead of
> dd in the for loop with the same result.
>
> Is this behaviour a bug?  I'd rather call it a quirk of the implementation
> and its right for you to point it out as it could bite new users.  It's
> reasonable for a good file manager to remove partially copied files but I
> wouldn't expect that from the command line utilities.
>
> As an aside, I generally discourage users from mounting floppies because,
> due to the lack of a software controllable lock (such as CDs have), it's
> too easy to cause data corruption or worse by ejecting a mounted floppy.  I
> prefer mtools.  Unfortunately, konqueror encourages users to mount floppies
> with its mountable icons and I suspect other file managers do the same.
> IMO, it would be better if file managers didn't mount removable media or
> only mounted it briefly, i.e. mount, retrieve a list of files, umount;
> mount, copy a file, umount; etc.  While this would cause some loss of
> performance, it would protect users from data corruption or worse.  And, at
> the risk of sounding condescending or elitist, those who make heavy use of
> file managers are more than likely the kind of users who need this type of
> protection.

--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list