On Wed, 10 Feb 1999 11:01:34 +0100, Kurt Garloff <K.Garloff@ping.de> said:
> Hi everybody,
> I posted a similar report before and I was very astonished to see nobody
> answering.
> 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.
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.
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.
> Of course umounting does not help! The strange thing about it is, that this
> happens for msdos and vfat, but not for ext2 or minix.
ext2 and minix both keep the initial blocksize of 1024 bytes by default.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/