SLUG Mailing List Archives
Re: [SLUG] HOT SWAPPING - "Internals of the sync/umount call"
- To: Adrian Chadd <adrian@xxxxxxxxxxxxxxx>, slug@xxxxxxxxxxx
- Subject: Re: [SLUG] HOT SWAPPING - "Internals of the sync/umount call"
- From: Grahame Kelly <grahame@xxxxxxxxxxxxxx>
- Date: Sun, 17 May 2009 11:04:33 +1000
On 16/05/2009, at 5:53 PM, Adrian Chadd wrote:
On Sat, May 16, 2009, Grahame Kelly wrote:
Rather than stating what I suspect is just a "belief", have you look
at the Kernel source code at all? If so I would be very interested at
exactly where you state such activity happens.
According to Linux Internals Doco (and hereijn I refer to the Linux
Drivers themselves) Once the device has been "un-mounted" the OS
warrants that the device, its linked control blocks, buffers etc.
are indeed-flushed and data secured on the device medium. The
applicable driver HAVE already unloaded any cache data before the
umount command returns with its resultant response.
And I assume that you 100% believe that when the drive says "YES SIR
I HAVE SYNCED" it has actually done this? :)
It is all part of the standards each industry strives for. SATA drive
manufactures validate and belong to the applicable standards groups
just for these reasons.
I am not disputing that some drives or controllers may not be
standards conforming (at times this is more than likely). If and only
if a drive, or/and its controller conform to such standards, then
whatever data stream needs to be written by the subsystem on the
completeion of a "sync" or in response to a "umount" is suppose to
ensure that such data is stored on the media either before the status
response is returned to the driving s/w or is warranted to have done
so. If this didn't happen then all hell would break loose (which is
what your saying).
I don't believe much if anything at all.
We both have discovered via our experiences when "things" don't work
a.k.a. don't conform to a standard - this is when structures or such
Under POSIX "umount" is suppose to warrant such for the device, its
controlling structures and associated kernel drive tables. If the
system(s) don't - then they simply are non-conforming implementations
- That is ALL.
I have never experienced this in all the years working with Linux.
Either you haven't un-mounted the device correctly (that is checked
the return status byte if in a script), or the OS release you refer
Or you've been lucky!
FWIW, SATA devices are hot-swap and the are ... a little less than
of coverage for those connections. Just sayin'
SATA I, II and forthcoming III specifications originally covered hot-
swapping. So it would be expected at the hardware level.
Its optional. And it is not always implemented correctly.
I have some notes somewhere from some previous experiments with
desktop-y SATA chipsets under FreeBSD/Linux and I found that they
do hotswap as advertised. ;)
Your correct to say "And it is not always implemented correctly" --
That is exactly what I am trying to show through this discussion.
It is your experiments that I and others are interested in.
We may together be able to:
A> narrow the problem down - and if it is a Linux or driver
implementation - make and forward a patch in making the OS better
B> If its a drive issue, advise the manufacture, or simply advise
others not to purchase same because of these issues.
C> Find a work-around - be it a operational, hardware or software one.
And advise others not just in SLUG but the wider Linux/FreeBSD world.
Thats my main point of this followup. Not an person to person
agreement - rather a technical follow up to narrow down and implement
a solution as I already have pointed out.
Keep tracking those problematic issues,
Set up a controlled test, document it and forward it to others so they
may test the same and return their results to you.