tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: "hot swap" storage devices
On Tue, Jun 28, 2011 at 4:35 AM, Erik Fair <fair%netbsd.org@localhost> wrote:
>
> On Jun 25, 2011, at 11:57 , Johnny Billquist wrote:
>
>> True. However, Unix have never really gracefully handled file systems or
>> devices that comes and goes. :-)
>
> As Robert Elz wrote (and I'll echo): UNIX has always handled removable
> devices - you just have to tell UNIX that you're going to remove it *before*
> you do (e.g. umount(8)). There is a reason why someone wrote fuser(8), long
> ago:
>
> http://miroirs.cesars.org/man/pages/SunOS-4.1.3/man8/fuser.8.txt
>
>
> With regard to "hot swap" storage devices, we really have two choices which
> are not mutually exclusive:
>
> 1. Treat as now, but with some additional code in the kernel which yells,
> "hey! put that back! I have data to write on it!" when a device goes away
> without prior notice (umount), and hold on to (rather than discard) the data
> in the I/O buffer cache, in the hope that the user notices and heeds the
> directive. Timeout to discard? Probably depends upon how much RAM utilization
> pressure you're under. I think "minutes" would be a good unit here.
>
> 2. Do all writes to "hot swap" devices synchronously - no write-behind cache
> at all, so that the device is most likely in a consistent state when it "goes
> away." Read cache would still be OK, but would have to be marked read-only
> upon device disappearance. Probably want to discard the read cache if the
> device is reinserted/reattached - you never know where the device has been
> the interim.
>
> I point out that this problem has been with us quite forcefully since Sun
> came up with NFS (oh, almost three decades ago), since networks and remote
> servers "go away" rather more randomly and frequently than the given attached
> hard disk.
It is admin's freedom how to design her/his system. If she/he decides
to use NFS for some important storage, and its connection is made so
reliable that connection loss is considered fatal, the system just
trust the NFS connection.
So I think it's only to provide a flag (command-line option) for
admins to tell systems if a given connection is considered trustable
or not.
>
> And how long has MacOS had an "eject" paradigm ... ?
>
> Erik <fair%netbsd.org@localhost>
>
>
Home |
Main Index |
Thread Index |
Old Index