Tugger the SLUGger!SLUG Mailing List Archives

Re: [SLUG] HOT SWAPPING - "Internals of the sync/umount call"

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? :)

Hi Adrian.

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 methodologies break. 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 to
is/was buggy,

Or you've been lucky!


FWIW, SATA devices are hot-swap and the are ... a little less than 8mm
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 various desktop-y SATA chipsets under FreeBSD/Linux and I found that they didn't all
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 compliant. 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.