On 11-Feb-09, at 5:52 PM, David Dyer-Bennet wrote:
On Wed, February 11, 2009 15:52, Bob Friesenhahn wrote:
On Wed, 11 Feb 2009, Tim wrote:
Right, except the OP stated he unmounted the filesystem in
question, and
it
was the *ONLY* one on the drive, meaning there is absolutely 0
chance of
their being pending writes. There's nothing to write to.
This is an interesting assumption leading to a wrong conclusion. If
the file is updated and the filesystem is "unmounted", it is still
possible for there to be uncommitted data in the pool. ...
As a practical matter, it seems unreasonable to me that there would be
uncommitted data in the pool after some quite short period of time ...
That is, if I plug in a memory stick with ZFS on it, read and write
for a
while, then when I'm done and IO appears to have quiesced, observe
that
the IO light on the drive is inactive for several seconds, I'd be
kinda
disappointed if I got actual corrution if I pulled it.
Absolutely. You should never get "actual corruption" (inconsistency)
at any time *except* in the case Jeff Bonwick explained: i.e. faulty/
misbehaving hardware! (That's one meaning of "always consistent on
disk".)
I think this is well understood, is it not?
Write barriers are not a new concept, and nor is the necessity. For
example, they are a clearly described feature of DEC's MSCP
protocol*, long before ATA or SCSI - presumably so that transactional
systems could actually be built at all. Devices were held to a high
standard of conformance since DEC's customers (like Sun's) were
traditionally those whose data was of very high value. Storage
engineers across the industry were certainly implementing them long
before MSCP.
--Toby
* - The related patent that I am looking at is #4,449,182, filed 5
Oct, 1981.
"Interface between a pair of processors, such as host and peripheral-
controlling processors in data processing systems."
Also the MSCP document released with the UDA50 mass storage
subsystem, dated April 1982:
"4.5 Command Categories and Execution Order
...
Sequential commands are those commands that, for the same unit, must
be executed in precise order. ... All sequential commands for a
particular unit that are received on the same connection must be
executed in the exact order that the MSCP server receives them. The
execution of a sequential command may not be interleaved with the
execution of any other sequential or non-sequential commands for the
same unit. Furthermore, any non-sequential commands received before
and on the same connection as a particular sequential command must be
completed before execution of that sequential command begins, and any
non-sequential commands received after and on the same conection as a
particular sequential command must not begin execution until after
that sequential command is completed. Sequential commands are, in
effect, a barrier than non-sequential commands cannot pass or penetrate.
Non-sequential commands are those commands that controllers may
re-order so as to optimize performance. Controllers may furthermore
interleave the execution of several non-sequential commands among
themselves, ..."
Complaints about
not being exported next time I tried to import it, sure. Maybe other
complaints. I wouldn't do this deliberately (other than for testing).
...
--
David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
