Hi, folks. I just built a new box and I''m running the latest OpenSolaris bits. uname says: SunOS blue 5.11 snv_111b i86pc i386 i86pc Solaris I just did an image-update last night, but I was seeing this problem in 111a too. I built myself a pool out of four 1TB disks (WD Caviar Green, if that matters): pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c4d0 ONLINE 0 0 0 c4d1 ONLINE 0 0 0 c5d0 ONLINE 0 0 0 c5d1 ONLINE 0 0 0 errors: No known data errors I''m trying to create a file system in that pool to hold a mysql database using the command zfs create tank/mysql, but the create command is hanging. Truss of the process shows: stgreen at blue:~$ pgrep -lf zfs 7471 zfs create tank/mysql stgreen at blue:~$ pfexec truss -p 7471 door_call(7, 0x080F7008) (sleeping...) This is an RPC thing, right? I had this happen a couple of times before the update yesterday as well. The thing is, the file system actually got created: stgreen at blue:~$ zfs list tank/mysql NAME USED AVAIL REFER MOUNTPOINT tank/mysql 28.4K 2.65T 28.4K /tank/mysql and I can happily cd to the file system and do things there. I''ve let zfs create sit in this state for a good long while, with nothing ever happening. Control-C-ing the zfs create doesn''t seem to cause any problems, but the whole thing is a bit worrisome. I''m happy to do whatever crazy things you suggest to figure out why this is happening... Steve
Stephen Green wrote:> Hi, folks. I just built a new box and I''m running the latest OpenSolaris > bits. uname says: > > SunOS blue 5.11 snv_111b i86pc i386 i86pc Solaris > > I just did an image-update last night, but I was seeing this problem in > 111a too. > > I built myself a pool out of four 1TB disks (WD Caviar Green, if that > matters): > > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > c4d0 ONLINE 0 0 0 > c4d1 ONLINE 0 0 0 > c5d0 ONLINE 0 0 0 > c5d1 ONLINE 0 0 0 > > errors: No known data errors > > I''m trying to create a file system in that pool to hold a mysql database > using the command zfs create tank/mysql, but the create command is > hanging. Truss of the process shows: > > stgreen at blue:~$ pgrep -lf zfs > 7471 zfs create tank/mysql > stgreen at blue:~$ pfexec truss -p 7471 > door_call(7, 0x080F7008) (sleeping...) > > This is an RPC thing, right? > > I had this happen a couple of times before the update yesterday as well. > The thing is, the file system actually got created: > > stgreen at blue:~$ zfs list tank/mysql > NAME USED AVAIL REFER MOUNTPOINT > tank/mysql 28.4K 2.65T 28.4K /tank/mysql > > and I can happily cd to the file system and do things there. I''ve let > zfs create sit in this state for a good long while, with nothing ever > happening. Control-C-ing the zfs create doesn''t seem to cause any > problems, but the whole thing is a bit worrisome. > > I''m happy to do whatever crazy things you suggest to figure out why this > is happening...I suspect this is probably a nameservice lookup call running ''pfiles 7471'' should confirm. -- Darren J Moffat
On Jun 1, 2009, at 4:57 AM, Darren J Moffat wrote:> Stephen Green wrote: >> Hi, folks. I just built a new box and I''m running the latest >> OpenSolaris bits. uname says: >> SunOS blue 5.11 snv_111b i86pc i386 i86pc Solaris >> I just did an image-update last night, but I was seeing this >> problem in 111a too. >> I built myself a pool out of four 1TB disks (WD Caviar Green, if >> that matters): >> pool: tank >> state: ONLINE >> scrub: none requested >> config: >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> c4d0 ONLINE 0 0 0 >> c4d1 ONLINE 0 0 0 >> c5d0 ONLINE 0 0 0 >> c5d1 ONLINE 0 0 0 >> errors: No known data errors >> I''m trying to create a file system in that pool to hold a mysql >> database using the command zfs create tank/mysql, but the create >> command is hanging. Truss of the process shows: >> stgreen at blue:~$ pgrep -lf zfs >> 7471 zfs create tank/mysql >> stgreen at blue:~$ pfexec truss -p 7471 >> door_call(7, 0x080F7008) (sleeping...) >> This is an RPC thing, right? >> I had this happen a couple of times before the update yesterday as >> well. The thing is, the file system actually got created: >> stgreen at blue:~$ zfs list tank/mysql >> NAME USED AVAIL REFER MOUNTPOINT >> tank/mysql 28.4K 2.65T 28.4K /tank/mysql >> and I can happily cd to the file system and do things there. I''ve >> let zfs create sit in this state for a good long while, with >> nothing ever happening. Control-C-ing the zfs create doesn''t seem >> to cause any problems, but the whole thing is a bit worrisome. >> I''m happy to do whatever crazy things you suggest to figure out why >> this is happening... > > I suspect this is probably a nameservice lookup call running > ''pfiles 7471'' should confirm.Thanks, I''ll check that when I''m back in front of the machine. This might be the same thing that''s causing sshes to the machine to hang too. Steve -- Stephen Green // Stephen.Green at sun.com Principal Investigator \\ http://blogs.sun.com/searchguy Aura Project // Voice: +1 781-442-0926 Sun Microsystems Labs \\ Fax: +1 781-442-1692
Darren J Moffat wrote:> Stephen Green wrote:>> stgreen at blue:~$ pgrep -lf zfs >> 7471 zfs create tank/mysql >> stgreen at blue:~$ pfexec truss -p 7471 >> door_call(7, 0x080F7008) (sleeping...) >> > > I suspect this is probably a nameservice lookup call running > ''pfiles 7471'' should confirm.Looks like it''s waiting on smbd? stgreen at blue:~/Projects/silverton-base$ pfexec truss -p 16790 door_call(7, 0x080F7008) (sleeping...) stgreen at blue:~/Projects/silverton-base$ pfexec pfiles 16790 16790: zfs create tank/mybook Current rlimit: 256 file descriptors [snip] 7: S_IFDOOR mode:0644 dev:311,0 ino:40 uid:0 gid:3 size:0 O_RDONLY door to smbd[600] /var/run/smb_share_door Perhaps trying to resolve it''s own name for sharing? There''s an entry for blue in /etc/hosts. zfs destroy for a file system does not have the same problem. Steve