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.
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.) [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]" Uwe -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
