On Wed, Feb 10, 1999 at 04:03:02PM +0000, Stephen C. Tweedie wrote:
> Hi,
>=20
> On Wed, 10 Feb 1999 11:01:34 +0100, Kurt Garloff <K.Garloff@ping.de> said:
>=20
> > 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 ........ ......=
..
>=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. 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.
>=20
> 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.
>=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.
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.=20
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.=20
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.
=2E. which is why those work, I understand.
--=20
Kurt Garloff <kurt@garloff.de> [Dortmund, FRG]
Plasma physics, high perf. computing [Linux-ix86,-axp, DUX]
PGP key: see mailheader [Linux SCSI driver: DC390]
--ncSAzJYg3Aa9+CRW
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
iQCVAwUBNsIh3BaQN/7O/JIVAQHCzAP+NC0kJhR0c0iuHmEMEfs97Ql/aEKMigwv
1OYE4dXn8tbWK781IPSwJthAt/fTNZT12CeprGiFQtZobiWpwwlo0H/sc4QYokd5
t8xKO/fjX9julsjvL4qByDrc6y7TamOYIi9ahWev9zqWgcftwpFtDSUvVtFsgaER
+iCRPH5UhF8=
=vfqh
-----END PGP SIGNATURE-----
--ncSAzJYg3Aa9+CRW--
-
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/