Ok, it's still happening in snv_106:
I plugged a USB drive into a freshly installed system, and created a single
disk zpool on it:
# zpool create usbtest c1t0d0
I opened the (nautilus?) file manager in gnome, and copied the /etc/X11 folder
to it. I then copied the /etc/apache folder to it, and at 4:05pm, disconnected
the drive.
At this point there are *no* warnings on screen, or any indication that there
is a problem. To check that the pool was still working, I created duplicates
of the two folders on that drive. That worked without any errors, although the
drive was physically removed.
4:07pm
I ran zpool status, the pool is actually showing as unavailable, so at least
that has happened faster than my last test.
The folder is still open in gnome, however any attempt to copy files to or from
it just hangs the file transfer operation window.
4:09pm
/usbtest is still visible in gnome
Also, I can still open a console and use the folder:
# cd usbtest
# ls
X11 X11 (copy) apache apache (copy)
I also tried:
# mv X11 X11-test
That hung, but I saw the X11 folder disappear from the graphical file manager,
so the system still believes something is working with this pool.
The main GUI is actually a little messed up now. The gnome file manager window
looking at the /usbtest folder has hung. Also, right-clicking the desktop to
open a new terminal hangs, leaving the right-click menu on screen.
The main menu still works though, and I can still open a new terminal.
4:19pm
Commands such as ls are finally hanging on the pool.
At this point I tried to reboot, but it appears that isn't working. I used
system monitor to kill everything I had running and tried again, but that
didn't help.
I had to physically power off the system to reboot.
After the reboot, as expected, /usbtest still exists (even though the drive is
disconnected). I removed that folder and connected the drive.
ZFS detects the insertion and automounts the drive, but I find that although
the pool is showing as online, and the filesystem shows as mounted at /usbtest.
But the /usbtest directory doesn't exist.
I had to export and import the pool to get it available, but as expected, I've
lost data:
# cd usbtest
# ls
X11
even worse, zfs is completely unaware of this:
# zpool status -v usbtest
pool: usbtest
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
usbtest ONLINE 0 0 0
c1t0d0 ONLINE 0 0 0
errors: No known data errors
So in summary, there are a good few problems here, many of which I've already
reported as bugs:
1. ZFS still accepts read and write operations for a faulted pool, causing data
loss that isn't necessarily reported by zpool status.
2. Even after writes start to hang, it's still possible to continue reading
data from a faulted pool.
3. A faulted pool causes unwanted side effects in the GUI, making the system
hard to use, and impossible to reboot.
4. After a hard reset, ZFS does not recover cleanly. Unused mountpoints are
left behind.
5. Automatic mounting of pools doesn't seem to work reliably.
6. zfs status doesn't inform of any problems mounting the pool.
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
