Re: Revoking filesystems [was Re: Sysfs attributes racing with unregistration]

[Eric W. Biederman]

Tejun Heo <tj@xxxxxxxxxx> writes:

> Hello,
>
> On Thu, Jan 05, 2012 at 10:13:31AM -0500, Alan Stern wrote:
>> I don't have a clear idea of what's involved (in particular, how to go
>> from a block_device structure to a mounted filesystem).  But the place
>> to do it would probably be block/genhd.c:invalidate_partition().  Ted
>> can tell you if there's a better alternative.
>> 
>> > Do you know how hard it is to detect at mount time if a block device
>> > might be hot-plugable?  We can always use a mount option here and
>> > make userspace figure it out, but being to have a good default would
>> > be nice.
>> 
>> I don't think it's possible to tell if a device is hot-unpluggable.  
>> For example, the device itself might not be removable from its parent, 
>> but the parent might be hot-unpluggable.  You'll probably have to 
>> assume that every device can potentially be unplugged, one way or 
>> another.
>> 
>> Also, even devices that aren't hot-unpluggable can fail.  The end 
>> result should be pretty much the same.
>
> Ummm.... I could be missing something but filesystems need to be able
> to deal with partial device failures (ie. some block can't be read)
> and hot-unplug or handling full failure is a logical extension of
> that.  That's how it already works, so I don't really think that is a
> particularly good application for the revoke mechanism.

Well the choices are really:
a) On a block device hotunplug keep the device and have it simply report
   everything as errors, to the filesystem.  Maybe with a hint to the
   filesystem that something is wrong.
b) Have a filesystem revoke method so that we don't have to keep the
   unplugged block device structure around indefinitely.

It seems clear that we are neither doing (a) or (b) which results in
periodic and spectacular failures when block devices are unplugged,
because we try and access block devices that no longer exist.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/