Message-ID: <43F80A06.2090209@cfl.rr.com>
Date: Sun, 19 Feb 2006 01:02:46 -0500
From: Phillip Susi <psusi@cfl.rr.com>
User-Agent: Mail/News 1.5 (X11/20060119)
MIME-Version: 1.0
To: Andrew Morton <akpm@osdl.org>
CC: Alan Stern <stern@rowland.harvard.edu>, pavel@suse.cz, torvalds@osdl.org,
       mrmacman_g4@mac.com, alon.barlev@gmail.com,
       linux-kernel@vger.kernel.org, linux-pm@lists.osdl.org
Subject: Re: Flames over -- Re: Which is simpler?
References: <20060217210445.GR3490@openzaurus.ucw.cz> <Pine.LNX.4.44L0.0602181531290.4115-100000@netrider.rowland.org> <20060218160242.7d2b5754.akpm@osdl.org>
In-Reply-To: <20060218160242.7d2b5754.akpm@osdl.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1761
Lines: 42

Andrew Morton wrote:
> Correct me if I'm wrong, but this really only affects storage devices, yes?
> That narrows the scope of the problem quite some.
> 
> I suspect we could do a very good job of working out whether we're still
> talking to the same fs if filesystem drivers were to help in that.
> 

Exactly, which is why windows involves the filesystem driver.

> But I suspect we could do an even better job if we did that in userspace.
> 
> The logic to determine whether the new device is the same as the old device
> can be arbitrarily complex, with increasing levels of success.  Various
> heuristics can be applied, some of which will involve knowledge of
> filesystem layout, etc.
> 
> So would it not be possible to optionally punt the device naming decision
> up to the hotplug scripts?  So code up there can go do direct-IO reads of
> the newly-present blockdev, use filesytem layout knowledge, peek at UUIDs,
> superblocks, disk labels, partition tables, inode numbering, etc?  Go look
> up a database, work out what that filesystem was doing last time we saw it,
> etc?
> 
> We could of course add things to the filesystems to help this process, but
> it'd be good if all the state tracking and magic didn't have to be locked
> up in the kernel.


Hrm... interesting but sounds like that could be sticky.  For instance, 
what if the user script that does the verifying happens to be ON the 
volume to be verified?

I think this kind of thing is really going to have to be in kernel, like 
a remount.


-
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/