Storage on Floppy

[Tim Writer]

John Wildberger <wildberger-iRg7kjdsKiH3fQ9qLvQP4Q at public.gmane.org> writes:

> On Tuesday 13 April 2004 02:56 pm, Sergey Kuznetsov wrote:
> 
> > mount -t vfat -o sync,dirsync /dev/sda /mnt/flash
> >
> > works for me. In this case you don't need to sync data, it always will be
> > synced.
> Reading the man mount page tells me that sync only works for ext2,ext3 and 
> ufs.

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.

> If I mount my floppy, as suggest above, with 
> "mount -t vfat -o sync,dirsync /dev/sda /mnt/floppy"
> then copying long files will spin my floppy forever. The only way to stop it 
> is by taking the floppy disk out of the drive. Inserting it again and using a 
> filemanager I can see that only the first two files were recorded. The second 
> one only partially.
> When I mount the floppy with "mount /dev/sda /mnt/floppy"
> the recording is more normal. After the fourth file I get error message 
> "No space left on the device" 
> This message is repeated for all the files left to copy. (6 files).
> Checking again with a file manager I see the first three files are being 
> recorded with its full content. The forth file is only partially recorded.
> (73kb out of 460kb).
> All 10 files show their full filename in the filemanager, with the last 6 
> files showing 0 content.
> The recorded floppy I can take out of the drive and insert it into another 
> computer and see that the directory shows all 10 files with their full 
> filename, but only the first four files have any content.
> 
> Now  those of you who call me a troll again for pointing this out  should go 
> ahead and have fun. 

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.

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
905.771.0017 ext. 225                           thornhill, ontario, canada
http://www.starnix.com              professional linux services & products
--
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