Messages in this thread | | | Date | Thu, 11 Feb 1999 01:18:36 +0100 | From | Kurt Garloff <> | Subject | Re: mount corrupts ramdisk |
| |
On Wed, Feb 10, 1999 at 04:03:02PM +0000, Stephen C. Tweedie wrote: > Hi, > > On Wed, 10 Feb 1999 11:01:34 +0100, Kurt Garloff <K.Garloff@ping.de> said: > > > However, if you have a look at /dev/ram2, you see that something's going > > wrong: > > 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ > > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ > > > THE MOUNT CALL HAS DESTROYED THE DATA IN /DEV/RAM2 !!! > > Yes. This is strictly speaking a cross between a bug and a feature. :) > > The buffer cache and block device layers in Linux maintain a current > blocksize for each block device. That blocksize is set when you mount a > filesystem, in order that the IO system can cache the filesystem's > accesses in units which make sense. > > That all works fine when you have got a persistant storage on disk which > can be reread when you change the buffer blocksize for a device: you > turf out the old buffers with the wrong size, and reread them on demand > using the new alignment. > > The ramdisk simply cannot cope with a request to change its block size. > All data is lost when this occurs.
.. which is a bug. As the ramdisk has no natural blocksize, it should either refuse to have it changed with an error message (without clearing the ramdisk), or -- better -- just do it. Shouldn't be too hard. Maybe, this would render the filesystem invalid, however, as the creator assumed another blocksize?
> What is really wrong here is that the ramdisk and filesystem are failing > to propogate this error back up to the users. Changing a ramdisk's > blocksize is simply not expected to preserve its data.
So, mount doesn't even see it?
> The real solution is to export a set-blocksize ioctl to user space so > that the correct blocksize can be set _before_ creating the initial > filesystem, and to make sure that the fat fs code doesn't accidentally > change the blocksize to something else while performing the initial > superblock read.
I still don't see, why the ramdisk is filled with zero. Data could be preserved. If mkfs.msdos would set the blocksize with an ioctl, the problems would not exist, that's true.
I feel still very uncomfortable thinking that a mount system call can destroy data.
You should be able to copy a floppy (image) to a ramdisk, mount and modify it and write it to a floppy/image again.
I also tried a loop device: Everything is OK, there.
> ext2 and minix both keep the initial blocksize of 1024 bytes by default.
.. which is why those work, I understand.
-- Kurt Garloff <kurt@garloff.de> [Dortmund, FRG] Plasma physics, high perf. computing [Linux-ix86,-axp, DUX] PGP key: see mailheader [Linux SCSI driver: DC390] [unhandled content-type:application/pgp-signature] | |