Re: Top 10 bugs/warnings for the week of March 23rd, 2008

[Theodore Tso <tytso@mit.edu>]

On Mon, May 26, 2008 at 07:38:48PM +0200, Jan Kara wrote:
> > Looking at the filesystem UUID could help -- this is an ID that is
> > present as data on the disk, and that is even independent of the bus
> > type. See also /dev/disk/by-uuid.
>   Yes, but as Oliver wrote if someone modified the filesystem in the mean
> time, you won't notice it - UUID doesn't help here.

That part you could figure out in userspace, by looking at the last
mount and last modified time in the superblock.  But the problem is
it's too late.  If you had buffers which had been "in flight" at the
time when the USB stick was pulled, the kernel isn't going to be able
to send them to the new instantiation of the device for the freshly
installed USB stick.  And I don't think we want to put
filesystem-specific UUID and superblock parsing code in the generic
USB layer!

I suspect that if we want to do this, the only way would be with
massive amounts of userspace help, and with the dm layer interposing
between the filesystem and the device.  So when the USB stick gets
pulled, from the dm-multipath side it looks like the last I/O path has
been pulled, and it role-plays accordingly (with some kind of
intelligence where it holds dirty buffers for some reasonable amount
of time --- where reasonable is not easy to define) and then when
someone re-inserts a USB stick, userspace will have to figure out that
it was the same filesystem, and that it apparently hasn't been
tampered with, cross its fingers, and then associate the (possibly
different USB device) with the dm-multipath device.

If we have a super-bright student who needs humbling, it might make
for an interesting GSOC project.  :-)

						- Ted