umounting

umounting

[Samuel Maftoul]

Hello people,
I use firewire devices and implements it for users at work.

I had to do some test and noticed a "bizarre" behaviour ( not really sure it is
):
User 1 is comming, He plugs his disk, mounts it and copy several datas.
Once finished, He unplug it without umounting it (what is bad, but
that's not the point).
User 2 comes, plugs his disk, tries to mount it but he can't because
it's already mounted. Without unplugging his disk, he umounts the
removed disk and then he tries mounting his one.
If user 1 had an ext2 disk, when user 2 umounts the filesystem with his
disk plugged his filesystem got broken ( tested with ext2 and vfat).
If user 1 had a vfat disk, then user 2 can cleanly umount the disk
without breaking any filesystem.
That's it.
Not sure whether it is an ext2, vfat or filesystem issue, or maybe not a
(kernel?)issue at all.
        Sam

Re: umounting

[Jan Ciger]

On Tuesday 22 January 2002 15:07, Samuel Maftoul wrote:
> If user 1 had an ext2 disk, when user 2 umounts the filesystem with his
> disk plugged his filesystem got broken ( tested with ext2 and vfat).
> If user 1 had a vfat disk, then user 2 can cleanly umount the disk
> without breaking any filesystem.

In general, when you unmount a filesystem, the system caches and data 
relevant for that filesystem are flushed to the disk. So if the first one 
leaves withou unmounting his disk, he can even have a corrupted fs himself, 
because some data didn't make it to the drive yet, there are just in caches. 

When a second user comes and unmounts a disk, then the data are flushed (the 
old data) and he gets a fs corruption, because the data were not from his 
disk. 

It is just matter of luck and it depends a lot on the buffering approach 
chosen by the fs developers - ext2 tends to cache a lot of things to improve 
performance and the disk flushes are not that frequent. If you manage to plug 
your drive in a wrong moment, then you end up with a mess. You can easily 
test this problem with floppies.

So, the solution is - teach your users to unmount disks before leaving, or 
mount them in synchronous mode - but I am not sure, whether VFAT supports 
that and it is a performance hog too. 

Jan

Re: umounting

[Oliver Neukum]

> When a second user comes and unmounts a disk, then the data are flushed
> (the old data) and he gets a fs corruption, because the data were not from
> his disk.

No. The sbp2 driver should report a disk change. If such a thing happens,
there's a kernel bug. Pulling out a mounted disk may cause a corrupted
filesystem on that disk but not on others.

	Regards
		Oliver

Re: umounting

[Jan Ciger]

On Tuesday 22 January 2002 20:01, you wrote:
> > When a second user comes and unmounts a disk, then the data are flushed
> > (the old data) and he gets a fs corruption, because the data were not
> > from his disk.
>
> No. The sbp2 driver should report a disk change. If such a thing happens,
> there's a kernel bug. Pulling out a mounted disk may cause a corrupted
> filesystem on that disk but not on others.

Maybe there is a problem in the driver, that it does not report the media 
change, but anyway, you WILL get a corrupted filesystem, when you unmount 
such disk with another media in drive - it is exactly like that - the driver 
didn't report the change and the filesystem layer thinks, that it has still 
the same media in drive and happily flushes e.g. ext2 data to a VFAT disk ... 
Then you get the corruption of the second disk. 

But I am not familiar with the sbp2 driver, but this is a quite standard 
behavior for removable media. 

Jan

Re: umounting

[Samuel Maftoul]

On Tue, Jan 22, 2002 at 08:01:44PM +0100, Oliver Neukum wrote:
> 
> > When a second user comes and unmounts a disk, then the data are flushed
> > (the old data) and he gets a fs corruption, because the data were not from
> > his disk.
> 
> No. The sbp2 driver should report a disk change. If such a thing happens,
According to my log, sbp2 has an event, It does see the new disk as I
can mount it ( something bizarre: The first disk I plug, the sbp2 driver
tells me the vendor and model of the disk, but all other disk won't tell
me anything until I realod sbp2 module ( I think reloading is ok but not
tested
> there's a kernel bug. Pulling out a mounted disk may cause a corrupted
> filesystem on that disk but not on others.
That's why I'm writing here: If a user broke his filesystem because he
forget to do umout, that's his fault but when a user do the right thing
but because the previous one haven't It brokes his fs, that's something
not normal and It should be avoided.
        Sam
> 
> 	Regards
> 		Oliver
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: umounting

[Oliver Neukum]

On Wednesday 23 January 2002 09:06, Samuel Maftoul wrote:
> On Tue, Jan 22, 2002 at 08:01:44PM +0100, Oliver Neukum wrote:
> > > When a second user comes and unmounts a disk, then the data are flushed
> > > (the old data) and he gets a fs corruption, because the data were not
> > > from his disk.
> >
> > No. The sbp2 driver should report a disk change. If such a thing happens,
>
> According to my log, sbp2 has an event, It does see the new disk as I
> can mount it ( something bizarre: The first disk I plug, the sbp2 driver
> tells me the vendor and model of the disk, but all other disk won't tell
> me anything until I realod sbp2 module ( I think reloading is ok but not
> tested

Do you use some kind of hotplugging script ?

	Regards
		Oliver

Re: umounting

[Samuel Maftoul]

On Wed, Jan 23, 2002 at 10:42:33PM +0100, Oliver Neukum wrote:
> On Wednesday 23 January 2002 09:06, Samuel Maftoul wrote:
> > On Tue, Jan 22, 2002 at 08:01:44PM +0100, Oliver Neukum wrote:
> > > > When a second user comes and unmounts a disk, then the data are flushed
> > > > (the old data) and he gets a fs corruption, because the data were not
> > > > from his disk.
> > >
> > > No. The sbp2 driver should report a disk change. If such a thing happens,
> >
> > According to my log, sbp2 has an event, It does see the new disk as I
> > can mount it ( something bizarre: The first disk I plug, the sbp2 driver
> > tells me the vendor and model of the disk, but all other disk won't tell
> > me anything until I realod sbp2 module ( I think reloading is ok but not
> > tested
> 
> Do you use some kind of hotplugging script ?
yes, I use suse 7.2 with updated modutils and kernel to 2.4.17 ( from
unofficial suse rpm produced by suse ) and I'm using suse7.3's hotplug
with ieee1394.agent that I got through the hotplug cvs server
maybe to chemical :)

I think that anyway we should prevent this happens if it's possible.
( I didn't lost any data since I tested with some spare disk ).

I can also put a umount in my ieee1394.agent, I thought about it and
probably will do it.
> 
> 	Regards
> 		Oliver

Re: umounting

[Xavier Bestel]

There was a suggestion some time ago (yeah I know, that was RMS) to have
a special mode for "surprise-removal" filesystems: when starting a write
operation on the device, always complete it such as if unmounted by
surprise, the fs is still valid.
This is not quite like a journaled fs I think, because it ought to work
with any fs (e.g. vfat because most if not all removable
disks/floppies/CF/flash-card-du-jour are formatted like this).

Well, I think this should be looked at.

Re: umounting

[Horst von Brand]

Jan Ciger <jan.ciger@epfl.ch> said:

[...]

> So, the solution is - teach your users to unmount disks before leaving, or 
> mount them in synchronous mode - but I am not sure, whether VFAT supports 
> that and it is a performance hog too. 

Better use mtools. No mounting required, which does screw DOSish minds.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: umounting

[Jan Ciger]

> > So, the solution is - teach your users to unmount disks before leaving,
> > or mount them in synchronous mode - but I am not sure, whether VFAT
> > supports that and it is a performance hog too.
>
> Better use mtools. No mounting required, which does screw DOSish minds.

I agree, but it probably does work only with floppies. 

Jan

Re: umounting

[Horst von Brand]

Jan Ciger <jan.ciger@epfl.ch> said:
> > > So, the solution is - teach your users to unmount disks before leaving,
> > > or mount them in synchronous mode - but I am not sure, whether VFAT
> > > supports that and it is a performance hog too.
> >
> > Better use mtools. No mounting required, which does screw DOSish minds.
> 
> I agree, but it probably does work only with floppies. 

Nope. It obviosly needs access (R/W) to the device/partition, and the right
configuration. I've used it with floppies and parallel Zip drives, and
sometime even with a loopback-mounted floppy image ;-)
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: umounting

[Jan Ciger]

> > I agree, but it probably does work only with floppies.
>
> Nope. It obviosly needs access (R/W) to the device/partition, and the right
> configuration. I've used it with floppies and parallel Zip drives, and
> sometime even with a loopback-mounted floppy image ;-)

Yeah, but you have to specify the format, and that is not that easy. It is a 
good way, how to screw your disks, when you do not know, what are you doing. 
I know, that it works with other things than floppies, but you have to have 
the format definition mentioned above. 

Jan