Hi, I''ve browsed the archives but there soes not seem to be a nice solution to this one (happening on a Solaris 10u5 production machine): zpool export atlashome zpool import atlashome cannot mount ''/atlashome/BACKUP'': directory is not empty (from old emails I gathered that the output of zfs list and zfs -o name,mountpoint should agree on the ordering and at first glance it seems to be that way) Our setup is as follows: /atlashome/<username> are directories of a number of users with up to 28 snapshots under each user then we have /atlashome/BACKUP as an additional (child) file system and /atlashome/BACKUP/<username> are file systems from remote users whose snapshots are "copied" via zfs send/receive once a day (keeping the latest 5 here as well). Any idea how I can solve this mount problem? Due to this the box is not starting all services, especially not nfs-sharing these directories. Thanks in advance Carsten
Hi
a small addendum. It seems that all sub ZFS below /atlashome/BACKUP are
already mounted when /atlashome/BACKUP is tried to be mounted:
# zfs get all atlashome/BACKUP|head -15
NAME PROPERTY VALUE SOURCE
atlashome/BACKUP type filesystem -
atlashome/BACKUP creation Thu Oct 9 16:30 2008 -
atlashome/BACKUP used 9.95T -
atlashome/BACKUP available 1.78T -
atlashome/BACKUP referenced 172K -
atlashome/BACKUP compressratio 1.47x -
atlashome/BACKUP mounted no -
atlashome/BACKUP quota none default
atlashome/BACKUP reservation none default
atlashome/BACKUP recordsize 32K inherited from
atlashome
atlashome/BACKUP mountpoint /atlashome/BACKUP default
atlashome/BACKUP sharenfs on inherited from
atlashome
atlashome/BACKUP checksum on default
atlashome/BACKUP compression on local
while
# ls -l /atlashome/BACKUP | wc -l
33
Is there any way to force zpool import to re-order that? I could delete
all stuff under BACKUP, however given the size I don''t really want to.
Cheers
Carsten
On Mon, 29 Jun 2009, Carsten Aulbert wrote:> Is there any way to force zpool import to re-order that? I could delete > all stuff under BACKUP, however given the size I don''t really want to.Do a zpool export first, and then check to see what''s in /atlashome. My bet is that the BACKUP directory is still there. If so, do an rmdir on /atlashome/BACKUP and then try the import again. Regards, markm
Hi Mark J Musante wrote:> > Do a zpool export first, and then check to see what''s in /atlashome. My > bet is that the BACKUP directory is still there. If so, do an rmdir on > /atlashome/BACKUP and then try the import again.Sorry, I meant to copy this earlier: s11 console login: root Password: Last login: Mon Jun 29 10:37:47 on console Sun Microsystems Inc. SunOS 5.10 Generic January 2005 s11:~# zpool export atlashome s11:~# ls -l /atlashome /atlashome: No such file or directory s11:~# zpool import atlashome cannot mount ''/atlashome/BACKUP'': directory is not empty s11:~# ls -l /atlashome/BACKUP/|wc -l 33 s11:~# Thus you see that probably zpool import does "the wrong thing"(TM) (or wrong order) Any idea? Cheers Carsten PS: I opened a case for that, but waited for the call back. When solving this problem, I can post the case ID for further reference.
On Mon, 29 Jun 2009, Carsten Aulbert wrote:> s11 console login: root > Password: > Last login: Mon Jun 29 10:37:47 on console > Sun Microsystems Inc. SunOS 5.10 Generic January 2005 > s11:~# zpool export atlashome > s11:~# ls -l /atlashome > /atlashome: No such file or directory > s11:~# zpool import atlashome > cannot mount ''/atlashome/BACKUP'': directory is not empty > s11:~# ls -l /atlashome/BACKUP/|wc -l > 33 > s11:~#OK, looks like you''re running into CR 6827199. There''s a workaround for that as well. After the zpool import, manually zfs umount all the datasets under /atlashome/BACKUP. Once you''ve done that, the BACKUP directory will still be there. Manually mount the dataset that corresponds to /atlashome/BACKUP, and then try ''zfs mount -a''. Regards, markm
Hi Mark, Mark J Musante wrote:> > OK, looks like you''re running into CR 6827199. > > There''s a workaround for that as well. After the zpool import, manually > zfs umount all the datasets under /atlashome/BACKUP. Once you''ve done > that, the BACKUP directory will still be there. Manually mount the > dataset that corresponds to /atlashome/BACKUP, and then try ''zfs mount -a''.I did that (needed to rmdir the directories under BACKUP) and then finally it worked - and the best even after a reboot it was able to mount all file systems again. Great and a lot of thanks! One question: Where can I find more about CR 6827199? I logged into sun.com with my service contract enabled log-in but I cannot find it there (or the search function does not like me too much). Cheers Carsten
On 29.06.09 23:01, Carsten Aulbert wrote:> One question: > > Where can I find more about CR 6827199? I logged into sun.com with my > service contract enabled log-in but I cannot find it there (or the > search function does not like me too much).You can try bugs.opensolaris.org too: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6827199 victor