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!
Whatever.
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.
Cheers.
Grahame
Adrian
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
