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. If you pay > closer attention you will see that "mounting" the filesystem basically > just adds a logical path mapping since the filesystem is already > available under /poolname/filesystemname regardless. So doing the > mount makes /poolname/filesystemname available as /filesystemname, or > whatever mount path you specify.
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 when there's no new IO activity to the pool (not just the filesystem). 5 or 10 seconds, maybe? (Possibly excepting if there was a HUGE spike of IO for a while just before this; there could be considerable stuff in the ZIL not yet committed then, I would think.) 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. 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). But it seems wrong to leave things uncommitted significantlylonger than necessary (seconds are huge time units to a computer, after all), and if the device is sitting there not doing IO, there's no reason it shouldn't have been writing anything uncommitted instead. Conversely, anybody who is pulling disks / memory sticks off while IO is visibly incomplete really SHOULD expect to lose everything on them, even if sometimes they'll be luckier than that. I suppose we're dealing with people who didn't work with floppies here, where that lesson got pretty solidly beaten in to people :-. -- 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
