On Wed, Feb 10, 1999 at 04:03:02PM +0000, Stephen C. Tweedie wrote:
..
>=20
> > THE MOUNT CALL HAS DESTROYED THE DATA IN /DEV/RAM2 !!!
>=20
> Yes. This is strictly speaking a cross between a bug and a feature. :) =
=20
>=20
> The buffer cache and block device layers in Linux maintain a current
> blocksize for each block device.
>=20
> The ramdisk simply cannot cope with a request to change its block size.
> All data is lost when this occurs.
=2E. which is a bug.
> 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.
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.=20
I feel still very uncomfortable thinking that a mount system call can
destroy data.
Since you cc util-linux:
1) This is a bad kernel bug - silently destroying data is never a good idea.
2) You can avoid the problem by doing something like
mount -t msdos /dev/ram2 /mnt -o blocksize=1024
Andries
-
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/