On Wed, February 11, 2009 18:16, Uwe Dippel wrote: > I need to disappoint you here, LED inactive for a few seconds is a very > bad indicator of pending writes. Used to experience this on a stick on > Ubuntu, which was silent until the 'umount' and then it started to write > for some 10 seconds.
Yikes, that's bizarre. > On the other hand, you are spot-on w.r.t. 'umount'. Once the command is > through, there is no more write to be expected. And if there was, it would > be a serious bug. So this 'umount'ed system needs to be in perfectly > consistent states. (Which is why I wrote further up that the structure > above the file system, that is the pool, is probably the culprit for all > this misery.) Yeah, once it's unmounted it really REALLY should be in a consistent state. > [i]Conversely, anybody who is pulling disks / memory sticks off while IO > is > visibly incomplete really SHOULD expect to lose everything on them[/i] > I hope you don't mean this. Not in a filesystem much hyped and much > advanced. Of course, we expect corruption of all files whose 'write' has > been boldly interrupted. But I for one, expect the metadata of all other > files to be readily available. Kind of, at the next use, telling me:"You > idiot removed the plug last, while files were still in the process of > writing. Don't expect them to be available now. Here is the list of all > other files: [list of all files not being written then]" It's good to have hopes, certainly. I'm just kinda cynical. -- 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
