From linimon at FreeBSD.org Tue Sep 1 05:11:50 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 1 05:12:13 2009 Subject: kern/138421: [ufs] [patch] remove UFS label limitations Message-ID: <200909010511.n815Bgcv079903@freefall.freebsd.org> Old Synopsis: UFS label limitations New Synopsis: [ufs] [patch] remove UFS label limitations Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 1 05:02:51 UTC 2009 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=138421 From pluknet at gmail.com Wed Sep 2 05:38:01 2009 From: pluknet at gmail.com (pluknet) Date: Wed Sep 2 05:38:07 2009 Subject: 64-bit inodes In-Reply-To: <20090831204506.GA6464@keira.kiwi-computer.com> References: <1287213639.20090831194947@ngs.ru> <20090831184045.GA5846@keira.kiwi-computer.com> <448086815.20090901031952@ngs.ru> <20090831204506.GA6464@keira.kiwi-computer.com> Message-ID: 2009/9/1 Rick C. Petty : > On Tue, Sep 01, 2009 at 03:19:52AM +0700, bossic@ngs.ru wrote: >> > On Mon, Aug 31, 2009 at 07:49:47PM +0700, bossic@ngs.ru wrote: >> >> Good time of day! >> >> I have a question about 64-bit inodes. Some software (for example >> >> glusterfs http://www.gluster.org/) don't work on operation systems this >> >> type of inodes support >> >> without. Will FreeBSD support 64-bit inodes? And when expect it? >> >> > UFS2 uses 64-bit block numbers and 64-bit times. ?Not sure about ZFS, but I >> > know it supports at least 64-bit block pointers. ?I'm not exactly sure what >> > you mean by "support 64-bit inodes". ?Certainly FreeBSD supports >> > filesystems that use 64-bit pointers and timestamps. >> >> Hi! I need to work the packet glusterfs. But I have next: "Distribute >> translator: uses 64bit inode numbers, as FreeBSD doesn't support 64bit >> inodes. Distribute is seen to not work on FreeBSD" on >> http://www.gluster.org/docs/index.php/Whats_New_v2.0 and >> http://www.mavetju.org/weblog/html/00262.html . What can I do? This >> packet working on Linux, but have "core dumped" on FreeBSD. There is >> not big problem to debug it for me, but definition of bug is lower >> hands me. > > [CC'd to the list for additional comments] > btw, NetBSD switched ino_t to uint64_t four years ago (so it was shipped in 4.0). Unrelated, but.. -- wbr, pluknet From linimon at FreeBSD.org Wed Sep 2 10:17:16 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 2 10:17:23 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Message-ID: <200909021017.n82AHGW5000737@freefall.freebsd.org> Synopsis: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 2 10:17:02 UTC 2009 Responsible-Changed-Why: Possibly filesystem-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=138476 From jhb at FreeBSD.org Wed Sep 2 12:50:06 2009 From: jhb at FreeBSD.org (John Baldwin) Date: Wed Sep 2 12:50:12 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Message-ID: <200909021250.n82Co6Kq055000@freefall.freebsd.org> The following reply was made to PR kern/138476; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, stephane.rochoy@netasq.com Cc: Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Date: Wed, 2 Sep 2009 08:33:50 -0400 Line 979 of vfs_subr.c in 7.2 is this in delmntque() 979: TAILQ_REMOVE(&mp->mnt_nvnodelist, vp, v_nmntvnodes); It looks like this is either a fuse or sshfs bug where it doesn't insert a vnode it created into the mount's vnode list and when the vnode gets recycled so it can be used by another filesystem (in this case FFS), it causes a panic. -- John Baldwin From gavin at FreeBSD.org Wed Sep 2 19:00:17 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Wed Sep 2 19:00:26 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Message-ID: <200909021900.n82J0H2S029463@freefall.freebsd.org> The following reply was made to PR kern/138476; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Date: Wed, 2 Sep 2009 19:52:46 +0100 (BST) To submitter: Is there any chance you can try unmounting your sshfs and having some other fuse FS mounted, to determine if this is caused by fuse or sshfs? From mel.flynn+fbsd.fs at mailing.thruhere.net Wed Sep 2 22:17:15 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Wed Sep 2 22:17:22 2009 Subject: Patch to allow gmirror to set priority of a disk Message-ID: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> Hi, I've created a patch that allows gmirror to set the priority of a disk. I've needed this feature so I can signal which disk is the "master" on the next reboot and also because insertion of a 3rd disk comes with the same priority as the master disk. Some background about the first issue: I've got one system that gets READ_DMA errors and then dumps the disk out of the mirror. I believe it is NOT related to disk errors, but rather to IDE/Motherboard bandwidth (SMART doesn't show any errors and the READ_DMA errors are scattered amongst LBA blocks, no WRITE_DMA errors ever, never got SATA disks to work on this mobo and last but not least it only happens when IO is high, like daily backup with dump -C 20M). Which disk gets thrown out, is random and the last time that happened I rebooted since I needed a new kernel anyway and the wrong disk was consider master. This is a side-effect of me having to do several: gmirror forget gm0 gmirror insert gm0 adX during an uptime sequence. As a result, both disks have the same priority. Unfortunately, due to geographic relocation, I no longer have physical access to the machine, so I have only compile tested this patch, but I wanted to get some feedback about it: - Have I made some mistakes that would trash my mirror? ;) - Is there any desire to have this feature other then my own? - Any style issues? -- Mel -------------- next part -------------- Index: sbin/geom/class/mirror/geom_mirror.c =================================================================== --- sbin/geom/class/mirror/geom_mirror.c (revision 196761) +++ sbin/geom/class/mirror/geom_mirror.c (working copy) @@ -27,6 +27,7 @@ #include __FBSDID("$FreeBSD$"); +#include /* UCHAR_MAX */ #include #include #include @@ -54,6 +55,7 @@ static void mirror_clear(struct gctl_req *req); static void mirror_dump(struct gctl_req *req); static void mirror_label(struct gctl_req *req); +static void mirror_setprio(struct gctl_req *req); struct g_command class_commands[] = { { "activate", G_FLAG_VERBOSE, mirror_main, G_NULL_OPTS, NULL, @@ -111,6 +113,9 @@ { "remove", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, "[-v] name prov ..." }, + { "setprio", G_FLAG_VERBOSE, mirror_main, G_NULL_OPTS, NULL, + "[-v] name prov priority" + }, { "stop", G_FLAG_VERBOSE, NULL, { { 'f', "force", NULL, G_TYPE_BOOL }, @@ -144,6 +149,8 @@ mirror_dump(req); else if (strcmp(name, "activate") == 0) mirror_activate(req); + else if (strcmp(name, "setprio") == 0) + mirror_setprio(req); else gctl_error(req, "Unknown command: %s.", name); } @@ -375,3 +382,64 @@ printf("Provider %s activated.\n", path); } } + +static void +mirror_setprio(struct gctl_req *req) +{ + struct g_mirror_metadata md, tmpmd; + const char *name, *prov; + intmax_t prio; + uint8_t oldprio; + int error, nargs; + + nargs = gctl_get_int(req, "nargs"); + if (nargs < 3) { + gctl_error(req, "Too few arguments."); + return; + } + + name = gctl_get_ascii(req, "arg0"); + prov = gctl_get_ascii(req, "arg1"); + prio = gctl_get_intmax(req, "arg2"); + if ( prio < 0 || prio > UCHAR_MAX ) { + fprintf(stderr, + "Priority has to be between 0 and %u", UCHAR_MAX); + gctl_error(req, "Failed."); + return; + } + error = g_metadata_read(prov, (u_char *)&tmpmd, sizeof(tmpmd), + G_MIRROR_MAGIC); + if (error != 0) { + fprintf(stderr, "Can't read metadata from %s: %s.\n", + name, strerror(error)); + gctl_error(req, "Failed."); + return; + } + if (mirror_metadata_decode((u_char *)&tmpmd, &md) != 0) { + fprintf(stderr, + "MD5 hash mismatch for provider %s: %s, aborting\n", + prov, strerror(error)); + gctl_error(req, "Failed."); + return; + } + if (strcmp(md.md_name, name) != 0) { + fprintf(stderr, + "Provider %s is not the mirror %s component.\n", + prov, name); + gctl_error(req, "Failed."); + return; + } + oldprio = md.md_priority; + md.md_priority = (uint8_t)prio; + mirror_metadata_encode(&md, (u_char *)&tmpmd); + error = g_metadata_store(prov, (u_char *)&tmpmd, sizeof(tmpmd)); + if (error != 0) { + fprintf(stderr, "Cannot write metadata from %s: %s.\n", + prov, strerror(error)); + gctl_error(req, "Failed."); + return; + } + if (verbose) + printf("Provider %s priority %u => %u", prov, oldprio, + md.md_priority); +} From jhb at freebsd.org Thu Sep 3 12:21:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 3 12:21:49 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs In-Reply-To: <200909021900.n82J0H2S029463@freefall.freebsd.org> References: <200909021900.n82J0H2S029463@freefall.freebsd.org> Message-ID: <200909030803.30858.jhb@freebsd.org> On Wednesday 02 September 2009 3:00:17 pm Gavin Atkinson wrote: > The following reply was made to PR kern/138476; it has been noted by GNATS. > > From: Gavin Atkinson > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during > VFS operations; maybe related to sshfs > Date: Wed, 2 Sep 2009 19:52:46 +0100 (BST) > > To submitter: Is there any chance you can try unmounting your sshfs and > having some other fuse FS mounted, to determine if this is caused by fuse > or sshfs? You can probably narrow it down to which part of the fuse/sshfs code calls 'getnewvnode'. This is most often done during the VFS_VGET() vfs op. It should be inserting all vnodes onto the mount list there (you can compare the code with other filesystems such as UFS to see how it should work). -- John Baldwin From avg at icyb.net.ua Thu Sep 3 12:32:28 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Sep 3 12:32:35 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs In-Reply-To: <200909021900.n82J0H2S029463@freefall.freebsd.org> References: <200909021900.n82J0H2S029463@freefall.freebsd.org> Message-ID: <4A9FB759.8030700@icyb.net.ua> on 02/09/2009 22:00 Gavin Atkinson said the following: > The following reply was made to PR kern/138476; it has been noted by GNATS. > > From: Gavin Atkinson > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during > VFS operations; maybe related to sshfs > Date: Wed, 2 Sep 2009 19:52:46 +0100 (BST) > > To submitter: Is there any chance you can try unmounting your sshfs and > having some other fuse FS mounted, to determine if this is caused by fuse > or sshfs? Just a note: sshfs is a userland program, it can not mess with kernel internals. fuse kmod is the only thing that does. -- Andriy Gapon From avg at icyb.net.ua Thu Sep 3 12:40:07 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Sep 3 12:40:15 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Message-ID: <200909031240.n83Ce3kd032798@freefall.freebsd.org> The following reply was made to PR kern/138476; it has been noted by GNATS. From: Andriy Gapon To: Gavin Atkinson , bug-followup@FreeBSD.org Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Date: Thu, 03 Sep 2009 15:32:25 +0300 on 02/09/2009 22:00 Gavin Atkinson said the following: > The following reply was made to PR kern/138476; it has been noted by GNATS. > > From: Gavin Atkinson > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during > VFS operations; maybe related to sshfs > Date: Wed, 2 Sep 2009 19:52:46 +0100 (BST) > > To submitter: Is there any chance you can try unmounting your sshfs and > having some other fuse FS mounted, to determine if this is caused by fuse > or sshfs? Just a note: sshfs is a userland program, it can not mess with kernel internals. fuse kmod is the only thing that does. -- Andriy Gapon From avg at icyb.net.ua Thu Sep 3 12:41:11 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Sep 3 12:41:23 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs In-Reply-To: <200909030803.30858.jhb@freebsd.org> References: <200909021900.n82J0H2S029463@freefall.freebsd.org> <200909030803.30858.jhb@freebsd.org> Message-ID: <4A9FB964.6060709@icyb.net.ua> on 03/09/2009 15:03 John Baldwin said the following: > On Wednesday 02 September 2009 3:00:17 pm Gavin Atkinson wrote: >> The following reply was made to PR kern/138476; it has been noted by GNATS. >> >> From: Gavin Atkinson >> To: bug-followup@FreeBSD.org >> Cc: >> Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during >> VFS operations; maybe related to sshfs >> Date: Wed, 2 Sep 2009 19:52:46 +0100 (BST) >> >> To submitter: Is there any chance you can try unmounting your sshfs and >> having some other fuse FS mounted, to determine if this is caused by fuse >> or sshfs? > > You can probably narrow it down to which part of the fuse/sshfs code > calls 'getnewvnode'. This is most often done during the VFS_VGET() vfs op. > It should be inserting all vnodes onto the mount list there (you can compare > the code with other filesystems such as UFS to see how it should work). > Looks like this could be happening in fuse_create (fuse_vnops.c). -- Andriy Gapon From pjd at FreeBSD.org Thu Sep 3 12:44:12 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Sep 3 12:44:19 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <20090903124407.GJ1821@garage.freebsd.pl> On Thu, Sep 03, 2009 at 12:00:11AM +0200, Mel Flynn wrote: > Hi, > > I've created a patch that allows gmirror to set the priority of a disk. I've > needed this feature so I can signal which disk is the "master" on the next > reboot and also because insertion of a 3rd disk comes with the same priority > as the master disk. > > Some background about the first issue: I've got one system that gets READ_DMA > errors and then dumps the disk out of the mirror. I believe it is NOT related > to disk errors, but rather to IDE/Motherboard bandwidth (SMART doesn't show > any errors and the READ_DMA errors are scattered amongst LBA blocks, no > WRITE_DMA errors ever, never got SATA disks to work on this mobo and last but > not least it only happens when IO is high, like daily backup with dump -C > 20M). > Which disk gets thrown out, is random and the last time that happened I > rebooted since I needed a new kernel anyway and the wrong disk was consider > master. This is a side-effect of me having to do several: > gmirror forget gm0 > gmirror insert gm0 adX > > during an uptime sequence. As a result, both disks have the same priority. > > Unfortunately, due to geographic relocation, I no longer have physical access > to the machine, so I have only compile tested this patch, but I wanted to get > some feedback about it: > - Have I made some mistakes that would trash my mirror? ;) > - Is there any desire to have this feature other then my own? > - Any style issues? Thank you for working on this, this is a long missing bit, although I've some comments. You assume that you can write to the mirror component, so you also assume that your mirror if offline, because if it would be online you won't be able to write to one of its components. If your mirror is offline, you can just 'gmirror label' the components again. It won't touch your data and this way you will have your priorities set properly. So what we need more is to be able to change priority of a mirror component which is part of an online mirror, so we need to comunicate with the kernel. Would you like to implement this functionality this way? I'd suggest doing this not as separate gmirror(8) subcommand, but as an extension to 'configure' subcommand, where one can provide priority by giving '-p' argument. PS. In case of 'gmirror insert' you already can change the priority with the '-p' option. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090903/29f05668/attachment.pgp From avg at icyb.net.ua Thu Sep 3 12:50:02 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Sep 3 12:50:08 2009 Subject: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Message-ID: <200909031250.n83Co25Y042126@freefall.freebsd.org> The following reply was made to PR kern/138476; it has been noted by GNATS. From: Andriy Gapon To: John Baldwin , bug-followup@freebsd.org Cc: freebsd-fs@freebsd.org, Gavin Atkinson Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs Date: Thu, 03 Sep 2009 15:41:08 +0300 on 03/09/2009 15:03 John Baldwin said the following: > On Wednesday 02 September 2009 3:00:17 pm Gavin Atkinson wrote: >> The following reply was made to PR kern/138476; it has been noted by GNATS. >> >> From: Gavin Atkinson >> To: bug-followup@FreeBSD.org >> Cc: >> Subject: Re: kern/138476: [panic] [sshfs] [fuse] Almost regular panic during >> VFS operations; maybe related to sshfs >> Date: Wed, 2 Sep 2009 19:52:46 +0100 (BST) >> >> To submitter: Is there any chance you can try unmounting your sshfs and >> having some other fuse FS mounted, to determine if this is caused by fuse >> or sshfs? > > You can probably narrow it down to which part of the fuse/sshfs code > calls 'getnewvnode'. This is most often done during the VFS_VGET() vfs op. > It should be inserting all vnodes onto the mount list there (you can compare > the code with other filesystems such as UFS to see how it should work). > Looks like this could be happening in fuse_create (fuse_vnops.c). -- Andriy Gapon From mel.flynn+fbsd.fs at mailing.thruhere.net Thu Sep 3 13:48:42 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Thu Sep 3 13:48:48 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <20090903124407.GJ1821@garage.freebsd.pl> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090903124407.GJ1821@garage.freebsd.pl> Message-ID: <200909031548.37887.mel.flynn+fbsd.fs@mailing.thruhere.net> On Thursday 03 September 2009 14:44:07 Pawel Jakub Dawidek wrote: > On Thu, Sep 03, 2009 at 12:00:11AM +0200, Mel Flynn wrote: > > Unfortunately, due to geographic relocation, I no longer have physical > > access to the machine, so I have only compile tested this patch, but I > > wanted to get some feedback about it: > > - Have I made some mistakes that would trash my mirror? ;) > > - Is there any desire to have this feature other then my own? > > - Any style issues? > > Thank you for working on this, this is a long missing bit, although I've > some comments. > > You assume that you can write to the mirror component, so you also > assume that your mirror if offline, because if it would be online you > won't be able to write to one of its components. Ah, that's a gotcha I didn't catch. > So what we need more is to be able to change priority of a mirror > component which is part of an online mirror, so we need to comunicate > with the kernel. Would you like to implement this functionality this > way? Yes. > I'd suggest doing this not as separate gmirror(8) subcommand, but as an > extension to 'configure' subcommand, where one can provide priority by > giving '-p' argument. Except I didn't see how configure was implemented. Am I correct that this is g_mirror_ctl_configure in sys/geom/mirror/g_mirror_ctl.c? > PS. In case of 'gmirror insert' you already can change the priority with > the '-p' option. Right. Dunno how I missed that. On a related note, perhaps the attached can be applied so that there's no question about the priority numbering? -- Mel -------------- next part -------------- Index: sbin/geom/class/mirror/gmirror.8 =================================================================== --- sbin/geom/class/mirror/gmirror.8 (revision 196776) +++ sbin/geom/class/mirror/gmirror.8 (working copy) @@ -115,8 +115,8 @@ .It Cm label Create a mirror. The order of components is important, because a component's priority is based on its position -(starting from 0). -The component with the biggest priority is used by the +(starting from 0 to 255). +The component with the biggest priority (the lowest number) is used by the .Cm prefer balance algorithm and is also used as a master component when resynchronization is needed, From pjd at FreeBSD.org Thu Sep 3 13:57:45 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Sep 3 13:57:57 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <200909031548.37887.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090903124407.GJ1821@garage.freebsd.pl> <200909031548.37887.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <20090903135741.GK1821@garage.freebsd.pl> On Thu, Sep 03, 2009 at 03:48:37PM +0200, Mel Flynn wrote: > On Thursday 03 September 2009 14:44:07 Pawel Jakub Dawidek wrote: > > I'd suggest doing this not as separate gmirror(8) subcommand, but as an > > extension to 'configure' subcommand, where one can provide priority by > > giving '-p' argument. > > Except I didn't see how configure was implemented. Am I correct that this is > g_mirror_ctl_configure in sys/geom/mirror/g_mirror_ctl.c? Yes, you are correct. > On a related note, perhaps the attached can be applied so that there's no > question about the priority numbering? > -- > Mel > Index: sbin/geom/class/mirror/gmirror.8 > =================================================================== > --- sbin/geom/class/mirror/gmirror.8 (revision 196776) > +++ sbin/geom/class/mirror/gmirror.8 (working copy) > @@ -115,8 +115,8 @@ > .It Cm label > Create a mirror. > The order of components is important, because a component's priority is based on its position > -(starting from 0). > -The component with the biggest priority is used by the > +(starting from 0 to 255). > +The component with the biggest priority (the lowest number) is used by the > .Cm prefer > balance algorithm > and is also used as a master component when resynchronization is needed, Looks good. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090903/9a6a06eb/attachment.pgp From gtodd at bellanet.org Thu Sep 3 17:13:56 2009 From: gtodd at bellanet.org (Graham Todd) Date: Thu Sep 3 17:14:11 2009 Subject: Identifying disks with serial number Message-ID: <4A9FF314.1080909@bellanet.org> Hello all, Quick question on disk serial numbers. Besides manually geom_label-ling disks by serial number is there an automagic way for geom to present serial numbers to the system/devfs? I'm not using ZFS or anything but I've got to the point where anything that helps with juggling disks would be nice. I noticed a newish DragonflyBSD feature that does this. They "label" disks with serial numbers, devfs seems to see them and then you can use convenience aliases in /etc/devtab to make the serial number ID referenceable in /etc/fstab). See: http://leaf.dragonflybsd.org/mailarchive/users/2009-08/msg00149.html Something similar was discussed in freebsd-arch thread long ago (by the usual suspects (-: ): http://lists.freebsd.org/pipermail/freebsd-arch/2006-June/005344.html Is there a documented way to "autolabel" disks by serial number in FreeBSD? Thanks for all replies. From 000.fbsd at quip.cz Thu Sep 3 19:12:40 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Sep 3 19:12:47 2009 Subject: Identifying disks with serial number In-Reply-To: <4A9FF314.1080909@bellanet.org> References: <4A9FF314.1080909@bellanet.org> Message-ID: <4AA010C7.9020303@quip.cz> Graham Todd wrote: > Hello all, > > Quick question on disk serial numbers. Besides manually geom_label-ling > disks by serial number is there an automagic way for geom to present > serial numbers to the system/devfs? I'm not using ZFS or anything but > I've got to the point where anything that helps with juggling disks would > be nice. > > I noticed a newish DragonflyBSD feature that does this. They "label" disks > with serial numbers, devfs seems to see them and then you can use > convenience aliases in /etc/devtab to make the serial number ID > referenceable in /etc/fstab). See: > > http://leaf.dragonflybsd.org/mailarchive/users/2009-08/msg00149.html > > Something similar was discussed in freebsd-arch thread long ago (by the > usual suspects (-: ): > > http://lists.freebsd.org/pipermail/freebsd-arch/2006-June/005344.html > > Is there a documented way to "autolabel" disks by serial number in FreeBSD? It was discussed [1], but there are no labels by disk ID at this time. There are auto labels for partitions. You can then use ufsid in your fstab. GEOM_LABEL: Label for provider ad4s1a is ufsid/4a985d01cb85f79f. GEOM_LABEL: Label for provider ad4s1d is ufsid/4a985d015b316798. GEOM_LABEL: Label for provider ad4s1e is ufsid/4a985d015260f27c. 1] http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003625.html Miroslav Lachman From mel.flynn+fbsd.fs at mailing.thruhere.net Fri Sep 4 01:12:26 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Fri Sep 4 01:12:32 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <20090903135741.GK1821@garage.freebsd.pl> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909031548.37887.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090903135741.GK1821@garage.freebsd.pl> Message-ID: <200909040312.21376.mel.flynn+fbsd.fs@mailing.thruhere.net> On Thursday 03 September 2009 15:57:41 Pawel Jakub Dawidek wrote: > On Thu, Sep 03, 2009 at 03:48:37PM +0200, Mel Flynn wrote: > > On Thursday 03 September 2009 14:44:07 Pawel Jakub Dawidek wrote: > > > I'd suggest doing this not as separate gmirror(8) subcommand, but as an > > > extension to 'configure' subcommand, where one can provide priority by > > > giving '-p' argument. > > > > Except I didn't see how configure was implemented. Am I correct that this > > is g_mirror_ctl_configure in sys/geom/mirror/g_mirror_ctl.c? > > Yes, you are correct. Quick question: how can I distinguish between "-p given" and "-p not given". All the configure commands work either on the mirror or all disks, for this I need to get the specific disk in a command line argument, but....as far as I can tell: priority = gctl_get_paraml(req, "priority", sizeof(*priority)); will give NULL, if userland and kernel are out of sync, as the geom should always fill the priority, as per: { 'p', "priority", NULL, G_TYPE_NUMBER }, Should I instead use: static int prio = -1; ... { 'p', "priority", &prio, G_TYPE_NUMBER }, And if the above returns -1, do_nada()? -- Mel From mel.flynn+fbsd.fs at mailing.thruhere.net Fri Sep 4 08:16:56 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Fri Sep 4 08:17:02 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <20090903135741.GK1821@garage.freebsd.pl> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909031548.37887.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090903135741.GK1821@garage.freebsd.pl> Message-ID: <200909041016.34677.mel.flynn+fbsd.fs@mailing.thruhere.net> On Thursday 03 September 2009 15:57:41 Pawel Jakub Dawidek wrote: > On Thu, Sep 03, 2009 at 03:48:37PM +0200, Mel Flynn wrote: > > On Thursday 03 September 2009 14:44:07 Pawel Jakub Dawidek wrote: > > > I'd suggest doing this not as separate gmirror(8) subcommand, but as an > > > extension to 'configure' subcommand, where one can provide priority by > > > giving '-p' argument. > > > > Except I didn't see how configure was implemented. Am I correct that this > > is g_mirror_ctl_configure in sys/geom/mirror/g_mirror_ctl.c? > > Yes, you are correct. Ok, new patch. I gathered from configure_slice, that my assumption was about flag handling is correct. Patch is only compile tested. -- Mel -------------- next part -------------- Index: sbin/geom/class/mirror/geom_mirror.c =================================================================== --- sbin/geom/class/mirror/geom_mirror.c (revision 196803) +++ sbin/geom/class/mirror/geom_mirror.c (working copy) @@ -47,7 +47,7 @@ static char label_balance[] = "split", configure_balance[] = "none"; static intmax_t label_slice = 4096, configure_slice = -1; -static intmax_t insert_priority = 0; +static intmax_t insert_priority = 0, configure_priority = -1; static void mirror_main(struct gctl_req *req, unsigned flags); static void mirror_activate(struct gctl_req *req); @@ -71,10 +71,11 @@ { 'F', "nofailsync", NULL, G_TYPE_BOOL }, { 'h', "hardcode", NULL, G_TYPE_BOOL }, { 'n', "noautosync", NULL, G_TYPE_BOOL }, + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, { 's', "slice", &configure_slice, G_TYPE_NUMBER }, G_OPT_SENTINEL }, - NULL, "[-adfFhnv] [-b balance] [-s slice] name" + NULL, "[-adfFhnv] [-b balance] [-s slice] [-p prio] name [prov]" }, { "deactivate", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, "[-v] name prov ..." Index: sbin/geom/class/mirror/gmirror.8 =================================================================== --- sbin/geom/class/mirror/gmirror.8 (revision 196803) +++ sbin/geom/class/mirror/gmirror.8 (working copy) @@ -47,7 +47,9 @@ .Op Fl adfFhnv .Op Fl b Ar balance .Op Fl s Ar slice +.Op Fl p Ar priority .Ar name +.Op Ar prov .Nm .Cm rebuild .Op Fl v @@ -115,8 +117,8 @@ .It Cm label Create a mirror. The order of components is important, because a component's priority is based on its position -(starting from 0). -The component with the biggest priority is used by the +(starting from 0 to 255). +The component with the biggest priority (the lowest number) is used by the .Cm prefer balance algorithm and is also used as a master component when resynchronization is needed, @@ -175,6 +177,9 @@ Hardcode providers' names in metadata. .It Fl n Turn off autosynchronization of stale components. +.It Fl p Ar priority +Specify priority for given +.Ar prov .It Fl s Ar slice Specifies slice size for .Cm split Index: sys/geom/mirror/g_mirror_ctl.c =================================================================== --- sys/geom/mirror/g_mirror_ctl.c (revision 196803) +++ sys/geom/mirror/g_mirror_ctl.c (working copy) @@ -93,12 +93,12 @@ { struct g_mirror_softc *sc; struct g_mirror_disk *disk; - const char *name, *balancep; + const char *name, *balancep, *prov; intmax_t *slicep; uint32_t slice; uint8_t balance; int *autosync, *noautosync, *failsync, *nofailsync, *hardcode, *dynamic; - int *nargs, do_sync = 0, dirty = 1; + int *nargs, *priority, do_sync = 0, dirty = 1, do_priority = 0; nargs = gctl_get_paraml(req, "nargs", sizeof(*nargs)); if (nargs == NULL) { @@ -149,6 +149,27 @@ gctl_error(req, "No '%s' argument.", "dynamic"); return; } + priority = gctl_get_paraml(req, "priority", sizeof(*priority)); + if (priority == NULL ) { + gctl_error(req, "No '%s' argument.", "priority"); + return; + } + if( *priority < -1 || *priority > 255 ) { + gctl_error(req, "Priority range is 0 to 255, %i given", + *priority); + return; + } + /* Since we have a priority, we also need a provider now. + * Note: be WARNS safe, by always assigning prov and only throw an + * error if *priority != -1. */ + prov = gctl_get_asciiparam(req, "arg1"); + if( *priority > -1 ) { + if( prov == NULL ) { + gctl_error(req, "Priority needs a disk name"); + return; + } + do_priority = 1; + } if (*autosync && *noautosync) { gctl_error(req, "'%s' and '%s' specified.", "autosync", "noautosync"); @@ -233,6 +254,11 @@ disk->d_flags &= ~G_MIRROR_DISK_FLAG_HARDCODED; if (!dirty) disk->d_flags &= ~G_MIRROR_DISK_FLAG_DIRTY; + if (do_priority) { + if (strcmp(disk->d_name, prov) == 0) { + disk->d_priority = *priority; + } + } g_mirror_update_metadata(disk); if (do_sync) { if (disk->d_state == G_MIRROR_DISK_STATE_STALE) { From gtodd at bellanet.org Fri Sep 4 14:36:35 2009 From: gtodd at bellanet.org (Graham Todd) Date: Fri Sep 4 14:36:41 2009 Subject: Identifying disks with serial number In-Reply-To: <4AA010C7.9020303@quip.cz> References: <4A9FF314.1080909@bellanet.org> <4AA010C7.9020303@quip.cz> Message-ID: <4AA125F6.1020003@bellanet.org> Miroslav Lachman wrote: > Graham Todd wrote: >> Hello all, >> >> Quick question on disk serial numbers. Besides manually geom_label-ling >> disks by serial number is there an automagic way for geom to present >> serial numbers to the system/devfs? I'm not using ZFS or anything but >> I've got to the point where anything that helps with juggling disks would >> be nice. >> >> I noticed a newish DragonflyBSD feature that does this. They "label" >> disks with serial numbers, devfs seems to see them and then you can >> use convenience aliases in /etc/devtab to make the serial number ID >> referenceable in /etc/fstab). See: >> >> http://leaf.dragonflybsd.org/mailarchive/users/2009-08/msg00149.html >> >> Something similar was discussed in freebsd-arch thread long ago (by the >> usual suspects (-: ): >> >> http://lists.freebsd.org/pipermail/freebsd-arch/2006-June/005344.html >> >> Is there a documented way to "autolabel" disks by serial number in >> FreeBSD? > > It was discussed [1], but there are no labels by disk ID at this time. > There are auto labels for partitions. You can then use ufsid in your fstab. > > GEOM_LABEL: Label for provider ad4s1a is ufsid/4a985d01cb85f79f. > GEOM_LABEL: Label for provider ad4s1d is ufsid/4a985d015b316798. > GEOM_LABEL: Label for provider ad4s1e is ufsid/4a985d015260f27c. > > 1] http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003625.html Thanks for the reference. I'm already using geom labels for juggling file systems and it's great. I hope that can extend to disks in the future. One of the replies to Ivan Voras's original post asked about a use case. I think in the message to the dragonfly users mailing list (see link above) Matt Dillon lays one out: booting from a specific disk ID no matter how it is attached (firewire, USB, external/internal SATA etc.). Since that might involve changes to the boot loader perhaps it's not a great example. I wasn't thinking of ZFS in particular and didn't realize that the implications were complicated for zpools etc (nor that there was a particular devfs namespace pollution issue for disk labels). As far as I can tell the dfly feature isn't specific to hammer but maybe it is more useful in their particular case. Anyway, thanks to all for the excellent work on FreeBSD file systems and geom classes ;-) From spawk at acm.poly.edu Fri Sep 4 14:44:23 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Fri Sep 4 14:44:30 2009 Subject: Identifying disks with serial number In-Reply-To: <4AA125F6.1020003@bellanet.org> References: <4A9FF314.1080909@bellanet.org> <4AA010C7.9020303@quip.cz> <4AA125F6.1020003@bellanet.org> Message-ID: <4AA12792.5010701@acm.poly.edu> Graham Todd wrote: > Miroslav Lachman wrote: > >> Graham Todd wrote: >> >>> Hello all, >>> >>> Quick question on disk serial numbers. Besides manually geom_label-ling >>> disks by serial number is there an automagic way for geom to present >>> serial numbers to the system/devfs? I'm not using ZFS or anything but >>> I've got to the point where anything that helps with juggling disks would >>> be nice. >>> >>> I noticed a newish DragonflyBSD feature that does this. They "label" >>> disks with serial numbers, devfs seems to see them and then you can >>> use convenience aliases in /etc/devtab to make the serial number ID >>> referenceable in /etc/fstab). See: >>> >>> http://leaf.dragonflybsd.org/mailarchive/users/2009-08/msg00149.html >>> >>> Something similar was discussed in freebsd-arch thread long ago (by the >>> usual suspects (-: ): >>> >>> http://lists.freebsd.org/pipermail/freebsd-arch/2006-June/005344.html >>> >>> Is there a documented way to "autolabel" disks by serial number in >>> FreeBSD? >>> >> It was discussed [1], but there are no labels by disk ID at this time. >> There are auto labels for partitions. You can then use ufsid in your fstab. >> >> GEOM_LABEL: Label for provider ad4s1a is ufsid/4a985d01cb85f79f. >> GEOM_LABEL: Label for provider ad4s1d is ufsid/4a985d015b316798. >> GEOM_LABEL: Label for provider ad4s1e is ufsid/4a985d015260f27c. >> >> 1] http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003625.html >> > > Thanks for the reference. I'm already using geom labels for juggling file > systems and it's great. I hope that can extend to disks in the future. > FYI, you can glabel an entire disk. The man page has an example. -Boris > One of the replies to Ivan Voras's original post asked about a use case. I > think in the message to the dragonfly users mailing list (see link above) > Matt Dillon lays one out: booting from a specific disk ID no matter how it > is attached (firewire, USB, external/internal SATA etc.). Since that might > involve changes to the boot loader perhaps it's not a great example. > > I wasn't thinking of ZFS in particular and didn't realize that the > implications were complicated for zpools etc (nor that there was a > particular devfs namespace pollution issue for disk labels). As far as I > can tell the dfly feature isn't specific to hammer but maybe it is more > useful in their particular case. > > Anyway, thanks to all for the excellent work on FreeBSD file systems and > geom classes ;-) > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From rondzierwa at comcast.net Fri Sep 4 23:08:21 2009 From: rondzierwa at comcast.net (rondzierwa@comcast.net) Date: Fri Sep 4 23:08:34 2009 Subject: zfs:lo lockup In-Reply-To: <910253830.7592771252104642453.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> Message-ID: <398426296.7593551252104906444.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> I'm running zfs on FreeBSD 7.2-RELEASE-p2. i csup'ed sys src 4 weeks ago. I have a 3Ware raid card with 8 1tb drives in raid5. I put the whole space in zfs as a tank and created several file systems from it. these are served to windoze clients via samba 3.0.34. several times a week i have to forcibly reset and reboot the system because one of the smbd processes is stuck in zfs:lo state (as displayed by "top"), and cannot be killed. Typically this happens when there is more than one client machine accessing the zfs shares. It happens when they are both accessing the same share, or different ones. is this something that has already been fixed? if so, what do i have to upgrade to get the fix? if not, what information can i provide to help somebody find a fix? thanks much ron. From spawk at acm.poly.edu Sat Sep 5 01:05:24 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Sat Sep 5 01:05:30 2009 Subject: zfs:lo lockup In-Reply-To: <398426296.7593551252104906444.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> References: <398426296.7593551252104906444.JavaMail.root@sz0128a.westchester.pa.mail.comcast.net> Message-ID: <4AA1B920.1090301@acm.poly.edu> It has very likely been fixed in ZFS version 13, which is available in RELENG_7, RELENG_8, and CURRENT. Have a look at the thread at http://lists.freebsd.org/pipermail/freebsd-fs/2009-August/006694.html for more information. -Boris rondzierwa@comcast.net wrote: > I'm running zfs on FreeBSD 7.2-RELEASE-p2. i csup'ed sys src 4 weeks ago. I have > a 3Ware raid card with 8 1tb drives in raid5. I put the whole space in zfs as a tank and > created several file systems from it. these are served to windoze clients via samba 3.0.34. > > several times a week i have to forcibly reset and reboot the system because one of the > smbd processes is stuck in zfs:lo state (as displayed by "top"), and cannot be killed. > > Typically this happens when there is more than one client machine accessing the zfs > shares. It happens when they are both accessing the same share, or different ones. > > is this something that has already been fixed? if so, what do i have to upgrade to get > the fix? if not, what information can i provide to help somebody find a fix? > > thanks much > ron. > > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From pjd at FreeBSD.org Sat Sep 5 09:11:41 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sat Sep 5 09:11:53 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <200909041016.34677.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909031548.37887.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090903135741.GK1821@garage.freebsd.pl> <200909041016.34677.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <20090905091030.GC1665@garage.freebsd.pl> On Fri, Sep 04, 2009 at 10:16:34AM +0200, Mel Flynn wrote: > On Thursday 03 September 2009 15:57:41 Pawel Jakub Dawidek wrote: > > On Thu, Sep 03, 2009 at 03:48:37PM +0200, Mel Flynn wrote: > > > On Thursday 03 September 2009 14:44:07 Pawel Jakub Dawidek wrote: > > > > I'd suggest doing this not as separate gmirror(8) subcommand, but as an > > > > extension to 'configure' subcommand, where one can provide priority by > > > > giving '-p' argument. > > > > > > Except I didn't see how configure was implemented. Am I correct that this > > > is g_mirror_ctl_configure in sys/geom/mirror/g_mirror_ctl.c? > > > > Yes, you are correct. > > Ok, new patch. I gathered from configure_slice, that my assumption was about > flag handling is correct. Patch is only compile tested. In general the patch looks good, although I haven't tested it yet. I do have some comments though. > Index: sbin/geom/class/mirror/geom_mirror.c > =================================================================== > --- sbin/geom/class/mirror/geom_mirror.c (revision 196803) > +++ sbin/geom/class/mirror/geom_mirror.c (working copy) > @@ -47,7 +47,7 @@ > > static char label_balance[] = "split", configure_balance[] = "none"; > static intmax_t label_slice = 4096, configure_slice = -1; > -static intmax_t insert_priority = 0; > +static intmax_t insert_priority = 0, configure_priority = -1; > > static void mirror_main(struct gctl_req *req, unsigned flags); > static void mirror_activate(struct gctl_req *req); > @@ -71,10 +71,11 @@ > { 'F', "nofailsync", NULL, G_TYPE_BOOL }, > { 'h', "hardcode", NULL, G_TYPE_BOOL }, > { 'n', "noautosync", NULL, G_TYPE_BOOL }, > + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, > { 's', "slice", &configure_slice, G_TYPE_NUMBER }, > G_OPT_SENTINEL > }, > - NULL, "[-adfFhnv] [-b balance] [-s slice] name" > + NULL, "[-adfFhnv] [-b balance] [-s slice] [-p prio] name [prov]" Style, extra space before '[-p prio]'. I also wonder if something like this should be possible: # gmirror configure -b round-robin -p 1 gm0 da0 In you current implementation it will change balance algorithm for all the providers and in addition priority of da0 provider. This doesn't look clear for my taste (will balance algorithm be changed on da0 only or on all providers?). I'd prefer: gmirror configure [-adfFhnv] [-b balance] [-s slice] name gmirror configure -p prio name prov Although I'm not sure if the infrastructure can actually print two usage patterns. > +.It Fl p Ar priority > +Specify priority for given > +.Ar prov s/for given/for the given/ ? > Index: sys/geom/mirror/g_mirror_ctl.c > =================================================================== > --- sys/geom/mirror/g_mirror_ctl.c (revision 196803) > +++ sys/geom/mirror/g_mirror_ctl.c (working copy) > @@ -93,12 +93,12 @@ > { > struct g_mirror_softc *sc; > struct g_mirror_disk *disk; > - const char *name, *balancep; > + const char *name, *balancep, *prov; > intmax_t *slicep; > uint32_t slice; > uint8_t balance; > int *autosync, *noautosync, *failsync, *nofailsync, *hardcode, *dynamic; > - int *nargs, do_sync = 0, dirty = 1; > + int *nargs, *priority, do_sync = 0, dirty = 1, do_priority = 0; > > nargs = gctl_get_paraml(req, "nargs", sizeof(*nargs)); > if (nargs == NULL) { > @@ -149,6 +149,27 @@ > gctl_error(req, "No '%s' argument.", "dynamic"); > return; > } > + priority = gctl_get_paraml(req, "priority", sizeof(*priority)); > + if (priority == NULL ) { Style, extra space after NULL. > + gctl_error(req, "No '%s' argument.", "priority"); > + return; > + } > + if( *priority < -1 || *priority > 255 ) { Style, should be: if (*priority < -1 || *priority > 255) { > + gctl_error(req, "Priority range is 0 to 255, %i given", > + *priority); > + return; > + } > + /* Since we have a priority, we also need a provider now. > + * Note: be WARNS safe, by always assigning prov and only throw an > + * error if *priority != -1. */ Style, multi-line comment should look like this: /* * Since we have a priority, we also need a provider now. * Note: be WARNS safe, by always assigning prov and only throw an * error if *priority != -1. */ > + prov = gctl_get_asciiparam(req, "arg1"); > + if( *priority > -1 ) { Style: if (*priority > -1) { > + if( prov == NULL ) { Style: if (prov == NULL) { > + gctl_error(req, "Priority needs a disk name"); > + return; > + } > + do_priority = 1; > + } > if (*autosync && *noautosync) { > gctl_error(req, "'%s' and '%s' specified.", "autosync", > "noautosync"); > @@ -233,6 +254,11 @@ > disk->d_flags &= ~G_MIRROR_DISK_FLAG_HARDCODED; > if (!dirty) > disk->d_flags &= ~G_MIRROR_DISK_FLAG_DIRTY; > + if (do_priority) { > + if (strcmp(disk->d_name, prov) == 0) { > + disk->d_priority = *priority; > + } Style, you can drop { } here: if (strcmp(disk->d_name, prov) == 0) disk->d_priority = *priority; > + } > g_mirror_update_metadata(disk); > if (do_sync) { > if (disk->d_state == G_MIRROR_DISK_STATE_STALE) { Other than those small style issues good job. Now we just have to decide about mixing per-mirror options with per-provider options. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090905/abba6ecf/attachment.pgp From mel.flynn+fbsd.fs at mailing.thruhere.net Sat Sep 5 19:11:33 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Sat Sep 5 19:11:46 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <20090905091030.GC1665@garage.freebsd.pl> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909041016.34677.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090905091030.GC1665@garage.freebsd.pl> Message-ID: <200909052111.27667.mel.flynn+fbsd.fs@mailing.thruhere.net> Hi Pawel, I'll post-process in the future. I'm so used to if( cond ), cause it allows me to more easily spot the outer bounds of the condition, it's hard to conform to style(9) for me. :) On Saturday 05 September 2009 11:10:30 Pawel Jakub Dawidek wrote: > On Fri, Sep 04, 2009 at 10:16:34AM +0200, Mel Flynn wrote: > > On Thursday 03 September 2009 15:57:41 Pawel Jakub Dawidek wrote: > > > On Thu, Sep 03, 2009 at 03:48:37PM +0200, Mel Flynn wrote: > > > > On Thursday 03 September 2009 14:44:07 Pawel Jakub Dawidek wrote: > > > > > I'd suggest doing this not as separate gmirror(8) subcommand, but > > > > > as an extension to 'configure' subcommand, where one can provide > > > > > priority by giving '-p' argument. > > > > > > > > Except I didn't see how configure was implemented. Am I correct that > > > > this is g_mirror_ctl_configure in sys/geom/mirror/g_mirror_ctl.c? > > > > > > Yes, you are correct. > > > > Ok, new patch. I gathered from configure_slice, that my assumption was > > about flag handling is correct. Patch is only compile tested. > > In general the patch looks good, although I haven't tested it yet. I do > have some comments though. > > > Index: sbin/geom/class/mirror/geom_mirror.c > > =================================================================== > > --- sbin/geom/class/mirror/geom_mirror.c (revision 196803) > > +++ sbin/geom/class/mirror/geom_mirror.c (working copy) > > @@ -47,7 +47,7 @@ > > > > static char label_balance[] = "split", configure_balance[] = "none"; > > static intmax_t label_slice = 4096, configure_slice = -1; > > -static intmax_t insert_priority = 0; > > +static intmax_t insert_priority = 0, configure_priority = -1; > > > > static void mirror_main(struct gctl_req *req, unsigned flags); > > static void mirror_activate(struct gctl_req *req); > > @@ -71,10 +71,11 @@ > > { 'F', "nofailsync", NULL, G_TYPE_BOOL }, > > { 'h', "hardcode", NULL, G_TYPE_BOOL }, > > { 'n', "noautosync", NULL, G_TYPE_BOOL }, > > + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, > > { 's', "slice", &configure_slice, G_TYPE_NUMBER }, > > G_OPT_SENTINEL > > }, > > - NULL, "[-adfFhnv] [-b balance] [-s slice] name" > > + NULL, "[-adfFhnv] [-b balance] [-s slice] [-p prio] name [prov]" > > Style, extra space before '[-p prio]'. > > I also wonder if something like this should be possible: > > # gmirror configure -b round-robin -p 1 gm0 da0 > > In you current implementation it will change balance algorithm for all > the providers and in addition priority of da0 provider. This doesn't > look clear for my taste (will balance algorithm be changed on da0 only > or on all providers?). Right, I found it convenient, but now that I think it about it, it's confusing from user perspective. > I'd prefer: > > gmirror configure [-adfFhnv] [-b balance] [-s slice] name > gmirror configure -p prio name prov > > Although I'm not sure if the infrastructure can actually print two usage > patterns. I tried two g_command structs for the same command, like so: @@ -76,6 +76,13 @@ }, NULL, "[-adfFhnv] [-b balance] [-s slice] name" }, + { "configure", G_FLAG_VERBOSE, NULL, + { + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, + G_OPT_SENTINEL + }, + NULL, "-p prio name prov" + }, { "deactivate", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, "[-v] name prov ..." }, But it errors if -p is given with illegal option, so either g_command needs to grow a second usage string, we need to do something like below, or we care less about usage and more about the man page. @@ -71,10 +71,12 @@ { 'F', "nofailsync", NULL, G_TYPE_BOOL }, { 'h', "hardcode", NULL, G_TYPE_BOOL }, { 'n', "noautosync", NULL, G_TYPE_BOOL }, + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, { 's', "slice", &configure_slice, G_TYPE_NUMBER }, G_OPT_SENTINEL }, - NULL, "[-adfFhnv] [-b balance] [-s slice] name" + NULL, "[-adfFhnv] [-b balance] [-s slice] name\n" + " gmirror configure -p priority name prov" }, { "deactivate", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, "[-v] name prov ..." Fixing style issues now and reimplementing. -- Mel From pjd at FreeBSD.org Sat Sep 5 19:23:08 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sat Sep 5 19:23:20 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <200909052111.27667.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909041016.34677.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090905091030.GC1665@garage.freebsd.pl> <200909052111.27667.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <20090905192251.GJ1665@garage.freebsd.pl> On Sat, Sep 05, 2009 at 09:11:27PM +0200, Mel Flynn wrote: > Hi Pawel, > > I'll post-process in the future. I'm so used to if( cond ), cause it allows me > to more easily spot the outer bounds of the condition, it's hard to conform to > style(9) for me. :) > > On Saturday 05 September 2009 11:10:30 Pawel Jakub Dawidek wrote: > > On Fri, Sep 04, 2009 at 10:16:34AM +0200, Mel Flynn wrote: > > > On Thursday 03 September 2009 15:57:41 Pawel Jakub Dawidek wrote: > > > > On Thu, Sep 03, 2009 at 03:48:37PM +0200, Mel Flynn wrote: > > > > > On Thursday 03 September 2009 14:44:07 Pawel Jakub Dawidek wrote: > > > > > > I'd suggest doing this not as separate gmirror(8) subcommand, but > > > > > > as an extension to 'configure' subcommand, where one can provide > > > > > > priority by giving '-p' argument. > > > > > > > > > > Except I didn't see how configure was implemented. Am I correct that > > > > > this is g_mirror_ctl_configure in sys/geom/mirror/g_mirror_ctl.c? > > > > > > > > Yes, you are correct. > > > > > > Ok, new patch. I gathered from configure_slice, that my assumption was > > > about flag handling is correct. Patch is only compile tested. > > > > In general the patch looks good, although I haven't tested it yet. I do > > have some comments though. > > > > > Index: sbin/geom/class/mirror/geom_mirror.c > > > =================================================================== > > > --- sbin/geom/class/mirror/geom_mirror.c (revision 196803) > > > +++ sbin/geom/class/mirror/geom_mirror.c (working copy) > > > @@ -47,7 +47,7 @@ > > > > > > static char label_balance[] = "split", configure_balance[] = "none"; > > > static intmax_t label_slice = 4096, configure_slice = -1; > > > -static intmax_t insert_priority = 0; > > > +static intmax_t insert_priority = 0, configure_priority = -1; > > > > > > static void mirror_main(struct gctl_req *req, unsigned flags); > > > static void mirror_activate(struct gctl_req *req); > > > @@ -71,10 +71,11 @@ > > > { 'F', "nofailsync", NULL, G_TYPE_BOOL }, > > > { 'h', "hardcode", NULL, G_TYPE_BOOL }, > > > { 'n', "noautosync", NULL, G_TYPE_BOOL }, > > > + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, > > > { 's', "slice", &configure_slice, G_TYPE_NUMBER }, > > > G_OPT_SENTINEL > > > }, > > > - NULL, "[-adfFhnv] [-b balance] [-s slice] name" > > > + NULL, "[-adfFhnv] [-b balance] [-s slice] [-p prio] name [prov]" > > > > Style, extra space before '[-p prio]'. > > > > I also wonder if something like this should be possible: > > > > # gmirror configure -b round-robin -p 1 gm0 da0 > > > > In you current implementation it will change balance algorithm for all > > the providers and in addition priority of da0 provider. This doesn't > > look clear for my taste (will balance algorithm be changed on da0 only > > or on all providers?). > > Right, I found it convenient, but now that I think it about it, it's confusing > from user perspective. > > > I'd prefer: > > > > gmirror configure [-adfFhnv] [-b balance] [-s slice] name > > gmirror configure -p prio name prov > > > > Although I'm not sure if the infrastructure can actually print two usage > > patterns. > > I tried two g_command structs for the same command, like so: > @@ -76,6 +76,13 @@ > }, > NULL, "[-adfFhnv] [-b balance] [-s slice] name" > }, > + { "configure", G_FLAG_VERBOSE, NULL, > + { > + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, > + G_OPT_SENTINEL > + }, > + NULL, "-p prio name prov" > + }, > { "deactivate", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, > "[-v] name prov ..." > }, > > But it errors if -p is given with illegal option, so either g_command needs to > grow a second usage string, we need to do something like below, or we care > less about usage and more about the man page. > > @@ -71,10 +71,12 @@ > { 'F', "nofailsync", NULL, G_TYPE_BOOL }, > { 'h', "hardcode", NULL, G_TYPE_BOOL }, > { 'n', "noautosync", NULL, G_TYPE_BOOL }, > + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, > { 's', "slice", &configure_slice, G_TYPE_NUMBER }, > G_OPT_SENTINEL > }, > - NULL, "[-adfFhnv] [-b balance] [-s slice] name" > + NULL, "[-adfFhnv] [-b balance] [-s slice] name\n" > + " gmirror configure -p priority name prov" We could also do the following: NULL, "[-adfFhnv] [-b balance] [-s slice] name\n" "-p priority name prov" And tech core geom(8) utility to split usage based on \n. usage_command() function from sbin/geom/core/geom.c would have to be modified. If you agree with this idea, would you also like to work on this? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090905/6e2fc844/attachment.pgp From mel.flynn+fbsd.fs at mailing.thruhere.net Sat Sep 5 20:25:09 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Sat Sep 5 20:25:19 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <20090905192251.GJ1665@garage.freebsd.pl> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909052111.27667.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090905192251.GJ1665@garage.freebsd.pl> Message-ID: <200909052225.06185.mel.flynn+fbsd.fs@mailing.thruhere.net> On Saturday 05 September 2009 21:22:51 Pawel Jakub Dawidek wrote: > And tech core geom(8) utility to split usage based on \n. > usage_command() function from sbin/geom/core/geom.c would have to be > modified. If you agree with this idea, would you also like to work on > this? Yes and see attached. Since utility exists after displaying usage, I didn't take the trouble of freeing ptr, but if this is preferred then I'll add the line. % geom mirror foo geom: Unknown command: foo. usage: geom mirror activate [-v] name prov ... geom mirror clear [-v] prov ... geom mirror configure[-adfFhnv] [-b balance] [-s slice] name geom mirror configure -p priority name prov -- Mel -------------- next part -------------- Index: sbin/geom/core/geom.c =================================================================== --- sbin/geom/core/geom.c (revision 196868) +++ sbin/geom/core/geom.c (working copy) @@ -98,11 +98,23 @@ struct g_option *opt; unsigned i; - fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); if (cmd->gc_usage != NULL) { - fprintf(stderr, " %s\n", cmd->gc_usage); + char *pos, *ptr; + + ptr = strdup(cmd->gc_usage); + while ((pos = strchr(ptr, '\n')) != NULL) { + *pos = '\0'; + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); + fprintf(stderr, "%s\n", ptr); + ptr = pos + 1; + } + /* Tail or no \n at all */ + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); + fprintf(stderr, " %s\n", ptr); return; } + + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); if ((cmd->gc_flags & G_FLAG_VERBOSE) != 0) fprintf(stderr, " [-v]"); for (i = 0; ; i++) { From pjd at FreeBSD.org Sat Sep 5 20:36:00 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sat Sep 5 20:36:12 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <200909052225.06185.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909052111.27667.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090905192251.GJ1665@garage.freebsd.pl> <200909052225.06185.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <20090905203551.GK1665@garage.freebsd.pl> On Sat, Sep 05, 2009 at 10:25:05PM +0200, Mel Flynn wrote: > On Saturday 05 September 2009 21:22:51 Pawel Jakub Dawidek wrote: > > > And tech core geom(8) utility to split usage based on \n. > > usage_command() function from sbin/geom/core/geom.c would have to be > > modified. If you agree with this idea, would you also like to work on > > this? > > Yes and see attached. Since utility exists after displaying usage, I didn't > take the trouble of freeing ptr, but if this is preferred then I'll add the > line. I think it would be good to free memory just to make it elegant. > % geom mirror foo > geom: Unknown command: foo. > usage: geom mirror activate [-v] name prov ... > geom mirror clear [-v] prov ... > geom mirror configure[-adfFhnv] [-b balance] [-s slice] name > geom mirror configure -p priority name prov > > -- > Mel > Index: sbin/geom/core/geom.c > =================================================================== > --- sbin/geom/core/geom.c (revision 196868) > +++ sbin/geom/core/geom.c (working copy) > @@ -98,11 +98,23 @@ > struct g_option *opt; > unsigned i; > > - fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > if (cmd->gc_usage != NULL) { > - fprintf(stderr, " %s\n", cmd->gc_usage); > + char *pos, *ptr; > + > + ptr = strdup(cmd->gc_usage); > + while ((pos = strchr(ptr, '\n')) != NULL) { Wouldn't it be easier to use strsep(3)? > + *pos = '\0'; > + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > + fprintf(stderr, "%s\n", ptr); Why to split this into two fprintfs? There is also space missing before %s. > + ptr = pos + 1; > + } > + /* Tail or no \n at all */ > + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > + fprintf(stderr, " %s\n", ptr); > return; > } > + > + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > if ((cmd->gc_flags & G_FLAG_VERBOSE) != 0) > fprintf(stderr, " [-v]"); > for (i = 0; ; i++) { With strsep(3) it would look like this: if (cmd->gc_usage != NULL) { char *cur, *ptr, *tofree; tofree = ptr = strdup(cmd->gc_usage); while ((cur = strsep(&ptr, "\n")) != NULL) { if (*cur == '\0') continue; fprintf(stderr, "%s %s %s %s\n", prefix, comm, cmd->gc_name, cur); } free(tofree); return; } -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090905/f1631f7e/attachment.pgp From mel.flynn+fbsd.fs at mailing.thruhere.net Sun Sep 6 00:36:16 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Sun Sep 6 00:36:23 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <20090905192251.GJ1665@garage.freebsd.pl> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909052111.27667.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090905192251.GJ1665@garage.freebsd.pl> Message-ID: <200909060236.11224.mel.flynn+fbsd.fs@mailing.thruhere.net> Hi, new patch containing everything and points for elegance. Double checked for style, so I'm sure there's one or two left ;). Since it's applies nearly clean (1 hunk -6 lines offset) on 7-STABLE, I can runtime test it tomorrow (tonight is lvl 0 backup). -- Mel -------------- next part -------------- Index: sys/geom/mirror/g_mirror_ctl.c =================================================================== --- sys/geom/mirror/g_mirror_ctl.c (revision 196868) +++ sys/geom/mirror/g_mirror_ctl.c (working copy) @@ -93,12 +93,12 @@ { struct g_mirror_softc *sc; struct g_mirror_disk *disk; - const char *name, *balancep; + const char *name, *balancep, *prov; intmax_t *slicep; uint32_t slice; uint8_t balance; int *autosync, *noautosync, *failsync, *nofailsync, *hardcode, *dynamic; - int *nargs, do_sync = 0, dirty = 1; + int *nargs, *priority, do_sync = 0, dirty = 1, do_priority = 0; nargs = gctl_get_paraml(req, "nargs", sizeof(*nargs)); if (nargs == NULL) { @@ -149,6 +149,29 @@ gctl_error(req, "No '%s' argument.", "dynamic"); return; } + priority = gctl_get_paraml(req, "priority", sizeof(*priority)); + if (priority == NULL) { + gctl_error(req, "No '%s' argument.", "priority"); + return; + } + if (*priority < -1 || *priority > 255) { + gctl_error(req, "Priority range is 0 to 255, %i given", + *priority); + return; + } + /* + * Since we have a priority, we also need a provider now. + * Note: be WARNS safe, by always assigning prov and only throw an + * error if *priority != -1. + */ + prov = gctl_get_asciiparam(req, "arg1"); + if (*priority > -1) { + if (prov == NULL) { + gctl_error(req, "Priority needs a disk name"); + return; + } + do_priority = 1; + } if (*autosync && *noautosync) { gctl_error(req, "'%s' and '%s' specified.", "autosync", "noautosync"); @@ -189,6 +212,14 @@ slice = sc->sc_slice; else slice = *slicep; + /* Enforce usage() of -p not allowing any other options */ + if (do_priority && (*autosync || *noautosync || *failsync || + *nofailsync || *hardcode || *dynamic || *slicep != -1 || + (strcmp(balancep, "none")))) { + gctl_error(req, "only -p accepted when setting priority"); + sx_xunlock(&sc->sc_lock); + return; + } if (g_mirror_ndisks(sc, -1) < sc->sc_ndisks) { sx_xunlock(&sc->sc_lock); gctl_error(req, "Not all disks connected. Try 'forget' command " @@ -197,7 +228,7 @@ } if (sc->sc_balance == balance && sc->sc_slice == slice && !*autosync && !*noautosync && !*failsync && !*nofailsync && !*hardcode && - !*dynamic) { + !*dynamic && !do_priority) { sx_xunlock(&sc->sc_lock); gctl_error(req, "Nothing has changed."); return; @@ -223,6 +254,19 @@ } } LIST_FOREACH(disk, &sc->sc_disks, d_next) { + /* + * Handle priority first, since we only need one disk, do one + * operation on it and then we're done. No need to check other + * flags, as usage doesn't allow it. + */ + if (do_priority) { + if (strcmp(disk->d_name, prov) == 0) { + disk->d_priority = *priority; + g_mirror_update_metadata(disk); + break; + } + continue; + } if (do_sync) { if (disk->d_state == G_MIRROR_DISK_STATE_SYNCHRONIZING) disk->d_flags &= ~G_MIRROR_DISK_FLAG_FORCE_SYNC; Index: sbin/geom/core/geom.c =================================================================== --- sbin/geom/core/geom.c (revision 196868) +++ sbin/geom/core/geom.c (working copy) @@ -98,11 +98,25 @@ struct g_option *opt; unsigned i; - fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); if (cmd->gc_usage != NULL) { - fprintf(stderr, " %s\n", cmd->gc_usage); + char *pos, *ptr, *sptr; + + ptr = strdup(cmd->gc_usage); + sptr = ptr; + while ((pos = strchr(ptr, '\n')) != NULL) { + *pos = '\0'; + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); + fprintf(stderr, "%s\n", ptr); + ptr = pos + 1; + } + /* Tail or no \n at all */ + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); + fprintf(stderr, " %s\n", ptr); + free(sptr); return; } + + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); if ((cmd->gc_flags & G_FLAG_VERBOSE) != 0) fprintf(stderr, " [-v]"); for (i = 0; ; i++) { Index: sbin/geom/class/mirror/geom_mirror.c =================================================================== --- sbin/geom/class/mirror/geom_mirror.c (revision 196868) +++ sbin/geom/class/mirror/geom_mirror.c (working copy) @@ -47,7 +47,7 @@ static char label_balance[] = "split", configure_balance[] = "none"; static intmax_t label_slice = 4096, configure_slice = -1; -static intmax_t insert_priority = 0; +static intmax_t insert_priority = 0, configure_priority = -1; static void mirror_main(struct gctl_req *req, unsigned flags); static void mirror_activate(struct gctl_req *req); @@ -71,10 +71,12 @@ { 'F', "nofailsync", NULL, G_TYPE_BOOL }, { 'h', "hardcode", NULL, G_TYPE_BOOL }, { 'n', "noautosync", NULL, G_TYPE_BOOL }, + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, { 's', "slice", &configure_slice, G_TYPE_NUMBER }, G_OPT_SENTINEL }, - NULL, "[-adfFhnv] [-b balance] [-s slice] name" + NULL, "[-adfFhnv] [-b balance] [-s slice] name\n" + "-p priority name prov" }, { "deactivate", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, "[-v] name prov ..." Index: sbin/geom/class/mirror/gmirror.8 =================================================================== --- sbin/geom/class/mirror/gmirror.8 (revision 196868) +++ sbin/geom/class/mirror/gmirror.8 (working copy) @@ -49,6 +49,12 @@ .Op Fl s Ar slice .Ar name .Nm +.Cm configure +.Op Fl v +.Fl p Ar priority +.Ar name +.Ar prov +.Nm .Cm rebuild .Op Fl v .Ar name @@ -115,8 +121,8 @@ .It Cm label Create a mirror. The order of components is important, because a component's priority is based on its position -(starting from 0). -The component with the biggest priority is used by the +(starting from 0 to 255). +The component with the biggest priority (the lowest number) is used by the .Cm prefer balance algorithm and is also used as a master component when resynchronization is needed, @@ -175,6 +181,9 @@ Hardcode providers' names in metadata. .It Fl n Turn off autosynchronization of stale components. +.It Fl p Ar priority +Specifies priority for the given component +.Ar prov . .It Fl s Ar slice Specifies slice size for .Cm split From mel.flynn+fbsd.fs at mailing.thruhere.net Sun Sep 6 00:56:07 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Sun Sep 6 00:56:18 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <200909060236.11224.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090905192251.GJ1665@garage.freebsd.pl> <200909060236.11224.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <200909060256.04013.mel.flynn+fbsd.fs@mailing.thruhere.net> On Sunday 06 September 2009 02:36:10 Mel Flynn wrote: > Hi, > > new patch containing everything and points for elegance. Double checked for > style, so I'm sure there's one or two left ;). > > Since it's applies nearly clean (1 hunk -6 lines offset) on 7-STABLE, I can > runtime test it tomorrow (tonight is lvl 0 backup). Ack, totally missed your strsep comments, strike this one and yes I should've used that. Will redo when it's not 3am in the morning anymore. ;) -- Mel From pjd at FreeBSD.org Sun Sep 6 06:52:25 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Sep 6 06:52:32 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <200909060236.11224.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909052111.27667.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090905192251.GJ1665@garage.freebsd.pl> <200909060236.11224.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <20090906065217.GL1665@garage.freebsd.pl> On Sun, Sep 06, 2009 at 02:36:10AM +0200, Mel Flynn wrote: > Hi, > > new patch containing everything and points for elegance. Double checked for > style, so I'm sure there's one or two left ;). Yeah:) I'll fixed what's left by myself and tested it. With few little changes it works fine, good job. Below, for the record, you can find what I changed. Patch committed. > Since it's applies nearly clean (1 hunk -6 lines offset) on 7-STABLE, I can > runtime test it tomorrow (tonight is lvl 0 backup). > Index: sys/geom/mirror/g_mirror_ctl.c > =================================================================== > --- sys/geom/mirror/g_mirror_ctl.c (revision 196868) > +++ sys/geom/mirror/g_mirror_ctl.c (working copy) > @@ -93,12 +93,12 @@ > { > struct g_mirror_softc *sc; > struct g_mirror_disk *disk; > - const char *name, *balancep; > + const char *name, *balancep, *prov; > intmax_t *slicep; > uint32_t slice; > uint8_t balance; > int *autosync, *noautosync, *failsync, *nofailsync, *hardcode, *dynamic; > - int *nargs, do_sync = 0, dirty = 1; > + int *nargs, *priority, do_sync = 0, dirty = 1, do_priority = 0; priority should be 'intmax_t *' here. > nargs = gctl_get_paraml(req, "nargs", sizeof(*nargs)); > if (nargs == NULL) { We need to accept 1 or 2 arguments few lines below. > @@ -149,6 +149,29 @@ > gctl_error(req, "No '%s' argument.", "dynamic"); > return; > } > + priority = gctl_get_paraml(req, "priority", sizeof(*priority)); > + if (priority == NULL) { > + gctl_error(req, "No '%s' argument.", "priority"); > + return; > + } > + if (*priority < -1 || *priority > 255) { > + gctl_error(req, "Priority range is 0 to 255, %i given", %d instead of %i for consistency. > + *priority); > + return; > + } > + /* > + * Since we have a priority, we also need a provider now. > + * Note: be WARNS safe, by always assigning prov and only throw an > + * error if *priority != -1. > + */ > + prov = gctl_get_asciiparam(req, "arg1"); > + if (*priority > -1) { > + if (prov == NULL) { > + gctl_error(req, "Priority needs a disk name"); > + return; > + } > + do_priority = 1; > + } > if (*autosync && *noautosync) { > gctl_error(req, "'%s' and '%s' specified.", "autosync", > "noautosync"); > @@ -189,6 +212,14 @@ > slice = sc->sc_slice; > else > slice = *slicep; > + /* Enforce usage() of -p not allowing any other options */ Missing '.' at the end of the sentence. > + if (do_priority && (*autosync || *noautosync || *failsync || > + *nofailsync || *hardcode || *dynamic || *slicep != -1 || > + (strcmp(balancep, "none")))) { One tab too much. strcmp() returns int, not bool, so we have to check it against 0. Extra () around strcmp(). > + gctl_error(req, "only -p accepted when setting priority"); > + sx_xunlock(&sc->sc_lock); There's no need to hold the lock during gctl_error(). > + return; > + } > if (g_mirror_ndisks(sc, -1) < sc->sc_ndisks) { > sx_xunlock(&sc->sc_lock); > gctl_error(req, "Not all disks connected. Try 'forget' command " > @@ -197,7 +228,7 @@ > } > if (sc->sc_balance == balance && sc->sc_slice == slice && !*autosync && > !*noautosync && !*failsync && !*nofailsync && !*hardcode && > - !*dynamic) { > + !*dynamic && !do_priority) { > sx_xunlock(&sc->sc_lock); > gctl_error(req, "Nothing has changed."); > return; I also added the following check: if ((!do_priority && *nargs != 1) || (do_priority && *nargs != 2)) { sx_xunlock(&sc->sc_lock); gctl_error(req, "Invalid number of arguments."); return; } > @@ -223,6 +254,19 @@ > } > } > LIST_FOREACH(disk, &sc->sc_disks, d_next) { > + /* > + * Handle priority first, since we only need one disk, do one > + * operation on it and then we're done. No need to check other > + * flags, as usage doesn't allow it. > + */ > + if (do_priority) { > + if (strcmp(disk->d_name, prov) == 0) { > + disk->d_priority = *priority; > + g_mirror_update_metadata(disk); > + break; > + } To be consistent with other option I changed it to: if (strcmp(disk->d_name, prov) == 0) { if (disk->d_priority == *priority) gctl_error(req, "Nothing has changed."); else { disk->d_priority = *priority; g_mirror_update_metadata(disk); } break; } > + continue; > + } > if (do_sync) { > if (disk->d_state == G_MIRROR_DISK_STATE_SYNCHRONIZING) > disk->d_flags &= ~G_MIRROR_DISK_FLAG_FORCE_SYNC; > Index: sbin/geom/core/geom.c > =================================================================== > --- sbin/geom/core/geom.c (revision 196868) > +++ sbin/geom/core/geom.c (working copy) > @@ -98,11 +98,25 @@ > struct g_option *opt; > unsigned i; > > - fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > if (cmd->gc_usage != NULL) { > - fprintf(stderr, " %s\n", cmd->gc_usage); > + char *pos, *ptr, *sptr; > + > + ptr = strdup(cmd->gc_usage); > + sptr = ptr; > + while ((pos = strchr(ptr, '\n')) != NULL) { > + *pos = '\0'; > + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > + fprintf(stderr, "%s\n", ptr); We need a space between cmd->gc_name and ptr here. > + ptr = pos + 1; > + } > + /* Tail or no \n at all */ > + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > + fprintf(stderr, " %s\n", ptr); > + free(sptr); I went with strsep(3) version I proposed, I think you missed it. > return; > } > + > + fprintf(stderr, "%s %s %s", prefix, comm, cmd->gc_name); > if ((cmd->gc_flags & G_FLAG_VERBOSE) != 0) > fprintf(stderr, " [-v]"); > for (i = 0; ; i++) { > Index: sbin/geom/class/mirror/geom_mirror.c > =================================================================== > --- sbin/geom/class/mirror/geom_mirror.c (revision 196868) > +++ sbin/geom/class/mirror/geom_mirror.c (working copy) > @@ -47,7 +47,7 @@ > > static char label_balance[] = "split", configure_balance[] = "none"; > static intmax_t label_slice = 4096, configure_slice = -1; > -static intmax_t insert_priority = 0; > +static intmax_t insert_priority = 0, configure_priority = -1; > > static void mirror_main(struct gctl_req *req, unsigned flags); > static void mirror_activate(struct gctl_req *req); > @@ -71,10 +71,12 @@ > { 'F', "nofailsync", NULL, G_TYPE_BOOL }, > { 'h', "hardcode", NULL, G_TYPE_BOOL }, > { 'n', "noautosync", NULL, G_TYPE_BOOL }, > + { 'p', "priority", &configure_priority, G_TYPE_NUMBER }, > { 's', "slice", &configure_slice, G_TYPE_NUMBER }, > G_OPT_SENTINEL > }, > - NULL, "[-adfFhnv] [-b balance] [-s slice] name" > + NULL, "[-adfFhnv] [-b balance] [-s slice] name\n" > + "-p priority name prov" I added '[-v]' here as it i a valid option. > }, > { "deactivate", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, NULL, > "[-v] name prov ..." > Index: sbin/geom/class/mirror/gmirror.8 > =================================================================== > --- sbin/geom/class/mirror/gmirror.8 (revision 196868) > +++ sbin/geom/class/mirror/gmirror.8 (working copy) > @@ -49,6 +49,12 @@ > .Op Fl s Ar slice > .Ar name > .Nm > +.Cm configure > +.Op Fl v > +.Fl p Ar priority > +.Ar name > +.Ar prov > +.Nm > .Cm rebuild > .Op Fl v > .Ar name > @@ -115,8 +121,8 @@ > .It Cm label > Create a mirror. > The order of components is important, because a component's priority is based on its position > -(starting from 0). > -The component with the biggest priority is used by the > +(starting from 0 to 255). > +The component with the biggest priority (the lowest number) is used by the > .Cm prefer > balance algorithm > and is also used as a master component when resynchronization is needed, > @@ -175,6 +181,9 @@ We also need: -.Bl -tag -width ".Fl b Ar balance" +.Bl -tag -width ".Fl p Ar priority" > Hardcode providers' names in metadata. > .It Fl n > Turn off autosynchronization of stale components. > +.It Fl p Ar priority > +Specifies priority for the given component > +.Ar prov . > .It Fl s Ar slice > Specifies slice size for > .Cm split -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090906/2355b9f4/attachment.pgp From mel.flynn+fbsd.fs at mailing.thruhere.net Sun Sep 6 08:17:10 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Sun Sep 6 08:17:22 2009 Subject: Patch to allow gmirror to set priority of a disk In-Reply-To: <20090906065217.GL1665@garage.freebsd.pl> References: <200909030000.11961.mel.flynn+fbsd.fs@mailing.thruhere.net> <200909060236.11224.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090906065217.GL1665@garage.freebsd.pl> Message-ID: <200909061017.05990.mel.flynn+fbsd.fs@mailing.thruhere.net> On Sunday 06 September 2009 08:52:17 you wrote: > On Sun, Sep 06, 2009 at 02:36:10AM +0200, Mel Flynn wrote: > > Hi, > > > > new patch containing everything and points for elegance. Double checked > > for style, so I'm sure there's one or two left ;). > > Yeah:) I'll fixed what's left by myself and tested it. With few little > changes it works fine, good job. Below, for the record, you can find > what I changed. Patch committed. Thank you very much! And now you got me thinking about allowing and enforcing two usage patterns of the same command in the core geom, so that the enforcement can be stripped out of command implementations. But I'll leave that for a time when this is not the only consumer of that logic. This has nonetheless been a welcome learning experience. -- Mel From linimon at FreeBSD.org Sun Sep 6 18:28:12 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Sep 6 18:28:23 2009 Subject: kern/138524: [msdosfs] disks and usb flashes/cards with Russian labels produces hangups Message-ID: <200909061828.n86ISB0s057164@freefall.freebsd.org> Old Synopsis: disks and usb flashes/cards with Russian labels produces hangups New Synopsis: [msdosfs] disks and usb flashes/cards with Russian labels produces hangups Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 6 18:27:53 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138524 From linimon at FreeBSD.org Sun Sep 6 18:30:54 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Sep 6 18:31:06 2009 Subject: kern/138537: [zfs] [panic] Memory modified after free Message-ID: <200909061830.n86IUsZP065088@freefall.freebsd.org> Old Synopsis: [panic] Memory modified after free New Synopsis: [zfs] [panic] Memory modified after free Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 6 18:30:13 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138537 From pjd at FreeBSD.org Sun Sep 6 22:47:18 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Sep 6 22:47:24 2009 Subject: kern/138537: [zfs] [panic] Memory modified after free In-Reply-To: <200909061830.n86IUsZP065088@freefall.freebsd.org> References: <200909061830.n86IUsZP065088@freefall.freebsd.org> Message-ID: <20090906224710.GO1665@garage.freebsd.pl> On Sun, Sep 06, 2009 at 06:30:54PM +0000, linimon@FreeBSD.org wrote: > Old Synopsis: [panic] Memory modified after free > New Synopsis: [zfs] [panic] Memory modified after free Mark, this doesn't look like ZFS panic. Only memory allocation in ZFS code discovered that memory was used after free. It is most likely related to ATA errors handling. > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun Sep 6 18:30:13 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090906/12456d6e/attachment.pgp From bruce at cran.org.uk Mon Sep 7 02:50:02 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Mon Sep 7 02:50:09 2009 Subject: kern/127213: [tmpfs] sendfile on tmpfs data corruption Message-ID: <200909070250.n872o2MW071464@freefall.freebsd.org> The following reply was made to PR kern/127213; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, citrin@citrin.ru Cc: Subject: Re: kern/127213: [tmpfs] sendfile on tmpfs data corruption Date: Mon, 7 Sep 2009 03:41:11 +0100 I've submitted the PR kern/138465 which contains a patch to tools/regression/sockets/sendfile which adds an MD5 field to the header structure; when all the data has been received the MD5 is recalculated and the test fails if they differ. As expected it fails when /tmp is a tmpfs filesystem. -- Bruce From linimon at FreeBSD.org Mon Sep 7 08:42:50 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 7 08:42:56 2009 Subject: kern/138537: [ata] [panic] Memory modified after free Message-ID: <200909070842.n878gn2x070451@freefall.freebsd.org> Old Synopsis: [zfs] [panic] Memory modified after free New Synopsis: [ata] [panic] Memory modified after free Responsible-Changed-From-To: freebsd-fs->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 7 08:42:07 UTC 2009 Responsible-Changed-Why: pjd says this is probably a problem in the ata driver that just happens to be detected by zfs. http://www.freebsd.org/cgi/query-pr.cgi?pr=138537 From bugmaster at FreeBSD.org Mon Sep 7 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 7 11:07:52 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200909071106.n87B6wJO010207@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138476 fs [panic] [sshfs] [fuse] Almost regular panic during VFS o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138367 fs [tmpfs] [panic] 'panic: Assertion pages > 0 failed' wh o kern/138244 fs [zfs] dd(1) attempts bitwise transfer onto ZFS pool o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/138109 fs [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2f f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136942 fs [zfs] zvol resize not reflected until reboot o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/136218 fs [zfs] Exported ZFS pools can't be imported into (Open) o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135480 fs [zfs] panic: lock &arg.lock already initialized o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o bin/135314 fs [zfs] assertion failed for zdb(8) usage o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot f kern/134496 fs [zfs] [panic] ZFS pool export occasionally causes a ke o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/133134 fs [zfs] Missing ZFS zpool labels o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132551 fs [zfs] ZFS locks up on extattr_list_link syscall o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129148 fs [zfs] [panic] panic on concurrent writing & rollback o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs o kern/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127492 fs [zfs] System hang on ZFS input-output o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/125644 fs [zfs] [panic] zfs unfixable fs errors caused panic whe f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs] [panic] changing into .zfs dir from nfs client c f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o kern/122173 fs [zfs] [panic] Kernel Panic if attempting to replace a o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122047 fs [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / o kern/122038 fs [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o kern/121770 fs [zfs] ZFS on i386, large file or heavy I/O leads to ke o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o bin/120288 fs zfs(8): "zfs share -a" does not send SIGHUP to mountd f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o misc/118855 fs [zfs] ZFS-related commands are nonfunctional in fixit o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118320 fs [zfs] [patch] NFS SETATTR sometimes fails to set file o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o kern/113180 fs [zfs] Setting ZFS nfsshare property does not cause inh o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/105093 fs [ext2fs] [patch] ext2fs on read-only media cannot be m o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/77826 fs [ext2fs] ext2fs usb filesystem will not mount RW o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 157 problems total. From pjd at FreeBSD.org Mon Sep 7 11:39:19 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 7 11:39:25 2009 Subject: kern/135480: [zfs] panic: lock &arg.lock already initialized Message-ID: <200909071139.n87BdINo047408@freefall.freebsd.org> Synopsis: [zfs] panic: lock &arg.lock already initialized State-Changed-From-To: open->patched State-Changed-By: pjd State-Changed-When: pon 7 wrz 2009 11:38:59 UTC State-Changed-Why: Fix committed to HEAD. Thanks for the report! http://www.freebsd.org/cgi/query-pr.cgi?pr=135480 From pjd at FreeBSD.org Mon Sep 7 11:39:37 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 7 11:39:44 2009 Subject: kern/135480: [zfs] panic: lock &arg.lock already initialized Message-ID: <200909071139.n87BdbSO047458@freefall.freebsd.org> Synopsis: [zfs] panic: lock &arg.lock already initialized Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 7 wrz 2009 11:39:26 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=135480 From pjd at FreeBSD.org Mon Sep 7 11:43:41 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Sep 7 11:43:46 2009 Subject: kern/137037: [zfs] [hang] zfs rollback on root causes FreeBSD to freeze in few seconds In-Reply-To: <200908120538.n7C5cAUF046203@freefall.freebsd.org> References: <200908120538.n7C5cAUF046203@freefall.freebsd.org> Message-ID: <20090907114336.GH1659@garage.freebsd.pl> On Wed, Aug 12, 2009 at 05:38:10AM +0000, pjd@FreeBSD.org wrote: > Note that rollback of root file system is impossible to do on-line anyway. > Rollback will modify data on your root file system and because of that > file system being rolled back has to be unmounted and mounted with new data. > You shouldn't be able to unmount root file system anyway. Actually I was wrong here. Rollback is possible on a mounted file system, it doesn't need to unmount file system, but it is still a risky game. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090907/70bbe1e7/attachment.pgp From pjd at FreeBSD.org Mon Sep 7 11:53:28 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 7 11:53:35 2009 Subject: kern/138244: [zfs] dd(1) attempts bitwise transfer onto ZFS pool Message-ID: <200909071153.n87BrRPc066070@freefall.freebsd.org> Synopsis: [zfs] dd(1) attempts bitwise transfer onto ZFS pool State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: pon 7 wrz 2009 11:46:04 UTC State-Changed-Why: I'm sorry, but I don't really understand what you described. What do you mean by 'bitwise transfer'? Writing to raw block device like /dev/da0? What do you mean by zvolume? I think you mean raw device used as pool component, but in ZFS terminology zvolume (ZVOL) is something different. What do you mean by 'bit level copying onto a zpool'? zpool is not a block device. Do you mean copying to /pool/ directory or block device which is pool component? Could you show example commands you were trying to use, your pool configuration, etc.? If you ment to do something like 'dd if=/dev/zero of=/dev/da0' where da0 is pool component (a vdev in ZFS terminology) then it should be denied by GEOM, as da0 should be already opened for writing by ZFS and dd(1) shouldn't be able to open it for writing at all. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 7 wrz 2009 11:46:04 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=138244 From pjd at FreeBSD.org Mon Sep 7 14:19:51 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 7 14:19:59 2009 Subject: kern/136942: [zfs] zvol resize not reflected until reboot Message-ID: <200909071419.n87EJpUx005309@freefall.freebsd.org> Synopsis: [zfs] zvol resize not reflected until reboot State-Changed-From-To: open->patched State-Changed-By: pjd State-Changed-When: pon 7 wrz 2009 14:17:00 UTC State-Changed-Why: I committed a change that should allow to change ZVOL size. Note that GEOM doesn't really support changing provider's size, so if ZVOL is open we will wait for the last close and then change the size. BTW. There are two undocumented commands to initialize and remove ZVOLs: # zfs volinit # zfs volfini Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 7 wrz 2009 14:17:00 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=136942 From pjd at FreeBSD.org Mon Sep 7 14:45:09 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 7 14:45:16 2009 Subject: kern/133134: [zfs] Missing ZFS zpool labels Message-ID: <200909071445.n87Ej8Np035339@freefall.freebsd.org> Synopsis: [zfs] Missing ZFS zpool labels State-Changed-From-To: open->patched State-Changed-By: pjd State-Changed-When: pon 7 wrz 2009 14:44:14 UTC State-Changed-Why: zdb(8) wasn't able to obtain GEOM provider size. I committed a fix to HEAD. Thanks for the report! Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 7 wrz 2009 14:44:14 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=133134 From pjd at FreeBSD.org Mon Sep 7 15:30:06 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Sep 7 15:30:13 2009 Subject: bin/121366: [zfs] [patch] Automatic disk scrubbing from periodic(8) Message-ID: <200909071530.n87FU3ZZ074201@freefall.freebsd.org> The following reply was made to PR bin/121366; it has been noted by GNATS. From: Pawel Jakub Dawidek To: Stefan Moeding Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: bin/121366: [zfs] [patch] Automatic disk scrubbing from periodic(8) Date: Mon, 7 Sep 2009 16:58:05 +0200 --QxIEt88oQPsT6QmF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 04, 2008 at 08:46:51PM +0100, Stefan Moeding wrote: >=20 > >Number: 121366 > >Category: bin > >Synopsis: [zfs] [patch] Automatic disk scrubbing from periodic(8) > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-bugs > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Tue Mar 04 20:10:01 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: Stefan Moeding > >Release: FreeBSD 7.0-STABLE i386 > >Organization: > >Environment: > System: FreeBSD elan.setuid.de 7.0-STABLE FreeBSD 7.0-STABLE #23: Sat Mar= 1 14:17:18 CET 2008 root@elan.setuid.de:/usr/obj/usr/src/sys/ELAN i386 > >Description: >=20 > The ZFS Best Practices Guide recommends disk scrubbing on a regular > basis. The attached file fits into the periodic(8) framework to start > a weekly scrub. It will look at all pools and choose one of them on a > round-robin basis depending on the date of the last scrub/resilver > unless there is already a scrub or resilver running. >=20 > The script should probably be installed to run at the end the weekly > schedule to avoid I/O contention from scrubbing and other weekly scripts. >=20 > The new periodic(8) switch 'weekly_zfs_scrubbing_enable' is introduced. >=20 > One drawback: ZFS seems to forget the time of a scrub/resilver when > shutting down. On machines with regular reboots and multiple pools > the script will probably pick the same pool every time. Maybe you can use user properties to remember time of last automatic scrub? A user property has to contain ':' in its name, eg.: # zfs set org.freebsd:lastscrub=3D`date "+%s"` pool # zpool scrub pool You can obtain it later with: # zfs get -H -o value org.freebsd:lastscrub system It can be removed (if needed) with: # zfs inherit org.freebsd:lastscrub system If you like the idea, would you also like to update your script to use it? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --QxIEt88oQPsT6QmF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKpR99ForvXbEpPzQRAhgUAKCIg4jTPS83dMl615OUAvaPo6wYygCfdYLF IWU96OveYlgKxRtKQZhyTlQ= =b6uu -----END PGP SIGNATURE----- --QxIEt88oQPsT6QmF-- From samuel at boivie.org Mon Sep 7 19:30:05 2009 From: samuel at boivie.org (Samuel Boivie) Date: Mon Sep 7 19:30:10 2009 Subject: kern/122888: [zfs] zfs hang w/ prefetch on, zil off while running transmission-daemon Message-ID: <200909071930.n87JU45H026616@freefall.freebsd.org> The following reply was made to PR kern/122888; it has been noted by GNATS. From: Samuel Boivie To: bug-followup@freebsd.org, jbsnyder@gmail.com Cc: Subject: Re: kern/122888: [zfs] zfs hang w/ prefetch on, zil off while running transmission-daemon Date: Mon, 7 Sep 2009 21:12:29 +0200 I'm seeing the same behavior using ktorrent on 8.0 beta3 amd64 without tuning. Workaround is good. From pjd at FreeBSD.org Mon Sep 7 20:12:54 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 7 20:13:00 2009 Subject: bin/120288: zfs(8): "zfs share -a" does not send SIGHUP to mountd Message-ID: <200909072012.n87KCr18075634@freefall.freebsd.org> Synopsis: zfs(8): "zfs share -a" does not send SIGHUP to mountd State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: pon 7 wrz 2009 20:10:46 UTC State-Changed-Why: I think the problem you were seeing was related to bug in pidfile(3), which was fixed some time ago. There was also another bug in detecting if file system is shared which I just fixed. Now the following commands should properly remove file systems from the 'showmount -e' output: # zfs unshare -a # zfs destroy foo/bar # zfs rename foo/bar foo/baz Thanks for the report! Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 7 wrz 2009 20:10:46 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=120288 From pjd at FreeBSD.org Mon Sep 7 20:17:59 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 7 20:18:05 2009 Subject: kern/113180: [zfs] Setting ZFS nfsshare property does not cause inheritance for current session Message-ID: <200909072017.n87KHwDB076858@freefall.freebsd.org> Synopsis: [zfs] Setting ZFS nfsshare property does not cause inheritance for current session State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: pon 7 wrz 2009 20:16:16 UTC State-Changed-Why: The problem you described was related to buggy detection of shared file systems which I just fixed. With this fix I'm not able to reproduce your problem, sharenfs property on parent changes children too as confirmed with 'showmount -e'. Thanks for the report! Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 7 wrz 2009 20:16:16 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=113180 From gerrit at pmp.uni-hannover.de Tue Sep 8 15:39:08 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Tue Sep 8 15:39:14 2009 Subject: zfs kernel panic Message-ID: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> Hi folks, I just upgraded a zfs server from 7.0-something to 7.2-stable and hoped to get rid of some minor instabilities I experienced every 6 months or so. Unfortunately, the new system crashed for the first time after only a few hours when copying some files via scp onto it. I got a kernel panic which looked quite similar to the one reported here (kmem_map too small): I have a dual cpu dual core opteron system with 4GB of RAM and a 3-disk raidz1. I took out the memory settings from loader.conf as suggested in UPDATING. I did not yet upgrade zpool nor zfs version (would that help?). Are there any known issues or any further hints what might cause the crash? I copied the files again, but this time everything went fine. cu Gerrit From serenity at exscape.org Tue Sep 8 15:39:47 2009 From: serenity at exscape.org (Thomas Backman) Date: Tue Sep 8 15:39:54 2009 Subject: zfs kernel panic In-Reply-To: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> Message-ID: On Sep 8, 2009, at 5:23 PM, Gerrit K?hn wrote: > Hi folks, > > I just upgraded a zfs server from 7.0-something to 7.2-stable and > hoped to > get rid of some minor instabilities I experienced every 6 months or > so. > Unfortunately, the new system crashed for the first time after only > a few > hours when copying some files via scp onto it. > I got a kernel panic which looked quite similar to the one reported > here > (kmem_map too small): > > > > I have a dual cpu dual core opteron system with 4GB of RAM and a 3- > disk > raidz1. I took out the memory settings from loader.conf as suggested > in > UPDATING. I did not yet upgrade zpool nor zfs version (would that > help?). > Are there any known issues or any further hints what might cause the > crash? I copied the files again, but this time everything went fine. Hmm. Do you use i386 or amd64? This panic is (was?) pretty common on i386 before tuning, but... 4GB RAM and an Opteron should have you running amd64, no? Regards, Thomas From pjd at FreeBSD.org Tue Sep 8 16:44:18 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Sep 8 16:44:30 2009 Subject: zfs kernel panic In-Reply-To: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> Message-ID: <20090908164413.GC1539@garage.freebsd.pl> On Tue, Sep 08, 2009 at 05:23:32PM +0200, Gerrit K?hn wrote: > Hi folks, > > I just upgraded a zfs server from 7.0-something to 7.2-stable and hoped to > get rid of some minor instabilities I experienced every 6 months or so. > Unfortunately, the new system crashed for the first time after only a few > hours when copying some files via scp onto it. > I got a kernel panic which looked quite similar to the one reported here > (kmem_map too small): > > > I have a dual cpu dual core opteron system with 4GB of RAM and a 3-disk > raidz1. I took out the memory settings from loader.conf as suggested in > UPDATING. I did not yet upgrade zpool nor zfs version (would that help?). > Are there any known issues or any further hints what might cause the > crash? I copied the files again, but this time everything went fine. If this is amd64, add vm.kmem_size="4G" to your loader.conf back. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090908/53a4bc4a/attachment.pgp From tlott at gamesnet.de Tue Sep 8 22:44:55 2009 From: tlott at gamesnet.de (Tobias Lott) Date: Tue Sep 8 22:45:02 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090908214402.43009577@sub.han.vpn.gamesnet.de> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> Message-ID: <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> On Tue, 8 Sep 2009 21:44:02 +0200 Tobias Lott wrote: > > > On Tue, 1 Sep 2009 10:05:17 -0400 > John Baldwin wrote: > > > On Tuesday 01 September 2009 9:24:24 am Maciej Jan Broniarz wrote: > > > Hello, > > > > > > I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb > > > ram. When I create a zfs volume all works fine. Still, when I > > > reboot the system it doesn't come up. It hangs with the following > > > error: > > > > > > http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg > > > > > > What might be the problem? > > > > It's probably a NULL pointer dereference, but we would need a stack > > trace to investigate this further. > > > My Problem seems to be related. > > Updating a Machine to 8.0-BETA4 #3 caused same, its a i386 System > using gpt with zfs-only volumes beside swap. > > http://i25.tinypic.com/343p0s0.jpg > > I'll try to see if I can get a stack trace > Hey Everyone I've managed to get some Output for this, using BETA2 LiveCD (gonna try using BETA4 CD Tomorrow). 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) and today built BETA4 Kernel Panic mounting zfs Volumes. Booting single user mode I get output of zfs list and so on but mounting whatever volume also Panics. Stack output, if there's more you need I'll gladly help http://i27.tinypic.com/2d78qpd.jpg http://i31.tinypic.com/oqhv2w.jpg http://i28.tinypic.com/oktsag.jpg -- Tobias Lott From pjd at FreeBSD.org Wed Sep 9 05:42:58 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Sep 9 05:43:12 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> Message-ID: <20090909054249.GH1539@garage.freebsd.pl> On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: > Hey Everyone > > I've managed to get some Output for this, using BETA2 LiveCD (gonna try > using BETA4 CD Tomorrow). > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) > and today built BETA4 Kernel Panic mounting zfs Volumes. > Booting single user mode I get output of zfs list and so on but > mounting whatever volume also Panics. Why -f? Were there a poblem in importing pool? > Stack output, if there's more you need I'll gladly help > http://i27.tinypic.com/2d78qpd.jpg > http://i31.tinypic.com/oqhv2w.jpg > http://i28.tinypic.com/oktsag.jpg Could you also provide top part of the backtrace? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090909/856255f4/attachment.pgp From pjd at FreeBSD.org Wed Sep 9 06:05:34 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 9 06:05:39 2009 Subject: misc/118855: [zfs] ZFS-related commands are nonfunctional in fixit shell. Message-ID: <200909090605.n8965Xhf061284@freefall.freebsd.org> Synopsis: [zfs] ZFS-related commands are nonfunctional in fixit shell. State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: śro 9 wrz 2009 06:04:47 UTC State-Changed-Why: Automatic dependencies load should work from fixit. I think the problem is that kern.module_path isn't configured properly. Are you able to verify that? If that's the case can you manually set kern.module_path to /dist/boot/kernel and see if that will make it to work? Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: śro 9 wrz 2009 06:04:47 UTC Responsible-Changed-Why: I'm back, so take it back. http://www.freebsd.org/cgi/query-pr.cgi?pr=118855 From gerrit at pmp.uni-hannover.de Wed Sep 9 07:03:39 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Wed Sep 9 07:03:45 2009 Subject: zfs kernel panic In-Reply-To: <20090908164413.GC1539@garage.freebsd.pl> References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> <20090908164413.GC1539@garage.freebsd.pl> Message-ID: <20090909090335.89a071df.gerrit@pmp.uni-hannover.de> On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek wrote about Re: zfs kernel panic: PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back. Yes, it is amd64 (sorry I did not mention that). I will add the option back (the one I used before was set to a somewhat lower value, something like 2G afaicr). cu Gerrit From gerrit at pmp.uni-hannover.de Wed Sep 9 07:07:18 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Wed Sep 9 07:07:33 2009 Subject: zfs kernel panic In-Reply-To: <20090908164413.GC1539@garage.freebsd.pl> References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> <20090908164413.GC1539@garage.freebsd.pl> Message-ID: <20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de> On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek wrote about Re: zfs kernel panic: PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back. What about vm.kmem_size_max? Does that also need tuning? cu Gerrit From tlott at gamesnet.de Wed Sep 9 08:13:51 2009 From: tlott at gamesnet.de (Tobias Lott) Date: Wed Sep 9 08:13:58 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090909054249.GH1539@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> Message-ID: <20090909101346.01887a02@sub.han.vpn.gamesnet.de> On Wed, 9 Sep 2009 07:42:49 +0200 Pawel Jakub Dawidek wrote: > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: > > Hey Everyone > > > > I've managed to get some Output for this, using BETA2 LiveCD (gonna > > try using BETA4 CD Tomorrow). > > > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) > > and today built BETA4 Kernel Panic mounting zfs Volumes. > > Booting single user mode I get output of zfs list and so on but > > mounting whatever volume also Panics. > > Why -f? Were there a poblem in importing pool? > > > Stack output, if there's more you need I'll gladly help > > http://i27.tinypic.com/2d78qpd.jpg > > http://i31.tinypic.com/oqhv2w.jpg > > http://i28.tinypic.com/oktsag.jpg > > Could you also provide top part of the backtrace? > Oh yeah my bad http://i29.tinypic.com/nqwxo2.jpg http://i26.tinypic.com/209hanm.jpg -- Tobias Lott From pjd at FreeBSD.org Wed Sep 9 08:33:18 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Sep 9 08:33:24 2009 Subject: zfs kernel panic In-Reply-To: <20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de> References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> <20090908164413.GC1539@garage.freebsd.pl> <20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de> Message-ID: <20090909083313.GA1901@garage.freebsd.pl> On Wed, Sep 09, 2009 at 09:07:15AM +0200, Gerrit K?hn wrote: > On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek > wrote about Re: zfs kernel panic: > > PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back. > > What about vm.kmem_size_max? Does that also need tuning? No, this should be auto-tuned to some very large value. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090909/2bdfd8aa/attachment.pgp From fbsd at dannysplace.net Wed Sep 9 10:10:13 2009 From: fbsd at dannysplace.net (Danny Carroll) Date: Wed Sep 9 10:11:13 2009 Subject: zfs kernel panic In-Reply-To: <20090909083313.GA1901@garage.freebsd.pl> References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> <20090908164413.GC1539@garage.freebsd.pl> <20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de> <20090909083313.GA1901@garage.freebsd.pl> Message-ID: <4AA77834.1010007@dannysplace.net> On 9/09/2009 6:33 PM, Pawel Jakub Dawidek wrote: > On Wed, Sep 09, 2009 at 09:07:15AM +0200, Gerrit K?hn wrote: > >> On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek >> wrote about Re: zfs kernel panic: >> >> PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back. >> >> What about vm.kmem_size_max? Does that also need tuning? >> > No, this should be auto-tuned to some very large value. > > Pawel (et al), Would it be possible for you to post to the list your ideas of a complete set of tuning parameters for ZFS on amd64? I have used the wiki article as a reference (http://wiki.freebsd.org/ZFSTuningGuide) but it states that if you have > 2g ram and 7.2 then you do not need to tune at all. I for one would be interested in learning a little more about how the memory should be tuned. Specifically what might be interesting is to know, once a parameter is set, is there an easy way to find out how it's being used? i.e. If you start limiting the arc, is is possible to know what sort of hit/miss rate you are getting. -D From pjd at FreeBSD.org Wed Sep 9 10:44:02 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Sep 9 10:44:09 2009 Subject: zfs kernel panic In-Reply-To: <4AA77834.1010007@dannysplace.net> References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de> <20090908164413.GC1539@garage.freebsd.pl> <20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de> <20090909083313.GA1901@garage.freebsd.pl> <4AA77834.1010007@dannysplace.net> Message-ID: <20090909104358.GG1901@garage.freebsd.pl> On Wed, Sep 09, 2009 at 07:41:08PM +1000, Danny Carroll wrote: > On 9/09/2009 6:33 PM, Pawel Jakub Dawidek wrote: > >On Wed, Sep 09, 2009 at 09:07:15AM +0200, Gerrit K?hn wrote: > > > >>On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek > >>wrote about Re: zfs kernel panic: > >> > >>PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back. > >> > >>What about vm.kmem_size_max? Does that also need tuning? > >> > >No, this should be auto-tuned to some very large value. > > > > > Pawel (et al), > > Would it be possible for you to post to the list your ideas of a > complete set of tuning parameters for ZFS on amd64? I have used the > wiki article as a reference (http://wiki.freebsd.org/ZFSTuningGuide) but > it states that if you have > 2g ram and 7.2 then you do not need to tune > at all. I think that was the idea, although I see no reason to have less kernel address space than physical memory (except there might be other in-kernel variables auto-tuned based on kmem size). > I for one would be interested in learning a little more about how the > memory should be tuned. Specifically what might be interesting is to > know, once a parameter is set, is there an easy way to find out how it's > being used? i.e. If you start limiting the arc, is is possible to know > what sort of hit/miss rate you are getting. There are ARC statistics available here: # sysctl kstat.zfs -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090909/e45eb766/attachment.pgp From linimon at FreeBSD.org Wed Sep 9 15:07:07 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 9 15:07:18 2009 Subject: kern/138656: [zfs] [panic] ZFS panic "lock &arg.lock already initialized" during zfs recv Message-ID: <200909091507.n89F76Jd052924@freefall.freebsd.org> Old Synopsis: ZFS panic "lock &arg.lock already initialized" during zfs recv New Synopsis: [zfs] [panic] ZFS panic "lock &arg.lock already initialized" during zfs recv Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 9 15:06:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138656 From pjd at FreeBSD.org Wed Sep 9 18:46:59 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 9 18:47:05 2009 Subject: kern/125149: [nfs] [panic] changing into .zfs dir from nfs client causes panic Message-ID: <200909091846.n89Ikw11075911@freefall.freebsd.org> Synopsis: [nfs] [panic] changing into .zfs dir from nfs client causes panic State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: śro 9 wrz 2009 18:46:17 UTC State-Changed-Why: Is this still a problem with FreeBSD 8? I'm not able to reproduce it. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: śro 9 wrz 2009 18:46:17 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=125149 From pjd at FreeBSD.org Wed Sep 9 18:50:48 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 9 18:50:53 2009 Subject: kern/121770: ZFS on i386, large file or heavy I/O leads to kernel panic or reboot Message-ID: <200909091850.n89IolvT083317@freefall.freebsd.org> Synopsis: ZFS on i386, large file or heavy I/O leads to kernel panic or reboot Responsible-Changed-From-To: freebsd-fs->freebsd-bugs Responsible-Changed-By: pjd Responsible-Changed-When: śro 9 wrz 2009 18:50:31 UTC Responsible-Changed-Why: Looks like a hardware failure and not ZFS problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=121770 From pjd at FreeBSD.org Wed Sep 9 18:56:32 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 9 18:56:39 2009 Subject: kern/122173: [zfs] [panic] Kernel Panic if attempting to replace a drive in a raidz wih zfs Message-ID: <200909091856.n89IuWmR085342@freefall.freebsd.org> Synopsis: [zfs] [panic] Kernel Panic if attempting to replace a drive in a raidz wih zfs State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: śro 9 wrz 2009 18:55:46 UTC State-Changed-Why: This seems to work fine on FreeBSD 8. Please upgrade. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: śro 9 wrz 2009 18:55:46 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=122173 From pjd at FreeBSD.org Wed Sep 9 20:11:25 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 9 20:11:31 2009 Subject: kern/132551: [zfs] ZFS locks up on extattr_list_link syscall Message-ID: <200909092011.n89KBOej064077@freefall.freebsd.org> Synopsis: [zfs] ZFS locks up on extattr_list_link syscall State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: śro 9 wrz 2009 20:11:02 UTC State-Changed-Why: Already fixed, see bin/132452. http://www.freebsd.org/cgi/query-pr.cgi?pr=132551 From artis.caune at gmail.com Thu Sep 10 05:50:03 2009 From: artis.caune at gmail.com (Artis Caune) Date: Thu Sep 10 05:50:09 2009 Subject: kern/138656: [zfs] [panic] ZFS panic "lock & arg.lock already initialized" during zfs recv Message-ID: <200909100550.n8A5o2wW049076@freefall.freebsd.org> The following reply was made to PR kern/138656; it has been noted by GNATS. From: Artis Caune To: bug-followup@FreeBSD.org, james-freebsd-current@jrv.org Cc: Subject: Re: kern/138656: [zfs] [panic] ZFS panic "lock &arg.lock already initialized" during zfs recv Date: Thu, 10 Sep 2009 08:40:23 +0300 I have the same problem but only with debugging turned on when it's panic in few minutes after box startup. With debugging turned off I never got this panic. (stable/8 r196679) -- Artis Caune Everything should be made as simple as possible, but not simpler. From mailing at ekomedya.com Thu Sep 10 15:18:52 2009 From: mailing at ekomedya.com (=?utf-8?Q?Eko_Bilgisayar_ve_=C4=B0leti=C5=9Fim_Hizmetleri_Ltd=2E_=C5=9Eti?=) Date: Thu Sep 10 15:20:33 2009 Subject: Turkey Calling You To Visit - The Trade SHOW- In Las Vegas Message-ID: <301eba6bbc7cb7611c65fb2bb4f9777e@localhost.localdomain> [http://www.turkeycalling.us] [http://www.turkeycalling.us] [http://www.turkeycalling.us] [http://www.turkeycalling.us/turkey-fam/turkeyfam.htm] Global Access Travel invites you to the Tradeshow in Las Vegas on September 13-15, 2009. Please visit us to get more information about our organization and services at our booth. If you fill the registration form or leave the business card when you visit us at our booth, you might be lucky visitor who is going to win our daily draw prize; Free inspection trip to Turkey. Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. This message was sent by: TURKEY CALLING YOU TO VISIT "THE TRADE SHOW" IN LAS VEGAS, N?zhetiye Cad, istanbul, Besiktas 34357, Turkey Manage your subscription: http://app.icontact.com/icp/mmail-mprofile.pl?r=47622549&l=82253&s=BL1J&m=587775&c=305227 From james-freebsd-fs2 at jrv.org Thu Sep 10 15:46:45 2009 From: james-freebsd-fs2 at jrv.org (James R. Van Artsdalen) Date: Thu Sep 10 15:46:51 2009 Subject: ZFS hang -CURRENT (9/9/9) Message-ID: <4AA91F63.1010801@jrv.org> FreeBSD pygmy.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r197044M: Wed Sep 9 18:58:08 CDT 2009 james@pygmy.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 ZFS recv hung last night during the daily periodic script. Most of the pool can be read but if one area is touched the process hangs with ^T reporting: $ find /bigtex ... /bigtex/usr/home/james ^T load: 0.00 cmd: find 2794 [rrl->rr_cv)] 5861.45r 0.28u 2.02s 0% 1704k That's about where the ZFS recv hung: receiving incremental stream of bigtex/usr/home/james/News@syssnap-1246856401 into bigtex/usr/home/james/News@syssnap-1246856401 received 15.8MB stream in 59 seconds (275KB/sec) receiving incremental stream of bigtex/usr/home/james/News@syssnap-1246942803 into bigtex/usr/home/james/News@syssnap-1246942803 received 5.91MB stream in 50 seconds (121KB/sec) receiving incremental stream of bigtex/usr/home/james/News@syssnap-1247029203 into bigtex/usr/home/james/News@syssnap-1247029203 There should have 25 or so more snapshots in that filesystem. /var/log/messages has no messages. From gavin at FreeBSD.org Thu Sep 10 19:15:23 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Sep 10 19:15:35 2009 Subject: kern/138709: [zfs] zfs recv hangs, pool accesses hang in rrl->rr_cv state Message-ID: <200909101915.n8AJFMR9000602@freefall.freebsd.org> Old Synopsis: [patch] FreeBSD/amd64 can't see all system memory New Synopsis: [zfs] zfs recv hangs, pool accesses hang in rrl->rr_cv state Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Thu Sep 10 19:14:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=138709 From giffunip at tutopia.com Thu Sep 10 20:00:07 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Thu Sep 10 20:00:14 2009 Subject: kern/138109: [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2fs based on BSD Lite2 Message-ID: <200909102000.n8AK07Ua040311@freefall.freebsd.org> The following reply was made to PR kern/138109; it has been noted by GNATS. From: "Pedro F. Giffuni" To: bug-followup@FreeBSD.org Cc: Bruce Evans Subject: Re: kern/138109: [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2fs based on BSD Lite2 Date: Thu, 10 Sep 2009 12:28:17 -0700 (PDT) --0-1580472039-1252610897=:7136 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello;=0A=0AI finally did a new sweep and attempted to clean the issues not= ed by Bruce. I also added a couple of patches of his authorship(issue with = a goal=3D=3D0 and the clustering cleanups).=0AI tried to make the BSD licen= sed code (in particular *fs_inode.c) similar to the PRE_SOFTUPDATE tag.=0A= =0AThe patch compiles on my system and a similar patch has been tested by A= ditya Sarawgi for his Google SoC project.=0A=0A=0A --0-1580472039-1252610897=:7136 Content-Type: application/octet-stream; name=patch-ext2fs Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-ext2fs" ZGlmZiAtdSBleHQyZnMub3JpZy9leHQyX2FsbG9jLmMgZXh0MmZzL2V4dDJf YWxsb2MuYwotLS0gZXh0MmZzLm9yaWcvZXh0Ml9hbGxvYy5jCTIwMDktMDkt MTAgMTM6MDU6MzEuMDAwMDAwMDAwICswMDAwCisrKyBleHQyZnMvZXh0Ml9h bGxvYy5jCTIwMDktMDktMTAgMTM6NDE6MDkuMDAwMDAwMDAwICswMDAwCkBA IC00NDEsNyArNDQxLDcgQEAKIAkvKiBpZiB0aGUgbmV4dCBibG9jayBpcyBh Y3R1YWxseSB3aGF0IHdlIHRob3VnaHQgaXQgaXMsCiAJICAgdGhlbiBzZXQg dGhlIGdvYWwgdG8gd2hhdCB3ZSB0aG91Z2h0IGl0IHNob3VsZCBiZQogCSov Ci0JaWYoaXAtPmlfbmV4dF9hbGxvY19ibG9jayA9PSBsYm4pCisJaWYoaXAt PmlfbmV4dF9hbGxvY19ibG9jayA9PSBsYm4gJiYgaXAtPmlfbmV4dF9hbGxv Y19nb2FsICE9IDApCiAJCXJldHVybiBpcC0+aV9uZXh0X2FsbG9jX2dvYWw7 CiAKIAkvKiBub3cgY2hlY2sgd2hldGhlciB3ZSB3ZXJlIHByb3ZpZGVkIHdp dGggYW4gYXJyYXkgdGhhdCBiYXNpY2FsbHkKZGlmZiAtdSBleHQyZnMub3Jp Zy9leHQyX2lub2RlLmMgZXh0MmZzL2V4dDJfaW5vZGUuYwotLS0gZXh0MmZz Lm9yaWcvZXh0Ml9pbm9kZS5jCTIwMDktMDktMTAgMTM6MDU6MzEuMDAwMDAw MDAwICswMDAwCisrKyBleHQyZnMvZXh0Ml9pbm9kZS5jCTIwMDktMDktMTAg MTM6NDI6MjEuMDAwMDAwMDAwICswMDAwCkBAIC0xMjYsMTYgKzEyNiwxMSBA QAogCWxvbmcgY291bnQsIG5ibG9ja3MsIGJsb2Nrc3JlbGVhc2VkID0gMDsK IAlpbnQgYWZsYWdzLCBlcnJvciwgaSwgYWxsZXJyb3I7CiAJb2ZmX3Qgb3Np emU7Ci0vKgotcHJpbnRmKCJleHQyX3RydW5jYXRlIGNhbGxlZCAlZCB0byAl ZFxuIiwgVlRPSShvdnApLT5pX251bWJlciwgbGVuZ3RoKTsKLSovCS8qIAot CSAqIG5lZ2F0aXZlIGZpbGUgc2l6ZXMgd2lsbCB0b3RhbGx5IGJyZWFrIHRo ZSBjb2RlIGJlbG93IGFuZAotCSAqIGFyZSBub3QgbWVhbmluZ2Z1bCBhbnl3 YXlzLgotCSAqLworCisJb2lwID0gVlRPSShvdnApOwkgCiAJaWYgKGxlbmd0 aCA8IDApCi0JICAgIHJldHVybiBFRkJJRzsKKwkJcmV0dXJuIChFSU5WQUwp OwogCi0Jb2lwID0gVlRPSShvdnApOwogCWlmIChvdnAtPnZfdHlwZSA9PSBW TE5LICYmCiAJICAgIG9pcC0+aV9zaXplIDwgb3ZwLT52X21vdW50LT5tbnRf bWF4c3ltbGlua2xlbikgewogI2lmZGVmIERJQUdOT1NUSUMKQEAgLTE1Nywy MyArMTUyLDI5IEBACiAJLyoKIAkgKiBMZW5ndGhlbiB0aGUgc2l6ZSBvZiB0 aGUgZmlsZS4gV2UgbXVzdCBlbnN1cmUgdGhhdCB0aGUKIAkgKiBsYXN0IGJ5 dGUgb2YgdGhlIGZpbGUgaXMgYWxsb2NhdGVkLiBTaW5jZSB0aGUgc21hbGxl c3QKLQkgKiB2YWx1ZSBvZiBvc3ppZSBpcyAwLCBsZW5ndGggd2lsbCBiZSBh dCBsZWFzdCAxLgorCSAqIHZhbHVlIG9mIG9zaXplIGlzIDAsIGxlbmd0aCB3 aWxsIGJlIGF0IGxlYXN0IDEuCiAJICovCiAJaWYgKG9zaXplIDwgbGVuZ3Ro KSB7CiAJCWlmIChsZW5ndGggPiBvaXAtPmlfZTJmcy0+ZnNfbWF4ZmlsZXNp emUpCiAJCQlyZXR1cm4gKEVGQklHKTsKKwkJdm5vZGVfcGFnZXJfc2V0c2l6 ZShvdnAsIGxlbmd0aCk7CiAJCW9mZnNldCA9IGJsa29mZihmcywgbGVuZ3Ro IC0gMSk7CiAJCWxibiA9IGxibGtubyhmcywgbGVuZ3RoIC0gMSk7CiAJCWFm bGFncyA9IEJfQ0xSQlVGOwogCQlpZiAoZmxhZ3MgJiBJT19TWU5DKQogCQkJ YWZsYWdzIHw9IEJfU1lOQzsKLQkJdm5vZGVfcGFnZXJfc2V0c2l6ZShvdnAs IGxlbmd0aCk7Ci0JCWlmICgoZXJyb3IgPSBleHQyX2JhbGxvYyhvaXAsIGxi biwgb2Zmc2V0ICsgMSwgY3JlZCwgJmJwLAotCQkgICAgYWZsYWdzKSkgIT0g MCkKKwkJZXJyb3IgPSBleHQyX2JhbGxvYyhvaXAsIGxibiwgb2Zmc2V0ICsg MSwgY3JlZCwgJmJwLCBhZmxhZ3MpOworCQlpZiAoZXJyb3IpIHsKKwkJCXZu b2RlX3BhZ2VyX3NldHNpemUodnAsIG9zaXplKTsKIAkJCXJldHVybiAoZXJy b3IpOworCQl9CiAJCW9pcC0+aV9zaXplID0gbGVuZ3RoOwotCQlpZiAoYWZs YWdzICYgSU9fU1lOQykKKwkJaWYgKGJwLT5iX2J1ZnNpemUgPT0gZnMtPnNf YmxvY2tzaXplKQorCQkJYnAtPmJfZmxhZ3MgfD0gQl9DTFVTVEVST0s7CisJ CWlmIChhZmxhZ3MgJiBCX1NZTkMpCiAJCQlid3JpdGUoYnApOworCQllbHNl IGlmIChvdnAtPnZfbW91bnQtPm1udF9mbGFnICYgTU5UX0FTWU5DKQorCQkJ YmR3cml0ZShicCk7CiAJCWVsc2UKIAkJCWJhd3JpdGUoYnApOwogCQlvaXAt PmlfZmxhZyB8PSBJTl9DSEFOR0UgfCBJTl9VUERBVEU7CkBAIC0xOTUsMTUg KzE5NiwxOSBAQAogCQlhZmxhZ3MgPSBCX0NMUkJVRjsKIAkJaWYgKGZsYWdz ICYgSU9fU1lOQykKIAkJCWFmbGFncyB8PSBCX1NZTkM7Ci0JCWlmICgoZXJy b3IgPSBleHQyX2JhbGxvYyhvaXAsIGxibiwgb2Zmc2V0LCBjcmVkLCAmYnAs Ci0JCSAgICBhZmxhZ3MpKSAhPSAwKQorCQllcnJvciA9IGV4dDJfYmFsbG9j KG9pcCwgbGJuLCBvZmZzZXQsIGNyZWQsICZicCwgYWZsYWdzKTsKKwkJaWYg KGVycm9yKQogCQkJcmV0dXJuIChlcnJvcik7CiAJCW9pcC0+aV9zaXplID0g bGVuZ3RoOwogCQlzaXplID0gYmxrc2l6ZShmcywgb2lwLCBsYm4pOwogCQli emVybygoY2hhciAqKWJwLT5iX2RhdGEgKyBvZmZzZXQsICh1X2ludCkoc2l6 ZSAtIG9mZnNldCkpOwogCQlhbGxvY2J1ZihicCwgc2l6ZSk7Ci0JCWlmIChh ZmxhZ3MgJiBJT19TWU5DKQorCQlpZiAoYnAtPmJfYnVmc2l6ZSA9PSBmcy0+ c19ibG9ja3NpemUpCisJCQlicC0+Yl9mbGFncyB8PSBCX0NMVVNURVJPSzsK KwkJaWYgKGFmbGFncyAmIEJfU1lOQykKIAkJCWJ3cml0ZShicCk7CisJCWVs c2UgaWYgKG92cC0+dl9tb3VudC0+bW50X2ZsYWcgJiBNTlRfQVNZTkMpCisJ CQliZHdyaXRlKGJwKTsKIAkJZWxzZQogCQkJYmF3cml0ZShicCk7CiAJfQpA QCAtMjQ3LDYgKzI1Miw3IEBACiAJZXJyb3IgPSB2dHJ1bmNidWYob3ZwLCBj cmVkLCB0ZCwgbGVuZ3RoLCAoaW50KWZzLT5zX2Jsb2Nrc2l6ZSk7CiAJaWYg KGVycm9yICYmIChhbGxlcnJvciA9PSAwKSkKIAkJYWxsZXJyb3IgPSBlcnJv cjsKKwl2bm9kZV9wYWdlcl9zZXRzaXplKG92cCwgbGVuZ3RoKTsKIAogCS8q CiAJICogSW5kaXJlY3QgYmxvY2tzIGZpcnN0LgpkaWZmIC11IGV4dDJmcy5v cmlnL2V4dDJfcmVhZHdyaXRlLmMgZXh0MmZzL2V4dDJfcmVhZHdyaXRlLmMK LS0tIGV4dDJmcy5vcmlnL2V4dDJfcmVhZHdyaXRlLmMJMjAwOS0wOS0xMCAx MzowNTozMS4wMDAwMDAwMDAgKzAwMDAKKysrIGV4dDJmcy9leHQyX3JlYWR3 cml0ZS5jCTIwMDktMDktMTAgMTQ6MTM6NDEuMDAwMDAwMDAwICswMDAwCkBA IC0zNiw2ICszNiw3IEBACiAgKiAkRnJlZUJTRDogc3JjL3N5cy9nbnUvZnMv ZXh0MmZzL2V4dDJfcmVhZHdyaXRlLmMsdiAxLjMxLjIwLjEgMjAwOS8wNC8x NSAwMzoxNDoyNiBrZW5zbWl0aCBFeHAgJAogICovCiAKKy8qIFhYWCBUT0RP OiByZW1vdmUgdGhlc2Ugb2JmdXNjYXRpb25zIChhcyBpbiBmZnNfdm5vcHMu YykuICovCiAjZGVmaW5lCUJMS1NJWkUoYSwgYiwgYykJYmxrc2l6ZShhLCBi LCBjKQogI2RlZmluZQlGUwkJCXN0cnVjdCBleHQyX3NiX2luZm8KICNkZWZp bmUJSV9GUwkJCWlfZTJmcwpAQCAtNDcsNyArNDgsNiBAQAogLyoKICAqIFZu b2RlIG9wIGZvciByZWFkaW5nLgogICovCi0vKiBBUkdTVVNFRCAqLwogc3Rh dGljIGludAogUkVBRChhcCkKIAlzdHJ1Y3Qgdm9wX3JlYWRfYXJncyAvKiB7 CkBAIC02NSw4ICs2NSw4IEBACiAJZGFkZHJfdCBsYm4sIG5leHRsYm47CiAJ b2ZmX3QgYnl0ZXNpbmZpbGU7CiAJbG9uZyBzaXplLCB4ZmVyc2l6ZSwgYmxr b2Zmc2V0OwotCWludCBlcnJvciwgb3JpZ19yZXNpZDsKLQlpbnQgc2VxY291 bnQgPSBhcC0+YV9pb2ZsYWcgPj4gSU9fU0VRU0hJRlQ7CisJaW50IGVycm9y LCBvcmlnX3Jlc2lkLCBzZXFjb3VudDsKKwlzZXFjb3VudCA9IGFwLT5hX2lv ZmxhZyA+PiBJT19TRVFTSElGVDsKIAl1X3Nob3J0IG1vZGU7CiAKIAl2cCA9 IGFwLT5hX3ZwOwpAQCAtODQsMTEgKzg0LDE0IEBACiAJfSBlbHNlIGlmICh2 cC0+dl90eXBlICE9IFZSRUcgJiYgdnAtPnZfdHlwZSAhPSBWRElSKQogCQlw YW5pYygiJXM6IHR5cGUgJWQiLCBSRUFEX1MsIHZwLT52X3R5cGUpOwogI2Vu ZGlmCi0JZnMgPSBpcC0+SV9GUzsKLQlpZiAoKHVvZmZfdCl1aW8tPnVpb19v ZmZzZXQgPiBmcy0+ZnNfbWF4ZmlsZXNpemUpCi0JCXJldHVybiAoRUZCSUcp OwotCiAJb3JpZ19yZXNpZCA9IHVpby0+dWlvX3Jlc2lkOworCUtBU1NFUlQo b3JpZ19yZXNpZCA+PSAwLCAoImV4dDJfcmVhZDogdWlvLT51aW9fcmVzaWQg PCAwIikpOworCWlmIChvcmlnX3Jlc2lkID09IDApCisJCXJldHVybiAoMCk7 CisJS0FTU0VSVCh1aW8tPnVpb19vZmZzZXQgPj0gMCwgKCJleHQyX3JlYWQ6 IHVpby0+dWlvX29mZnNldCA8IDAiKSk7CisJZnMgPSBpcC0+SV9GUzsKKwlp ZiAodWlvLT51aW9fb2Zmc2V0IDwgaXAtPmlfc2l6ZSAmJiB1aW8tPnVpb19v ZmZzZXQgPj0gZnMtPmZzX21heGZpbGVzaXplKQorCQlyZXR1cm4gKEVPVkVS RkxPVyk7CiAJZm9yIChlcnJvciA9IDAsIGJwID0gTlVMTDsgdWlvLT51aW9f cmVzaWQgPiAwOyBicCA9IE5VTEwpIHsKIAkJaWYgKChieXRlc2luZmlsZSA9 IGlwLT5pX3NpemUgLSB1aW8tPnVpb19vZmZzZXQpIDw9IDApCiAJCQlicmVh azsKQEAgLTEwNiw5ICsxMDksOCBAQAogCQlpZiAobGJsa3Rvc2l6ZShmcywg bmV4dGxibikgPj0gaXAtPmlfc2l6ZSkKIAkJCWVycm9yID0gYnJlYWQodnAs IGxibiwgc2l6ZSwgTk9DUkVELCAmYnApOwogCQllbHNlIGlmICgodnAtPnZf bW91bnQtPm1udF9mbGFnICYgTU5UX05PQ0xVU1RFUlIpID09IDApCi0JCQll cnJvciA9IGNsdXN0ZXJfcmVhZCh2cCwKLQkJCSAgICBpcC0+aV9zaXplLCBs Ym4sIHNpemUsIE5PQ1JFRCwKLQkJCSAgICB1aW8tPnVpb19yZXNpZCwgKGFw LT5hX2lvZmxhZyA+PiBJT19TRVFTSElGVCksICZicCk7CisJCQllcnJvciA9 IGNsdXN0ZXJfcmVhZCh2cCwgaXAtPmlfc2l6ZSwgbGJuLCBzaXplLCBOT0NS RUQsCisJCQkgICAgYmxrb2Zmc2V0ICsgdWlvLT51aW9fcmVzaWQsIHNlcWNv dW50LCAmYnApOwogCQllbHNlIGlmIChzZXFjb3VudCA+IDEpIHsKIAkJCWlu dCBuZXh0c2l6ZSA9IEJMS1NJWkUoZnMsIGlwLCBuZXh0bGJuKTsKIAkJCWVy cm9yID0gYnJlYWRuKHZwLCBsYm4sCkBAIC0xMzQsOCArMTM2LDggQEAKIAkJ CQlicmVhazsKIAkJCXhmZXJzaXplID0gc2l6ZTsKIAkJfQotCQllcnJvciA9 Ci0JCSAgICB1aW9tb3ZlKChjaGFyICopYnAtPmJfZGF0YSArIGJsa29mZnNl dCwgKGludCl4ZmVyc2l6ZSwgdWlvKTsKKwkJZXJyb3IgPSB1aW9tb3ZlKChj aGFyICopYnAtPmJfZGF0YSArIGJsa29mZnNldCwKKwkJCShpbnQpeGZlcnNp emUsIHVpbyk7CiAJCWlmIChlcnJvcikKIAkJCWJyZWFrOwogCkBAIC0xNDMs NyArMTQ1LDcgQEAKIAl9CiAJaWYgKGJwICE9IE5VTEwpCiAJCWJxcmVsc2Uo YnApOwotCWlmIChvcmlnX3Jlc2lkID4gMCAmJiAoZXJyb3IgPT0gMCB8fCB1 aW8tPnVpb19yZXNpZCAhPSBvcmlnX3Jlc2lkKSAmJgorCWlmICgoZXJyb3Ig PT0gMCB8fCB1aW8tPnVpb19yZXNpZCAhPSBvcmlnX3Jlc2lkKSAmJgogCSAg ICAodnAtPnZfbW91bnQtPm1udF9mbGFnICYgTU5UX05PQVRJTUUpID09IDAp CiAJCWlwLT5pX2ZsYWcgfD0gSU5fQUNDRVNTOwogCXJldHVybiAoZXJyb3Ip OwpAQCAtMTY5LDExICsxNzEsMTAgQEAKIAlzdHJ1Y3QgdGhyZWFkICp0ZDsK IAlkYWRkcl90IGxibjsKIAlvZmZfdCBvc2l6ZTsKLQlpbnQgc2VxY291bnQ7 Ci0JaW50IGJsa29mZnNldCwgZXJyb3IsIGZsYWdzLCBpb2ZsYWcsIHJlc2lk LCBzaXplLCB4ZmVyc2l6ZTsKKwlpbnQgYmxrb2Zmc2V0LCBlcnJvciwgZmxh Z3MsIGlvZmxhZywgcmVzaWQsIHNpemUsIHNlcWNvdW50LCB4ZmVyc2l6ZTsK IAogCWlvZmxhZyA9IGFwLT5hX2lvZmxhZzsKLQlzZXFjb3VudCA9IGFwLT5h X2lvZmxhZyA+PiBJT19TRVFTSElGVDsKKwlzZXFjb3VudCA9IGlvZmxhZyA+ PiBJT19TRVFTSElGVDsKIAl1aW8gPSBhcC0+YV91aW87CiAJdnAgPSBhcC0+ YV92cDsKIAlpcCA9IFZUT0kodnApOwpAQCAtMTk0LDE1ICsxOTUsMTUgQEAK IAkJYnJlYWs7CiAJY2FzZSBWRElSOgogCQlpZiAoKGlvZmxhZyAmIElPX1NZ TkMpID09IDApCi0JCQlwYW5pYygiJXM6IG5vbnN5bmMgZGlyIHdyaXRlIiwg V1JJVEVfUyk7CisJCQlwYW5pYygiZXh0Ml93cml0ZTogbm9uc3luYyBkaXIg d3JpdGUiKTsKIAkJYnJlYWs7CiAJZGVmYXVsdDoKLQkJcGFuaWMoIiVzOiB0 eXBlIiwgV1JJVEVfUyk7CisJCXBhbmljKCJleHQyX3dyaXRlOiB0eXBlICVw ICVkICglamQsJWQpIiwgKHZvaWQgKil2cCwgdnAtPnZfdHlwZSwKKwkJCShp bnRtYXhfdCl1aW8tPnVpb19vZmZzZXQsIHVpby0+dWlvX3Jlc2lkKTsKIAl9 CiAKIAlmcyA9IGlwLT5JX0ZTOwotCWlmICh1aW8tPnVpb19vZmZzZXQgPCAw IHx8Ci0JICAgICh1b2ZmX3QpdWlvLT51aW9fb2Zmc2V0ICsgdWlvLT51aW9f cmVzaWQgPiBmcy0+ZnNfbWF4ZmlsZXNpemUpCisJaWYgKCh1b2ZmX3QpdWlv LT51aW9fb2Zmc2V0ICsgdWlvLT51aW9fcmVzaWQgPiBmcy0+ZnNfbWF4Zmls ZXNpemUpCiAJCXJldHVybiAoRUZCSUcpOwogCS8qCiAJICogTWF5YmUgdGhp cyBzaG91bGQgYmUgYWJvdmUgdGhlIHZub2RlIG9wIGNhbGwsIGJ1dCBzbyBs b25nIGFzCkBAIC0yMzYsMjYgKzIzNywxOSBAQAogCiAJCS8qCiAJCSAqIEF2 b2lkIGEgZGF0YS1jb25zaXN0ZW5jeSByYWNlIGJldHdlZW4gd3JpdGUoKSBh bmQgbW1hcCgpCi0JCSAqIGJ5IGVuc3VyaW5nIHRoYXQgbmV3bHkgYWxsb2Nh dGVkIGJsb2NrcyBhcmUgemVyb2QuICBUaGUKKwkJICogYnkgZW5zdXJpbmcg dGhhdCBuZXdseSBhbGxvY2F0ZWQgYmxvY2tzIGFyZSB6ZXJvZWQuICBUaGUK IAkJICogcmFjZSBjYW4gb2NjdXIgZXZlbiBpbiB0aGUgY2FzZSB3aGVyZSB0 aGUgd3JpdGUgY292ZXJzCiAJCSAqIHRoZSBlbnRpcmUgYmxvY2suCiAJCSAq LwogCQlmbGFncyB8PSBCX0NMUkJVRjsKLSNpZiAwCi0JCWlmIChmcy0+c19m cmFnX3NpemUgPiB4ZmVyc2l6ZSkKLQkJCWZsYWdzIHw9IEJfQ0xSQlVGOwot CQllbHNlCi0JCQlmbGFncyAmPSB+Ql9DTFJCVUY7Ci0jZW5kaWYKIAotCQll cnJvciA9IGV4dDJfYmFsbG9jKGlwLAotCQkgICAgbGJuLCBibGtvZmZzZXQg KyB4ZmVyc2l6ZSwgYXAtPmFfY3JlZCwgJmJwLCBmbGFncyk7CisJCWVycm9y ID0gZXh0Ml9iYWxsb2MoaXAsIGxibiwgYmxrb2Zmc2V0ICsgeGZlcnNpemUs CisJCSAgICBhcC0+YV9jcmVkLCAmYnAsIGZsYWdzKTsKIAkJaWYgKGVycm9y KQogCQkJYnJlYWs7CiAKLQkJaWYgKHVpby0+dWlvX29mZnNldCArIHhmZXJz aXplID4gaXAtPmlfc2l6ZSkgeworCQlpZiAodWlvLT51aW9fb2Zmc2V0ICsg eGZlcnNpemUgPiBpcC0+aV9zaXplKQogCQkJaXAtPmlfc2l6ZSA9IHVpby0+ dWlvX29mZnNldCArIHhmZXJzaXplOwotCQl9CiAKIAkJc2l6ZSA9IEJMS1NJ WkUoZnMsIGlwLCBsYm4pIC0gYnAtPmJfcmVzaWQ7CiAJCWlmIChzaXplIDwg eGZlcnNpemUpCkBAIC0yNjQsNyArMjU4LDcgQEAKIAkJZXJyb3IgPQogCQkg ICAgdWlvbW92ZSgoY2hhciAqKWJwLT5iX2RhdGEgKyBibGtvZmZzZXQsIChp bnQpeGZlcnNpemUsIHVpbyk7CiAJCWlmICgoaW9mbGFnICYgSU9fVk1JTykg JiYKLQkJICAgKExJU1RfRklSU1QoJmJwLT5iX2RlcCkgPT0gTlVMTCkpIC8q IGluIGV4dDJmcz8gKi8KKwkJICAgTElTVF9GSVJTVCgmYnAtPmJfZGVwKSA9 PSBOVUxMKSAvKiBpbiBleHQyZnM/ICovCiAJCQlicC0+Yl9mbGFncyB8PSBC X1JFTEJVRjsKIAogCQlpZiAoaW9mbGFnICYgSU9fU1lOQykgewpAQCAtMjgy LDEyICsyNzYsMTUgQEAKIAkJfQogCQlpZiAoZXJyb3IgfHwgeGZlcnNpemUg PT0gMCkKIAkJCWJyZWFrOwotCQlpcC0+aV9mbGFnIHw9IElOX0NIQU5HRSB8 IElOX1VQREFURTsKIAl9CiAJLyoKIAkgKiBJZiB3ZSBzdWNjZXNzZnVsbHkg d3JvdGUgYW55IGRhdGEsIGFuZCB3ZSBhcmUgbm90IHRoZSBzdXBlcnVzZXIK IAkgKiB3ZSBjbGVhciB0aGUgc2V0dWlkIGFuZCBzZXRnaWQgYml0cyBhcyBh IHByZWNhdXRpb24gYWdhaW5zdAogCSAqIHRhbXBlcmluZy4KKwkgKiBYWFgg dG9vIGxhdGUsIHRoZSB0YW1wZXJlciBtYXkgaGF2ZSBvcGVuZWQgdGhlIGZp bGUgd2hpbGUgd2UKKwkgKiB3ZXJlIHdyaXRpbmcgdGhlIGRhdGEgKG9yIGJl Zm9yZSkuCisJICogWFhYIHRvbyBlYXJseSwgaWYgKGVycm9yICYmIGlvZmxh ZyAmIElPX1VOSVQpIHRoZW4gd2Ugd2lsbAorCSAqIHVud3JpdGUgdGhlIGRh dGEuCiAJICovCiAJaWYgKHJlc2lkID4gdWlvLT51aW9fcmVzaWQgJiYgYXAt PmFfY3JlZCAmJiBhcC0+YV9jcmVkLT5jcl91aWQgIT0gMCkKIAkJaXAtPmlf bW9kZSAmPSB+KElTVUlEIHwgSVNHSUQpOwpAQCAtMjk4LDcgKzI5NSwxMSBA QAogCQkJdWlvLT51aW9fb2Zmc2V0IC09IHJlc2lkIC0gdWlvLT51aW9fcmVz aWQ7CiAJCQl1aW8tPnVpb19yZXNpZCA9IHJlc2lkOwogCQl9Ci0JfSBlbHNl IGlmIChyZXNpZCA+IHVpby0+dWlvX3Jlc2lkICYmIChpb2ZsYWcgJiBJT19T WU5DKSkKLQkJZXJyb3IgPSBleHQyX3VwZGF0ZSh2cCwgMSk7CisJfQorCWlm ICh1aW8tPnVpb19yZXNpZCAhPSByZXNpZCkgeworCQlpcC0+aV9mbGFnIHw9 IElOX0NIQU5HRSB8IElOX1VQREFURTsKKwkJaWYgKGlvZmxhZyAmIElPX1NZ TkMpCisJCQllcnJvciA9IGV4dDJfdXBkYXRlKHZwLCAxKTsKKwl9CiAJcmV0 dXJuIChlcnJvcik7CiB9CmRpZmYgLXUgZXh0MmZzLm9yaWcvZXh0Ml92ZnNv cHMuYyBleHQyZnMvZXh0Ml92ZnNvcHMuYwotLS0gZXh0MmZzLm9yaWcvZXh0 Ml92ZnNvcHMuYwkyMDA5LTA5LTEwIDEzOjA1OjMxLjAwMDAwMDAwMCArMDAw MAorKysgZXh0MmZzL2V4dDJfdmZzb3BzLmMJMjAwOS0wOS0xMCAxMzo0MTow OS4wMDAwMDAwMDAgKzAwMDAKQEAgLTE3MSw4ICsxNzEsNiBAQAogCQkJZmxh Z3MgPSBXUklURUNMT1NFOwogCQkJaWYgKG1wLT5tbnRfZmxhZyAmIE1OVF9G T1JDRSkKIAkJCQlmbGFncyB8PSBGT1JDRUNMT1NFOwotCQkJaWYgKHZmc19i dXN5KG1wLCBMS19OT1dBSVQsIDAsIHRkKSkKLQkJCQlyZXR1cm4gKEVCVVNZ KTsKIAkJCWVycm9yID0gZXh0Ml9mbHVzaGZpbGVzKG1wLCBmbGFncywgdGQp OwogCQkJdmZzX3VuYnVzeShtcCwgdGQpOwogCQkJaWYgKCFlcnJvciAmJiBm cy0+c193YXN2YWxpZCkgewpAQCAtNTAwLDYgKzQ5OCw3IEBACiAgKgk0KSBp bnZhbGlkYXRlIGFsbCBpbmFjdGl2ZSB2bm9kZXMuCiAgKgk1KSBpbnZhbGlk YXRlIGFsbCBjYWNoZWQgZmlsZSBkYXRhLgogICoJNikgcmUtcmVhZCBpbm9k ZSBkYXRhIGZvciBhbGwgYWN0aXZlIHZub2Rlcy4KKyAqIFhYWCB3ZSBhcmUg bWlzc2luZyBzb21lIHN0ZXBzLCBpbiBwYXJ0aWN1bGFyICMgMwogICovCiBz dGF0aWMgaW50CiBleHQyX3JlbG9hZChzdHJ1Y3QgbW91bnQgKm1wLCBzdHJ1 Y3QgdGhyZWFkICp0ZCkKQEAgLTEwMDcsOCArMTAwNiw4IEBACiAJCSAqIHN0 aWxsIHplcm8sIGl0IHdpbGwgYmUgdW5saW5rZWQgYW5kIHJldHVybmVkIHRv IHRoZSBmcmVlCiAJCSAqIGxpc3QgYnkgdnB1dCgpLgogCQkgKi8KLQkJdnB1 dCh2cCk7CiAJCWJyZWxzZShicCk7CisJCXZwdXQodnApOwogCQkqdnBwID0g TlVMTDsKIAkJcmV0dXJuIChlcnJvcik7CiAJfQpAQCAtMTAzMiw3ICsxMDMx LDcgQEAKIC8qCiAJZXh0Ml9wcmludF9pbm9kZShpcCk7CiAqLwotCWJyZWxz ZShicCk7CisJYnFyZWxzZShicCk7CiAKIAkvKgogCSAqIEluaXRpYWxpemUg dGhlIHZub2RlIGZyb20gdGhlIGlub2RlLCBjaGVjayBmb3IgYWxpYXNlcy4K --0-1580472039-1252610897=:7136-- From pjd at FreeBSD.org Thu Sep 10 21:52:07 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Sep 10 21:52:13 2009 Subject: ZFS hang -CURRENT (9/9/9) In-Reply-To: <4AA91F63.1010801@jrv.org> References: <4AA91F63.1010801@jrv.org> Message-ID: <20090910215200.GC2718@garage.freebsd.pl> On Thu, Sep 10, 2009 at 10:46:43AM -0500, James R. Van Artsdalen wrote: > FreeBSD pygmy.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r197044M: > Wed Sep 9 18:58:08 CDT 2009 > james@pygmy.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > ZFS recv hung last night during the daily periodic script. Most of the > pool can be read but if one area is touched the process hangs with ^T > reporting: > > $ find /bigtex > ... > /bigtex/usr/home/james > ^T > load: 0.00 cmd: find 2794 [rrl->rr_cv)] 5861.45r 0.28u 2.02s 0% 1704k > > That's about where the ZFS recv hung: > > receiving incremental stream of > bigtex/usr/home/james/News@syssnap-1246856401 into > bigtex/usr/home/james/News@syssnap-1246856401 > received 15.8MB stream in 59 seconds (275KB/sec) > receiving incremental stream of > bigtex/usr/home/james/News@syssnap-1246942803 into > bigtex/usr/home/james/News@syssnap-1246942803 > received 5.91MB stream in 50 seconds (121KB/sec) > receiving incremental stream of > bigtex/usr/home/james/News@syssnap-1247029203 into > bigtex/usr/home/james/News@syssnap-1247029203 > > There should have 25 or so more snapshots in that filesystem. > > /var/log/messages has no messages. Could you break into DDB debugger and send me output of 'alltrace' command for starters. You can also obtain process backtrace using procstat(1). -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090910/dae01008/attachment.pgp From pjd at FreeBSD.org Thu Sep 10 21:53:00 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Sep 10 21:53:16 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090909101346.01887a02@sub.han.vpn.gamesnet.de> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> Message-ID: <20090910215254.GD2718@garage.freebsd.pl> On Wed, Sep 09, 2009 at 10:13:46AM +0200, Tobias Lott wrote: > > > On Wed, 9 Sep 2009 07:42:49 +0200 > Pawel Jakub Dawidek wrote: > > > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: > > > Hey Everyone > > > > > > I've managed to get some Output for this, using BETA2 LiveCD (gonna > > > try using BETA4 CD Tomorrow). > > > > > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) > > > and today built BETA4 Kernel Panic mounting zfs Volumes. > > > Booting single user mode I get output of zfs list and so on but > > > mounting whatever volume also Panics. > > > > Why -f? Were there a poblem in importing pool? > > > > > Stack output, if there's more you need I'll gladly help > > > http://i27.tinypic.com/2d78qpd.jpg > > > http://i31.tinypic.com/oqhv2w.jpg > > > http://i28.tinypic.com/oktsag.jpg > > > > Could you also provide top part of the backtrace? > > > Oh yeah my bad > > http://i29.tinypic.com/nqwxo2.jpg > http://i26.tinypic.com/209hanm.jpg Seems that one of the vdevs is NULL. Could you tell me why you decided to use -f option for importing the pool? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090910/9d1a2291/attachment.pgp From gavin at FreeBSD.org Fri Sep 11 09:11:44 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Sep 11 09:11:55 2009 Subject: ports/138476: [panic] sysutils/fusefs-kmod: Almost regular panic during VFS operations; maybe related to sshfs Message-ID: <200909110911.n8B9BhRp056079@freefall.freebsd.org> Old Synopsis: [panic] [sshfs] [fuse] Almost regular panic during VFS operations; maybe related to sshfs New Synopsis: [panic] sysutils/fusefs-kmod: Almost regular panic during VFS operations; maybe related to sshfs Responsible-Changed-From-To: freebsd-fs->freebsd-ports-bugs Responsible-Changed-By: gavin Responsible-Changed-When: Fri Sep 11 09:07:27 UTC 2009 Responsible-Changed-Why: This looks likely to be an issue with the sysutils/fusefs-kmod port, over to maintainers. http://www.freebsd.org/cgi/query-pr.cgi?pr=138476 From tlott at gamesnet.de Fri Sep 11 09:58:12 2009 From: tlott at gamesnet.de (tlott@gamesnet.de) Date: Fri Sep 11 09:58:24 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090910215254.GD2718@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> Message-ID: <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> > On Wed, Sep 09, 2009 at 10:13:46AM +0200, Tobias Lott wrote: >> >> >> On Wed, 9 Sep 2009 07:42:49 +0200 >> Pawel Jakub Dawidek wrote: >> >> > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: >> > > Hey Everyone >> > > >> > > I've managed to get some Output for this, using BETA2 LiveCD (gonna >> > > try using BETA4 CD Tomorrow). >> > > >> > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) >> > > and today built BETA4 Kernel Panic mounting zfs Volumes. >> > > Booting single user mode I get output of zfs list and so on but >> > > mounting whatever volume also Panics. >> > >> > Why -f? Were there a poblem in importing pool? >> > >> > > Stack output, if there's more you need I'll gladly help >> > > http://i27.tinypic.com/2d78qpd.jpg >> > > http://i31.tinypic.com/oqhv2w.jpg >> > > http://i28.tinypic.com/oktsag.jpg >> > >> > Could you also provide top part of the backtrace? >> > >> Oh yeah my bad >> >> http://i29.tinypic.com/nqwxo2.jpg >> http://i26.tinypic.com/209hanm.jpg > > Seems that one of the vdevs is NULL. Could you tell me why you decided > to use -f option for importing the pool? > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > Because zpool import tank says: cannot import 'tank': pool may be in use from other system use '-f' to import anyway From weldon at excelsusphoto.com Fri Sep 11 14:09:49 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Fri Sep 11 14:10:22 2009 Subject: kern/125149: [nfs] [panic] changing into .zfs dir from nfs client causes panic In-Reply-To: <200909091846.n89Ikw11075911@freefall.freebsd.org> References: <200909091846.n89Ikw11075911@freefall.freebsd.org> Message-ID: Since I am running an faily old version of head and I can't migrate to a more current version until our "off-season" (next is December), I can't verify. The last I heard of this ticket, a patch was fixed to keep it from panicing, but to be able to access the .zfs directory from a nfs client required more retooling. If memory serves me right, sometime around Wednesday, pjd@FreeBSD.org told me: > Synopsis: [nfs] [panic] changing into .zfs dir from nfs client causes panic > > State-Changed-From-To: open->feedback > State-Changed-By: pjd > State-Changed-When: ?ro 9 wrz 2009 18:46:17 UTC > State-Changed-Why: > Is this still a problem with FreeBSD 8? I'm not able to reproduce it. > > > Responsible-Changed-From-To: freebsd-fs->pjd > Responsible-Changed-By: pjd > Responsible-Changed-When: ?ro 9 wrz 2009 18:46:17 UTC > Responsible-Changed-Why: > I'll take this one. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=125149 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From linimon at FreeBSD.org Sat Sep 12 03:13:45 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Sep 12 03:13:52 2009 Subject: kern/138709: [zfs] zfs recv hangs, pool accesses hang in rrl->rr_cv state Message-ID: <200909120313.n8C3Di7Y044232@freefall.freebsd.org> Synopsis: [zfs] zfs recv hangs, pool accesses hang in rrl->rr_cv state State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sat Sep 12 03:13:27 UTC 2009 State-Changed-Why: See kern/138220. http://www.freebsd.org/cgi/query-pr.cgi?pr=138709 From gavin at FreeBSD.org Sat Sep 12 18:08:13 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Sep 12 18:08:26 2009 Subject: kern/138764: [zfs] ZFS panic: "panic: dirtying snapshot!" Message-ID: <200909121808.n8CI8Dui079650@freefall.freebsd.org> Old Synopsis: ZFS panic: "panic: dirtying snapshot!" New Synopsis: [zfs] ZFS panic: "panic: dirtying snapshot!" Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sat Sep 12 18:06:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=138764 From dfilter at FreeBSD.ORG Sat Sep 12 19:30:08 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sat Sep 12 19:30:15 2009 Subject: kern/132068: commit references a PR Message-ID: <200909121930.n8CJU8oJ059918@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132068: commit references a PR Date: Sat, 12 Sep 2009 19:28:07 +0000 (UTC) Author: pjd Date: Sat Sep 12 19:27:54 2009 New Revision: 197131 URL: http://svn.freebsd.org/changeset/base/197131 Log: Tighten up the check for race in zfs_zget() - ZTOV(zp) can not only contain NULL, but also can point to dead vnode, take that into account. PR: kern/132068 Reported by: Edward Fisk" <7ogcg7g02@sneakemail.com>, kris Fix based on patch from: Jaakko Heinonen MFC after: 1 week Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c Sat Sep 12 19:07:03 2009 (r197130) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c Sat Sep 12 19:27:54 2009 (r197131) @@ -890,8 +890,16 @@ again: if (zp->z_unlinked) { err = ENOENT; } else { - if (ZTOV(zp) != NULL) - VN_HOLD(ZTOV(zp)); + if ((vp = ZTOV(zp)) != NULL) { + VI_LOCK(vp); + if ((vp->v_iflag & VI_DOOMED) != 0) { + VI_UNLOCK(vp); + vp = NULL; + } else + VI_UNLOCK(vp); + } + if (vp != NULL) + VN_HOLD(vp); else { if (first) { ZFS_LOG(1, "dying znode detected (zp=%p)", zp); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From pjd at FreeBSD.org Sun Sep 13 16:09:43 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Sun Sep 13 16:09:49 2009 Subject: kern/118320: [zfs] [patch] NFS SETATTR sometimes fails to set file mode on ZFS partition Message-ID: <200909131609.n8DG9gop097033@freefall.freebsd.org> Synopsis: [zfs] [patch] NFS SETATTR sometimes fails to set file mode on ZFS partition State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: ndz 13 wrz 2009 16:08:52 UTC State-Changed-Why: Is this still a problem with FreeBSD 8? Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: ndz 13 wrz 2009 16:08:52 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=118320 From pjd at FreeBSD.org Sun Sep 13 16:28:32 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Sun Sep 13 16:28:39 2009 Subject: kern/138709: [zfs] zfs recv hangs, pool accesses hang in rrl->rr_cv state Message-ID: <200909131628.n8DGSWxq017066@freefall.freebsd.org> Synopsis: [zfs] zfs recv hangs, pool accesses hang in rrl->rr_cv state State-Changed-From-To: closed->feedback State-Changed-By: pjd State-Changed-When: ndz 13 wrz 2009 16:26:24 UTC State-Changed-Why: I don't think it hasanything to do with kern/138220. This would be great if you could provide a way to reproduce this. It might be related to one of my recent commits. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: ndz 13 wrz 2009 16:26:24 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=138709 From rmacklem at uoguelph.ca Sun Sep 13 18:13:09 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Sep 13 18:13:29 2009 Subject: NFS client defaults to a mix of UDP and TCP Message-ID: I had thought that I had posted w.r.t. before, but can't find it in the archive (which might explain why I didn't get any responses:-). The current mount_nfs defaults to using UDP for the mount protocol and then switches to using TCP for the actual mount. (When neither "udp" nor "tcp" mount options are specified.) I don't think I changed it to be this way, because I recall noticing it when I added changes for the experimental NFS client and thought it was "weird", but assumed that it had been that way for a long time. It now appears that it was introduced post-FreeBSD7 at r176198, which changed the default for NFS to TCP, but didn't switch the default for the mount protocol to TCP. The ancient history of this is that "once upon a time" there were NFS servers that could do NFS over TCP, but only supported UDP for the mount protocol and there was an option called "mntudp" for that case. I can't imagine that any server still needs this case, but it appears to have become the default. The default works fine for servers that support both UDP and TCP, but result in a non-functional mount point when the server only supports UDP. (See recent email thread on freebsd-stable called "NFS issues on 8.0-BETA4".) Is this something that should be changed? rick From pjd at FreeBSD.org Sun Sep 13 20:24:02 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Sep 13 20:24:09 2009 Subject: Review request for NFS readdirplus change. Message-ID: <20090913202350.GE2091@garage.freebsd.pl> Hi. I'm looking for a review of the following patch: http://people.freebsd.org/~pjd/patches/nfs_serv.c.3.patch The main purpose of this patch is to support stuff like ZFS, where using VFS_VGET() might be tricky on .zfs/ directory and friends. When VFS_VGET() is not supported be the underlying file system, we switch to VOP_LOOKUP(). Note that OpenSolaris NFS server implementation always uses lookup for readdirplus. I also modified the code to use shared-locking, there is no need to exclusively lock the vnodes. The patch removes an assert which doesn't hold for ZFS when we go into .zfs/snapshot// directory, which is separate mount point, but we don't want to export it separately, so we still return it on lookup. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090913/3a431b33/attachment.pgp From gavin at FreeBSD.org Sun Sep 13 21:32:28 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sun Sep 13 21:32:34 2009 Subject: usb/112640: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk Message-ID: <200909132132.n8DLWRT7025974@freefall.freebsd.org> Old Synopsis: [usb] [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk New Synopsis: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Sun Sep 13 21:31:16 UTC 2009 State-Changed-Why: Submitter has provided feedback. The problem still exists on 7.2, and USB has been ruled out. Responsible-Changed-From-To: gavin->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sun Sep 13 21:31:16 UTC 2009 Responsible-Changed-Why: Over to maintaner(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=112640 From pjd at FreeBSD.org Mon Sep 14 06:39:32 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 06:39:38 2009 Subject: kern/128514: [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Adapter Message-ID: <200909140639.n8E6dVbd072592@freefall.freebsd.org> Synopsis: [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Adapter State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 06:38:38 UTC State-Changed-Why: Could you try adding vfs.zfs.cache_flush_disable=1 to your /boot/loader.conf and see i that helps? It will prevent ZFS from sending write flush requests to the disks. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 06:38:38 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=128514 From pjd at FreeBSD.org Mon Sep 14 07:03:32 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 07:03:39 2009 Subject: kern/129148: [zfs] [panic] panic on concurrent writing & rollback Message-ID: <200909140703.n8E73VH1000588@freefall.freebsd.org> Synopsis: [zfs] [panic] panic on concurrent writing & rollback State-Changed-From-To: open->patched State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 07:02:21 UTC State-Changed-Why: I believe it is already fixed in HEAD. Could you verify? If you can't try HEAD, it sould be in 8 soon. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 07:02:21 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=129148 From pjd at FreeBSD.org Mon Sep 14 08:08:18 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 08:08:25 2009 Subject: kern/138656: [zfs] [panic] ZFS panic "lock &arg.lock already initialized" during zfs recv Message-ID: <200909140808.n8E88GlL089782@freefall.freebsd.org> Synopsis: [zfs] [panic] ZFS panic "lock &arg.lock already initialized" during zfs recv State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 08:01:07 UTC State-Changed-Why: Duplicate of kern/135480. Problem already fixed in HEAD. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 08:01:07 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=138656 From bugmaster at FreeBSD.org Mon Sep 14 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 14 11:07:59 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200909141106.n8EB6w7u072308@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/138764 fs [zfs] [panic] ZFS panic: "panic: dirtying snapshot!" o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138367 fs [tmpfs] [panic] 'panic: Assertion pages > 0 failed' wh o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/138109 fs [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2f f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/136218 fs [zfs] Exported ZFS pools can't be imported into (Open) o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o bin/135314 fs [zfs] assertion failed for zdb(8) usage o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot f kern/134496 fs [zfs] [panic] ZFS pool export occasionally causes a ke o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127492 fs [zfs] System hang on ZFS input-output o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/125644 fs [zfs] [panic] zfs unfixable fs errors caused panic whe f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122047 fs [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / o kern/122038 fs [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o usb/112640 fs [ext2fs] [hang] Kernel freezes when writing a file to o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/105093 fs [ext2fs] [patch] ext2fs on read-only media cannot be m o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/77826 fs [ext2fs] ext2fs usb filesystem will not mount RW o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 144 problems total. From pjd at FreeBSD.org Mon Sep 14 12:40:10 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 12:40:16 2009 Subject: kern/125644: [zfs] [panic] zfs unfixable fs errors caused panic when trying to destroy filesystem Message-ID: <200909141240.n8ECe9re070015@freefall.freebsd.org> Synopsis: [zfs] [panic] zfs unfixable fs errors caused panic when trying to destroy filesystem State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 12:38:47 UTC State-Changed-Why: Strange panic on old ZFS version. If it will happen again on FreeBSD 8, please let me know. http://www.freebsd.org/cgi/query-pr.cgi?pr=125644 From pjd at FreeBSD.org Mon Sep 14 12:40:26 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 12:40:32 2009 Subject: kern/125644: [zfs] [panic] zfs unfixable fs errors caused panic when trying to destroy filesystem Message-ID: <200909141240.n8ECeQLn072790@freefall.freebsd.org> Synopsis: [zfs] [panic] zfs unfixable fs errors caused panic when trying to destroy filesystem Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 12:40:13 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=125644 From pjd at FreeBSD.org Mon Sep 14 12:44:24 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 12:44:29 2009 Subject: kern/136218: [zfs] Exported ZFS pools can't be imported into (Open)Solaris Message-ID: <200909141244.n8ECiNiL079101@freefall.freebsd.org> Synopsis: [zfs] Exported ZFS pools can't be imported into (Open)Solaris State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 12:42:24 UTC State-Changed-Why: Problem solved by the author. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 12:42:24 UTC Responsible-Changed-Why: I'll take that one. http://www.freebsd.org/cgi/query-pr.cgi?pr=136218 From pjd at FreeBSD.org Mon Sep 14 12:47:05 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 12:47:11 2009 Subject: kern/138764: [zfs] [panic] ZFS panic: "panic: dirtying snapshot!" Message-ID: <200909141247.n8ECl5Vd079178@freefall.freebsd.org> Synopsis: [zfs] [panic] ZFS panic: "panic: dirtying snapshot!" State-Changed-From-To: open->suspended State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 12:46:18 UTC State-Changed-Why: At least backtrace is needed to start working on this problem. Suspend PR until backtrace is provided. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 12:46:18 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=138764 From pjd at FreeBSD.org Mon Sep 14 13:07:47 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 13:07:53 2009 Subject: kern/127492: [zfs] System hang on ZFS input-output Message-ID: <200909141307.n8ED7k3C097997@freefall.freebsd.org> Synopsis: [zfs] System hang on ZFS input-output State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 13:07:16 UTC State-Changed-Why: Can you still see this behaviour with FreeBSD 8? Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 13:07:16 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=127492 From jhb at freebsd.org Mon Sep 14 13:13:29 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 14 13:13:35 2009 Subject: Review request for NFS readdirplus change. In-Reply-To: <20090913202350.GE2091@garage.freebsd.pl> References: <20090913202350.GE2091@garage.freebsd.pl> Message-ID: <200909140832.27956.jhb@freebsd.org> On Sunday 13 September 2009 4:23:50 pm Pawel Jakub Dawidek wrote: > Hi. > > I'm looking for a review of the following patch: > > http://people.freebsd.org/~pjd/patches/nfs_serv.c.3.patch > > The main purpose of this patch is to support stuff like ZFS, where using > VFS_VGET() might be tricky on .zfs/ directory and friends. When > VFS_VGET() is not supported be the underlying file system, we switch to > VOP_LOOKUP(). Note that OpenSolaris NFS server implementation always > uses lookup for readdirplus. > > I also modified the code to use shared-locking, there is no need to > exclusively lock the vnodes. > > The patch removes an assert which doesn't hold for ZFS when we go into > .zfs/snapshot// directory, which is separate mount point, but we > don't want to export it separately, so we still return it on lookup. I don't think you need the trailing '\' before a split expression when building cn_flags. Other than that I think it looks ok from what I can see (but I am far less familiar with the NFS server than the NFS client). Also, you might want to patch the new NFS server as well as the old one (or ask Rick about the new one). -- John Baldwin From jhb at freebsd.org Mon Sep 14 13:13:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 14 13:14:14 2009 Subject: NFS client defaults to a mix of UDP and TCP In-Reply-To: References: Message-ID: <200909140858.34592.jhb@freebsd.org> On Sunday 13 September 2009 2:18:25 pm Rick Macklem wrote: > I had thought that I had posted w.r.t. before, but can't find it in > the archive (which might explain why I didn't get any responses:-). > > The current mount_nfs defaults to using UDP for the mount protocol > and then switches to using TCP for the actual mount. (When neither > "udp" nor "tcp" mount options are specified.) I don't think I > changed it to be this way, because I recall noticing it when I > added changes for the experimental NFS client and thought it was > "weird", but assumed that it had been that way for a long time. > > It now appears that it was introduced post-FreeBSD7 at r176198, > which changed the default for NFS to TCP, but didn't switch the > default for the mount protocol to TCP. > > The ancient history of this is that "once upon a time" there were > NFS servers that could do NFS over TCP, but only supported UDP for > the mount protocol and there was an option called "mntudp" for that > case. I can't imagine that any server still needs this case, but > it appears to have become the default. > > The default works fine for servers that support both UDP and TCP, > but result in a non-functional mount point when the server only > supports UDP. (See recent email thread on freebsd-stable called > "NFS issues on 8.0-BETA4".) > > Is this something that should be changed? rick Yes. I know of folks would love to have NFS use only TCP, including the initial RPC portmapper requests. IMO an NFS mount should use TCP for everything and a UDP mount should use UDP for everything by default. -- John Baldwin From pjd at FreeBSD.org Mon Sep 14 13:22:41 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 14 13:22:48 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200909141322.n8EDMeJ2017930@freefall.freebsd.org> Synopsis: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 State-Changed-From-To: feedback->patched State-Changed-By: pjd State-Changed-When: pon 14 wrz 2009 13:22:15 UTC State-Changed-Why: Fixed in HEAD. Thanks for the report! Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 14 wrz 2009 13:22:15 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=132068 From avg at icyb.net.ua Mon Sep 14 13:28:56 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Sep 14 13:29:04 2009 Subject: NFS client defaults to a mix of UDP and TCP In-Reply-To: <200909140858.34592.jhb@freebsd.org> References: <200909140858.34592.jhb@freebsd.org> Message-ID: <4AAE4513.6030701@icyb.net.ua> on 14/09/2009 15:58 John Baldwin said the following: > > Yes. I know of folks would love to have NFS use only TCP, including the > initial RPC portmapper requests. IMO an NFS mount should use TCP for > everything and a UDP mount should use UDP for everything by default. > And another fact - it seems that NFS umount unconditionally uses UDP for "something": /* * Report to mountd-server which nfsname * has been unmounted. */ if (ai != NULL && !(fflag & MNT_FORCE) && do_rpc) { clp = clnt_create(hostp, MOUNTPROG, MOUNTVERS, "udp"); ... -- Andriy Gapon From sarawgi.aditya at gmail.com Mon Sep 14 15:40:04 2009 From: sarawgi.aditya at gmail.com (Aditya Sarawgi) Date: Mon Sep 14 15:40:11 2009 Subject: usb/112640: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk Message-ID: <200909141540.n8EFe40O048927@freefall.freebsd.org> The following reply was made to PR usb/112640; it has been noted by GNATS. From: Aditya Sarawgi To: klaas@kite.ping.de, gavin@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: usb/112640: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk Date: Mon, 14 Sep 2009 21:02:33 +0000 Hi, I think this problem persists only on amd64. I have rewritten some parts of ext2fs and I feel this problem will not occur in the new implementation. I don't have a merge for 7.x release for the new code but if you want to try the code on 8.x mail me. Thanks! -- Aditya Sarawgi From rmacklem at uoguelph.ca Mon Sep 14 16:16:14 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Sep 14 16:16:25 2009 Subject: Review request for NFS readdirplus change. In-Reply-To: <200909140832.27956.jhb@freebsd.org> References: <20090913202350.GE2091@garage.freebsd.pl> <200909140832.27956.jhb@freebsd.org> Message-ID: On Mon, 14 Sep 2009, John Baldwin wrote: > On Sunday 13 September 2009 4:23:50 pm Pawel Jakub Dawidek wrote: >> Hi. >> >> I'm looking for a review of the following patch: >> >> http://people.freebsd.org/~pjd/patches/nfs_serv.c.3.patch >> [good stuff snipped] > > I don't think you need the trailing '\' before a split expression when > building cn_flags. Other than that I think it looks ok from what I can see > (but I am far less familiar with the NFS server than the NFS client). Also, > you might want to patch the new NFS server as well as the old one (or ask > Rick about the new one). > Looks fine to me, too (although I'm not particularily familiar with the flags for VOP_LOOKUP()). I can do a similar change to the experimental server once it goes in. rick From rmacklem at uoguelph.ca Mon Sep 14 16:22:34 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Sep 14 16:22:46 2009 Subject: NFS client defaults to a mix of UDP and TCP In-Reply-To: <4AAE4513.6030701@icyb.net.ua> References: <200909140858.34592.jhb@freebsd.org> <4AAE4513.6030701@icyb.net.ua> Message-ID: On Mon, 14 Sep 2009, Andriy Gapon wrote: > on 14/09/2009 15:58 John Baldwin said the following: >> >> Yes. I know of folks would love to have NFS use only TCP, including the >> initial RPC portmapper requests. IMO an NFS mount should use TCP for >> everything and a UDP mount should use UDP for everything by default. >> > > And another fact - it seems that NFS umount unconditionally uses UDP for "something": > > /* > * Report to mountd-server which nfsname > * has been unmounted. > */ > if (ai != NULL && !(fflag & MNT_FORCE) && do_rpc) { > clp = clnt_create(hostp, MOUNTPROG, MOUNTVERS, "udp"); > ... > Yep. This one is somewhat less critical IMO, since this RPC is just fyi for the mountd on the server and, if it fails for any reason, only normally affects the output of "showmount" and doesn't break the umount. (That doesn't mean I don't think it should be fixed, but it can be done separately from resolving what mount_nfs needs to default to.) rick From mel.flynn+fbsd.fs at mailing.thruhere.net Mon Sep 14 18:09:22 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Mon Sep 14 18:09:29 2009 Subject: Question about struct vop_*_args Message-ID: <200909142009.17782.mel.flynn+fbsd.fs@mailing.thruhere.net> Hi, find+grep isn't able to tell me where the struct vop_rename_args and friends are defined. Is this done dynamically somewhere and can anyone point to the location? -- Mel From swell.k at gmail.com Mon Sep 14 18:13:14 2009 From: swell.k at gmail.com (Anonymous) Date: Mon Sep 14 18:13:20 2009 Subject: kern/129148: [zfs] [panic] panic on concurrent writing & rollback In-Reply-To: <200909140703.n8E73VH1000588@freefall.freebsd.org> (pjd@freebsd.org's message of "Mon, 14 Sep 2009 07:03:31 GMT") References: <200909140703.n8E73VH1000588@freefall.freebsd.org> Message-ID: <86ab0xqurm.fsf@gmail.com> pjd@FreeBSD.org writes: > Synopsis: [zfs] [panic] panic on concurrent writing & rollback > > State-Changed-From-To: open->patched > State-Changed-By: pjd > State-Changed-When: pon 14 wrz 2009 07:02:21 UTC > State-Changed-Why: > I believe it is already fixed in HEAD. Could you verify? > If you can't try HEAD, it sould be in 8 soon. I'm no longer able to reproduce it on r197192M neither with the script nor with patch & rollback & patch sequence. From mdounin at mdounin.ru Mon Sep 14 18:27:33 2009 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon Sep 14 18:27:51 2009 Subject: Question about struct vop_*_args In-Reply-To: <200909142009.17782.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909142009.17782.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <20090914182730.GF4917@mdounin.ru> Hello! On Mon, Sep 14, 2009 at 08:09:17PM +0200, Mel Flynn wrote: > Hi, > > find+grep isn't able to tell me where the struct vop_rename_args and friends > are defined. Is this done dynamically somewhere and can anyone point to the > location? Yes, it's defined in vnode_if.h which is dynamically generated by src/sys/tools/vnode_if.awk from src/sys/kern/vnode_if.src. Maxim Dounin From scjamorim at bsd.com.br Mon Sep 14 18:45:15 2009 From: scjamorim at bsd.com.br (Sylvio Cesar) Date: Mon Sep 14 18:45:29 2009 Subject: Question about struct vop_*_args In-Reply-To: <200909142009.17782.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200909142009.17782.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <5859850b0909141112q5409e660qba85bca99b8b3eeb@mail.gmail.com> Hi, Uses: find with xargs and grep. i.e: find / | xargs grep name_args Regards, Sylvio Cesar 2009/9/14 Mel Flynn : > Hi, > > find+grep isn't able to tell me where the struct vop_rename_args and friends > are defined. Is this done dynamically somewhere and can anyone point to the > location? > -- > Mel > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From mel.flynn+fbsd.fs at mailing.thruhere.net Mon Sep 14 18:59:38 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Mon Sep 14 18:59:56 2009 Subject: Question about struct vop_*_args In-Reply-To: <20090914182730.GF4917@mdounin.ru> References: <200909142009.17782.mel.flynn+fbsd.fs@mailing.thruhere.net> <20090914182730.GF4917@mdounin.ru> Message-ID: <200909142059.34881.mel.flynn+fbsd.fs@mailing.thruhere.net> On Monday 14 September 2009 20:27:30 Maxim Dounin wrote: > Hello! > > On Mon, Sep 14, 2009 at 08:09:17PM +0200, Mel Flynn wrote: > > Hi, > > > > find+grep isn't able to tell me where the struct vop_rename_args and > > friends are defined. Is this done dynamically somewhere and can anyone > > point to the location? > > Yes, it's defined in vnode_if.h which is dynamically generated by > src/sys/tools/vnode_if.awk from src/sys/kern/vnode_if.src. Ah, thank you very much. Now I know where to start reading. -- Mel From avg at icyb.net.ua Mon Sep 14 18:59:49 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Sep 14 18:59:57 2009 Subject: NFS client defaults to a mix of UDP and TCP In-Reply-To: References: <200909140858.34592.jhb@freebsd.org> <4AAE4513.6030701@icyb.net.ua> Message-ID: <4AAE929E.3040904@icyb.net.ua> on 14/09/2009 19:27 Rick Macklem said the following: > > > On Mon, 14 Sep 2009, Andriy Gapon wrote: > >> on 14/09/2009 15:58 John Baldwin said the following: >>> >>> Yes. I know of folks would love to have NFS use only TCP, including the >>> initial RPC portmapper requests. IMO an NFS mount should use TCP for >>> everything and a UDP mount should use UDP for everything by default. >>> >> >> And another fact - it seems that NFS umount unconditionally uses UDP >> for "something": >> >> /* >> * Report to mountd-server which nfsname >> * has been unmounted. >> */ >> if (ai != NULL && !(fflag & MNT_FORCE) && do_rpc) { >> clp = clnt_create(hostp, MOUNTPROG, MOUNTVERS, "udp"); >> ... >> > Yep. This one is somewhat less critical IMO, since this RPC is just > fyi for the mountd on the server and, if it fails for any reason, only > normally affects the output of "showmount" and doesn't break the umount. > (That doesn't mean I don't think it should be fixed, but it can be done > separately from resolving what mount_nfs needs to default to.) I agree. It's just that given the nature of UDP it takes a very long while for umount to re-alize that nobody's listening in some situations. -- Andriy Gapon From linimon at FreeBSD.org Tue Sep 15 00:47:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 15 00:47:07 2009 Subject: kern/138790: [zfs] ZFS ceases caching when mem demand is high Message-ID: <200909150047.n8F0l0MS096713@freefall.freebsd.org> Old Synopsis: ZFS ceases caching when mem demand is high New Synopsis: [zfs] ZFS ceases caching when mem demand is high Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 15 00:46:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138790 From rodrigc at crodrigues.org Tue Sep 15 01:28:33 2009 From: rodrigc at crodrigues.org (Craig Rodrigues) Date: Tue Sep 15 01:28:45 2009 Subject: NFS client defaults to a mix of UDP and TCP In-Reply-To: References: Message-ID: <20090915012833.GA54756@crodrigues.org> On Sun, Sep 13, 2009 at 02:18:25PM -0400, Rick Macklem wrote: > Is this something that should be changed? rick Go ahead and clean this up. I worked with Doug Rabson to re-do a lot of the mount_nfs code to use nmount(), and this UDP/TCP thing for the RPC transport slipped through. There is no good reason for keeping things the way they are. Thanks for all your work beating the FreeBSD NFS implementation into shape! I sat next to you at the Italian restaurant at BSDCan 2009. :) -- Craig Rodrigues rodrigc@crodrigues.org From zbeeble at gmail.com Tue Sep 15 18:38:02 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Tue Sep 15 18:38:09 2009 Subject: kern/138790: [zfs] ZFS ceases caching when mem demand is high In-Reply-To: <200909150047.n8F0l0MS096713@freefall.freebsd.org> References: <200909150047.n8F0l0MS096713@freefall.freebsd.org> Message-ID: <5f67a8c40909151138l4c4fcd3cnc31bf3f59a781052@mail.gmail.com> On Mon, Sep 14, 2009 at 8:47 PM, wrote: > Old Synopsis: ZFS ceases caching when mem demand is high > New Synopsis: [zfs] ZFS ceases caching when mem demand is high > > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > Responsible-Changed-By: linimon > Responsible-Changed-When: Tue Sep 15 00:46:39 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > I have a question on this: Are we back to the old fight on dividing the system memory resource between cache and paging again? This seems like a major regression for using ZFS over UFS. The idea that this might be happening has caused me to regard my ZFS store as a largely nfs/smb appliance. Certainly it does well in this role --- and dedicating a system to many terrabytes of store isn't the end-of-the-world, but having used ZFS on my laptop --- and all the pain that incurs --- I'm shy about using ZFS on anything that isn't essentially a disk appliance. ZFS should be better than that. If the cache/VM aren't integrated on FreeBSD, are they integrated in OpenSolaris? From jh at saunalahti.fi Tue Sep 15 18:40:11 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Tue Sep 15 18:40:21 2009 Subject: usb/112640: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk Message-ID: <200909151840.n8FIeBGX019383@freefall.freebsd.org> The following reply was made to PR usb/112640; it has been noted by GNATS. From: Jaakko Heinonen To: klaas@kite.ping.de, Aditya Sarawgi Cc: bug-followup@FreeBSD.org, gavin@FreeBSD.org Subject: Re: usb/112640: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk Date: Tue, 15 Sep 2009 21:39:14 +0300 On 2009-09-14, Aditya Sarawgi wrote: > I think this problem persists only on amd64. I was unable reproduce the problem with the command give in audit trail. Are you sure that the problem is reproducible after r186740 (head) or r187386 (stable/7)? Those revisions fixed a bug with identical symptoms. -- Jaakko From tlott at gamesnet.de Tue Sep 15 18:44:42 2009 From: tlott at gamesnet.de (Tobias Lott) Date: Tue Sep 15 18:44:55 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> Message-ID: <20090915204404.79cf9325@sub.han.vpn.gamesnet.de> On Fri, 11 Sep 2009 11:51:25 +0200 tlott@gamesnet.de wrote: > > On Wed, Sep 09, 2009 at 10:13:46AM +0200, Tobias Lott wrote: > >> > >> > >> On Wed, 9 Sep 2009 07:42:49 +0200 > >> Pawel Jakub Dawidek wrote: > >> > >> > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: > >> > > Hey Everyone > >> > > > >> > > I've managed to get some Output for this, using BETA2 LiveCD > >> > > (gonna try using BETA4 CD Tomorrow). > >> > > > >> > > 'zfs import -f poolname' triggered this, Booting kernel.old > >> > > (BETA3) and today built BETA4 Kernel Panic mounting zfs > >> > > Volumes. Booting single user mode I get output of zfs list and > >> > > so on but mounting whatever volume also Panics. > >> > > >> > Why -f? Were there a poblem in importing pool? > >> > > >> > > Stack output, if there's more you need I'll gladly help > >> > > http://i27.tinypic.com/2d78qpd.jpg > >> > > http://i31.tinypic.com/oqhv2w.jpg > >> > > http://i28.tinypic.com/oktsag.jpg > >> > > >> > Could you also provide top part of the backtrace? > >> > > >> Oh yeah my bad > >> > >> http://i29.tinypic.com/nqwxo2.jpg > >> http://i26.tinypic.com/209hanm.jpg > > > > Seems that one of the vdevs is NULL. Could you tell me why you > > decided to use -f option for importing the pool? > > > > -- > > Pawel Jakub Dawidek http://www.wheel.pl > > pjd@FreeBSD.org http://www.FreeBSD.org > > FreeBSD committer Am I Evil? Yes, I Am! > > > > Because zpool import tank says: > cannot import 'tank': pool may be in use from other system > use '-f' to import anyway > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" Any news on this? -- Tobias Lott From pjd at FreeBSD.org Tue Sep 15 21:41:53 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Sep 15 21:42:05 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090915204404.79cf9325@sub.han.vpn.gamesnet.de> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> <20090915204404.79cf9325@sub.han.vpn.gamesnet.de> Message-ID: <20090915214142.GA2063@garage.freebsd.pl> On Tue, Sep 15, 2009 at 08:44:04PM +0200, Tobias Lott wrote: > Any news on this? Not really. I'm out of ideas. A way to repoduce it would be of course best. If you can't provide one maybe you remember something strange just before panic, like disk disappeared or something? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090915/a376e148/attachment.pgp From tlott at gamesnet.de Tue Sep 15 21:55:48 2009 From: tlott at gamesnet.de (Tobias Lott) Date: Tue Sep 15 21:55:55 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090915214142.GA2063@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> <20090915204404.79cf9325@sub.han.vpn.gamesnet.de> <20090915214142.GA2063@garage.freebsd.pl> Message-ID: <20090915235511.559550e5@sub.han.vpn.gamesnet.de> On Tue, 15 Sep 2009 23:41:42 +0200 Pawel Jakub Dawidek wrote: > On Tue, Sep 15, 2009 at 08:44:04PM +0200, Tobias Lott wrote: > > Any news on this? > > Not really. I'm out of ideas. A way to repoduce it would be of course > best. If you can't provide one maybe you remember something strange > just before panic, like disk disappeared or something? > Looks like I've found whats causing it by mounting all ZFS Volumes one by one. It was a Volume used by a Jail running nginx, nagios and some other stuff. Weird but luckily not that important since its a Test Machine, can I provide anything that you could figure out whats wrong with that Volume so it can be fixed? Cause I triggered this only by upgrading BETA3->4 #3 r196936. Cheers. -- Tobias Lott From andrew at modulus.org Wed Sep 16 00:53:47 2009 From: andrew at modulus.org (Andrew Snow) Date: Wed Sep 16 00:53:54 2009 Subject: kern/138790: [zfs] ZFS ceases caching when mem demand is high In-Reply-To: <5f67a8c40909151138l4c4fcd3cnc31bf3f59a781052@mail.gmail.com> References: <200909150047.n8F0l0MS096713@freefall.freebsd.org> <5f67a8c40909151138l4c4fcd3cnc31bf3f59a781052@mail.gmail.com> Message-ID: <4AB03659.9060703@modulus.org> Zaphod Beeblebrox wrote: > Are we back to the old fight on dividing the system memory resource between > cache and paging again? This seems like a major regression for using ZFS > over UFS. > The idea that this might be happening has caused me to regard my ZFS store > as a largely nfs/smb appliance. > ZFS should be better than that. Why? ZFS is designed for systems with large amounts of memory to spare - I don't think it should be used for any system with less than 2GB. Most brand new systems bought these days will have at least 2GB, if not 4 or 8GB. UFS isn't going away, it is still the filesystem preferred for embedded and low-end systems. - Andrew From zbeeble at gmail.com Wed Sep 16 06:35:27 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Wed Sep 16 06:35:38 2009 Subject: kern/138790: [zfs] ZFS ceases caching when mem demand is high In-Reply-To: <4AB03659.9060703@modulus.org> References: <200909150047.n8F0l0MS096713@freefall.freebsd.org> <5f67a8c40909151138l4c4fcd3cnc31bf3f59a781052@mail.gmail.com> <4AB03659.9060703@modulus.org> Message-ID: <5f67a8c40909152335k747dc9eao5d56f3cfdc77d3e4@mail.gmail.com> On Tue, Sep 15, 2009 at 8:50 PM, Andrew Snow wrote: > Zaphod Beeblebrox wrote: > > ZFS should be better than that. >> > > Why? ZFS is designed for systems with large amounts of memory to spare - I > don't think it should be used for any system with less than 2GB. > > Most brand new systems bought these days will have at least 2GB, if not 4 > or 8GB. > I don't see why that has to be the case. ZFS is certainly _tuned_ for large filesystems, but it's feature set has many more uses. Pretty much the entire world got the memo that unified buffercache was good. As I understand the stuff I've read, the fact that ZFS (in FreeBSD) isn't unified is largely due to making it easier to import (sure... fine... but) --- meaning that it's an item that should be fixed. As I understand it, ZFS is unified on OpenSolaris. > UFS isn't going away, it is still the filesystem preferred for embedded and > low-end systems. > What... snapshots are suddenly unhelpful on smaller systems? I think not. From pjd at FreeBSD.org Wed Sep 16 15:46:26 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Sep 16 15:46:39 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090915235511.559550e5@sub.han.vpn.gamesnet.de> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> <20090915204404.79cf9325@sub.han.vpn.gamesnet.de> <20090915214142.GA2063@garage.freebsd.pl> <20090915235511.559550e5@sub.han.vpn.gamesnet.de> Message-ID: <20090916154616.GC1656@garage.freebsd.pl> On Tue, Sep 15, 2009 at 11:55:11PM +0200, Tobias Lott wrote: > > > On Tue, 15 Sep 2009 23:41:42 +0200 > Pawel Jakub Dawidek wrote: > > > On Tue, Sep 15, 2009 at 08:44:04PM +0200, Tobias Lott wrote: > > > Any news on this? > > > > Not really. I'm out of ideas. A way to repoduce it would be of course > > best. If you can't provide one maybe you remember something strange > > just before panic, like disk disappeared or something? > > > > Looks like I've found whats causing it by mounting all ZFS Volumes one > by one. It was a Volume used by a Jail running nginx, nagios and some > other stuff. > Weird but luckily not that important since its a Test Machine, can I > provide anything that you could figure out whats wrong with that Volume so it can be fixed? Cause I triggered > this only by upgrading BETA3->4 #3 r196936. What do you mean by 'ZFS Volume' here? You mean ZVOL as created with 'zfs create -V' command? Could you tell me exactly what steps should I take to reproduce the problem? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090916/ad451630/attachment.pgp From tlott at gamesnet.de Wed Sep 16 16:43:12 2009 From: tlott at gamesnet.de (tlott@gamesnet.de) Date: Wed Sep 16 16:43:19 2009 Subject: Problems with ZFS on AMD64 (and i386 now) In-Reply-To: <20090916154616.GC1656@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> <20090915204404.79cf9325@sub.han.vpn.gamesnet.de> <20090915214142.GA2063@garage.freebsd.pl> <20090915235511.559550e5@sub.han.vpn.gamesnet.de> <20090916154616.GC1656@garage.freebsd.pl> Message-ID: > On Tue, Sep 15, 2009 at 11:55:11PM +0200, Tobias Lott wrote: >> >> >> On Tue, 15 Sep 2009 23:41:42 +0200 >> Pawel Jakub Dawidek wrote: >> >> > On Tue, Sep 15, 2009 at 08:44:04PM +0200, Tobias Lott wrote: >> > > Any news on this? >> > >> > Not really. I'm out of ideas. A way to repoduce it would be of course >> > best. If you can't provide one maybe you remember something strange >> > just before panic, like disk disappeared or something? >> > >> >> Looks like I've found whats causing it by mounting all ZFS Volumes one >> by one. It was a Volume used by a Jail running nginx, nagios and some >> other stuff. >> Weird but luckily not that important since its a Test Machine, can I >> provide anything that you could figure out whats wrong with that Volume >> so it can be fixed? Cause I triggered >> this only by upgrading BETA3->4 #3 r196936. > > What do you mean by 'ZFS Volume' here? You mean ZVOL as created with > 'zfs create -V' command? Could you tell me exactly what steps should I > take to reproduce the problem? > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil ? Yes, I Am! > No sorry bad wording from my Side, its just a normal ZFS Filesystem (zfs create tank/filesystem) created some more Filesystem for more Jails on the same Machine yesterday. Couldn't reproduce it so far, so I guess it was just an update gone wrong with the result of one corrupted Filesystem. From gerrit at pmp.uni-hannover.de Thu Sep 17 07:44:18 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Sep 17 07:44:24 2009 Subject: Fw: Linux/KDE and NFS locking on 7-stable Message-ID: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> Hi, since I got exactly no reply on -stable, I try it again here. Please let me know if (and how :-) I can provide more information on this. cu Gerrit Begin forwarded message: Date: Mon, 14 Sep 2009 16:53:04 +0200 From: Gerrit K?hn To: freebsd-stable@freebsd.org Subject: Linux/KDE and NFS locking on 7-stable Hi all, I upgraded a FreeBSD fileserver last week from 7.0-stable to 7.2-stable and experience some weird problems now with Linux NFS clients. The Linux Clients mount their home directories via nfs. I usually use "nolock" on the client side, because file locking was always troublesome in the past. On the Clients the users run kde 3.5 or 4.2. After the update of the server kde 3.5 quit starting up (after logging in with kdm) on the spalsh screen and comes up with some kind of I/O error when writing to the home dir. At the same time the server complains about kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416 Any other window manager (xfce, icewm, mwm, twm) seems to work fine. Playing around with locking, udp/tcp, rebooting some times then somehow magically made it work with kde 3.5 again (although I am using the same mount options in the and as I used before): mclane:/tank/home/gco /tank/home/ghf nfs nfsvers=3,rw,nolock,nordirplus 0 0 Turning locking on definitely does not work (tried it three times). rcp.lockd and rpc.statd are running on the server side, no further tuning done there. KDE 4.2 seems to have better, I have been able to get it working with locking turned on (but it refused to work without locking with the same errors as described above for kde 3.5). I find the whole situation a bit unattractive. Can anybody here give me a hint which combination of mount options should work for a FreeBSD Server running 7.2-stable and Linux clients running 2.6.29 and KDE3/4? I am not that much into performance here, I want a stable working solution. And why, after all, is KDE so picky about locking and nfs homedirs anyway? All other environments appear not to show these problems. cu Gerrit _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From rmacklem at uoguelph.ca Thu Sep 17 14:58:29 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Sep 17 14:58:38 2009 Subject: Fw: Linux/KDE and NFS locking on 7-stable In-Reply-To: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> References: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> Message-ID: On Thu, 17 Sep 2009, Gerrit K??hn wrote: > > I upgraded a FreeBSD fileserver last week from 7.0-stable to 7.2-stable > and experience some weird problems now with Linux NFS clients. > The Linux Clients mount their home directories via nfs. I usually use > "nolock" on the client side, because file locking was always troublesome > in the past. On the Clients the users run kde 3.5 or 4.2. > After the update of the server kde 3.5 quit starting up (after logging > in with kdm) on the spalsh screen and comes up with some kind of I/O error > when writing to the home dir. At the same time the server complains about > > kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416 > I think this happens when the nlm in the server tries to contact the client. I believe setting the following in the server's /etc/rc.conf and rebooting the server (or just killing off lockd on the server), combined with "nolock" as you have on the above Linux mount, might work ok: rpc_lockd_enable="NO" rpc_statd_enable="NO" Imo, the nlm protocol was poorly designed and has always resulted in interoperability problems. Although I fiddle with NFS, I avoid the NLM like the plague:-) Good luck with it, rick ps: If you need to run the lockd on the server, starting the lockd in the Linux client might help, although I'd still use "nolock" on the Linux mount. From mattjreimer at gmail.com Thu Sep 17 18:14:12 2009 From: mattjreimer at gmail.com (Matt Reimer) Date: Thu Sep 17 18:14:18 2009 Subject: Can FreeBSD boot from a pool comprised of multiple vdevs? Message-ID: Is FreeBSD able to boot from a pool comprised of multiple vdevs? If not, what would it take to get it working? I got 8.0-BETA4 booting from a pool comprised of a single raidz vdev, but when I added another raidz vdev it fails to boot with this error: ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset lld Can't find root filesystem - giving up ZFS: unexpected object set type lld ZFS: unexpected object set type lld FreeBSD/i386 boot Default: glamdring:/boot/kernel/kernel boot: ZFS: unexpected object set type lld (Apparently loader's printf() doesn't understand %lld.) Boots successfully with gptzfsboot: # zpool status pool: glamdring state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM glamdring ONLINE 0 0 0 raidz1 ONLINE 0 0 0 label/glamdring-0.0 ONLINE 0 0 0 label/glamdring-0.1 ONLINE 0 0 0 label/glamdring-0.2 ONLINE 0 0 0 errors: No known data errors Does not boot: # zpool status pool: glamdring state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM glamdring ONLINE 0 0 0 raidz1 ONLINE 0 0 0 label/glamdring-0.0 ONLINE 0 0 0 label/glamdring-0.1 ONLINE 0 0 0 label/glamdring-0.2 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 label/glamdring-1.0 ONLINE 0 0 0 label/glamdring-1.1 ONLINE 0 0 0 label/glamdring-1.2 ONLINE 0 0 0 errors: No known data errors Thanks in advance. Matt From fbsdlist at src.cx Thu Sep 17 19:43:36 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Thu Sep 17 19:43:42 2009 Subject: Can FreeBSD boot from a pool comprised of multiple vdevs? In-Reply-To: References: Message-ID: Hi, I've just spent a bit of time investigating the same issue. There was a thread on -current in June that discussed ZFS booting issue and this email suggested that zfsboot does not support gang blocks. http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008589.html If I understand it correctly, gang blocks are used when ZFS can't (or does not want to) allocate contiguous block of required size, so the block is split in sub-blocks that in turn may be gang blocks. I.e. we're looking at a tree of blocks. If that's indeed the case, it implies that even on a single-disk system we may eventually run into a situation when newly installed kernel will be written using gang block and thus would not be handled correctly by zfsboot. That said, I've tried many possible combinations on a VirtualBox running 8.0BETA4 and most of them didn't work. Here's the summary: Zpool configurations I was able to boot from: * 1 disk * 1 mirror of 2 disks * 2 mirrors of 2 disks each * 2-disk raidz (kind of pointless, but..) Configurations that didn't work: * RAIDZ2 with 8 disks * RAIDZ2 with 4 disks * RAIDZ2 with 3 disks * RAIDZ with 8 disks * RAIDZ with 3 disks * 4 mirrors of 2 disks each * 3 mirrors of 3 disks each. Usually gptzfsboot complains that it can't read MOS. Striped multi-disk setups resulted in "can't find dsl_dir". I did some digging in case of RAIDZ2 booting failure and it does look that the failure happens because calculated checksum does not match expected one. Due to lack of my ZFS knowlegde I didn't get deeper than that. --Artem On Thu, Sep 17, 2009 at 10:41 AM, Matt Reimer wrote: > Is FreeBSD able to boot from a pool comprised of multiple vdevs? If > not, what would it take to get it working? > > I got 8.0-BETA4 booting from a pool comprised of a single raidz vdev, > but when I added another raidz vdev it fails to boot with this error: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read object set for dataset lld > Can't find root filesystem - giving up > ZFS: unexpected object set type lld > ZFS: unexpected object set type lld > > FreeBSD/i386 boot > Default: glamdring:/boot/kernel/kernel > boot: > ZFS: unexpected object set type lld > > (Apparently loader's printf() doesn't understand %lld.) > > Boots successfully with gptzfsboot: > > # zpool status > ?pool: glamdring > ?state: ONLINE > ?scrub: none requested > config: > > ? ? ? ?NAME ? ? ? ? ? ? ? ? ? ? STATE ? ? READ WRITE CKSUM > ? ? ? ?glamdring ? ? ? ? ? ? ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ?raidz1 ? ? ? ? ? ? ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-0.0 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-0.1 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-0.2 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > > errors: No known data errors > > Does not boot: > > # zpool status > ?pool: glamdring > ?state: ONLINE > ?scrub: none requested > config: > > ? ? ? ?NAME ? ? ? ? ? ? ? ? ? ? STATE ? ? READ WRITE CKSUM > ? ? ? ?glamdring ? ? ? ? ? ? ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ?raidz1 ? ? ? ? ? ? ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-0.0 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-0.1 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-0.2 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ?raidz1 ? ? ? ? ? ? ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-1.0 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-1.1 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?label/glamdring-1.2 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > > errors: No known data errors > > Thanks in advance. > > Matt > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From gerrit at pmp.uni-hannover.de Fri Sep 18 07:14:38 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Fri Sep 18 07:14:45 2009 Subject: Fw: Linux/KDE and NFS locking on 7-stable In-Reply-To: References: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> Message-ID: <20090918091435.465bfc1e.gerrit@pmp.uni-hannover.de> On Thu, 17 Sep 2009 11:03:55 -0400 (EDT) Rick Macklem wrote about Re: Fw: Linux/KDE and NFS locking on 7-stable: RM> > I upgraded a FreeBSD fileserver last week from 7.0-stable to RM> > 7.2-stable and experience some weird problems now with Linux NFS RM> > clients. The Linux Clients mount their home directories via nfs. I RM> > usually use "nolock" on the client side, because file locking was RM> > always troublesome in the past. On the Clients the users run kde 3.5 RM> > or 4.2. After the update of the server kde 3.5 quit starting up RM> > (after logging in with kdm) on the spalsh screen and comes up with RM> > some kind of I/O error when writing to the home dir. At the same RM> > time the server complains about RM> > kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416 RM> I think this happens when the nlm in the server tries to contact the RM> client. ??? My NFS-Clients are accessing the server via a NAT router. There is no way the server could contact the clients. RM> I believe setting the following in the server's /etc/rc.conf RM> and rebooting the server (or just killing off lockd on the server), RM> combined with "nolock" as you have on the above Linux mount, might RM> work ok: RM> rpc_lockd_enable="NO" RM> rpc_statd_enable="NO" I did not try that so far, as there are some clients which seem to work fine with locking. RM> Imo, the nlm protocol was poorly designed and has always resulted in RM> interoperability problems. Although I fiddle with NFS, I avoid the NLM RM> like the plague:-) Seems so. Why would one want to have a server contact a client anyway? :-) Yesterday I played around with it some more, and have a solution now (at least I hope so :-) with combining "nolock" with "tcp" on the client side. I read some oder mails (from you?) here that stated problems with the new server and strange combinations of mounting via udp and accessing via tcp (although I did not look up what the Linux clients actually do). Before I had either no protocol setting for the clients or they were explicitely using udp (because that solved the problems I had with locking when I was still using 7.0-stable :-). RM> Good luck with it, rick RM> ps: If you need to run the lockd on the server, starting the lockd in RM> the Linux client might help, although I'd still use "nolock" on RM> the Linux mount. I think statd is running on the Linux client anyway. Will have to look for lockd. Thanks for the hints. I still wonder a bit why nfs/locking is often so much of a hassle. Shouldn't it be some kind of established standard technique after all the years? Not that I would want to use smb instead, but still... btw: are there any alternatives? cu Gerrit From ed at FreeBSD.org Fri Sep 18 13:42:25 2009 From: ed at FreeBSD.org (ed@FreeBSD.org) Date: Fri Sep 18 13:42:31 2009 Subject: kern/131995: [nfs] Failure to mount NFSv4 server Message-ID: <200909181342.n8IDgOH3085975@freefall.freebsd.org> Synopsis: [nfs] Failure to mount NFSv4 server Responsible-Changed-From-To: freebsd-fs->rmacklem Responsible-Changed-By: ed Responsible-Changed-When: Fri Sep 18 13:41:51 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=131995 From ed at FreeBSD.org Fri Sep 18 13:42:56 2009 From: ed at FreeBSD.org (ed@FreeBSD.org) Date: Fri Sep 18 13:43:02 2009 Subject: kern/131995: [nfs] Failure to mount NFSv4 server Message-ID: <200909181342.n8IDgunf086026@freefall.freebsd.org> Synopsis: [nfs] Failure to mount NFSv4 server Responsible-Changed-From-To: rmacklem->freebsd-fs Responsible-Changed-By: ed Responsible-Changed-When: Fri Sep 18 13:42:28 UTC 2009 Responsible-Changed-Why: Woops! Better put it back on fs@. It looks like this has something to do with the old NFS implementation. http://www.freebsd.org/cgi/query-pr.cgi?pr=131995 From rmacklem at uoguelph.ca Fri Sep 18 14:51:31 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri Sep 18 14:51:39 2009 Subject: Fw: Linux/KDE and NFS locking on 7-stable In-Reply-To: <20090918091435.465bfc1e.gerrit@pmp.uni-hannover.de> References: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> <20090918091435.465bfc1e.gerrit@pmp.uni-hannover.de> Message-ID: On Fri, 18 Sep 2009, Gerrit KĂźhn wrote: > > ??? > My NFS-Clients are accessing the server via a NAT router. There is no way > the server could contact the clients. > First off, I'll note that I'm not particularily familiar with the NLM and NSM protocols, so take all of this with a grain of salt. My understanding is: - The server calls does a callback to the client when a blocking lock can be granted, if there was a conflicting lock held at the time of the lock request. - The NSM protocol tries to determine when machines have crashed. When a server reboots it will try to notify clients that it has rebooted. (I don't know the protocol well enough to know if there is any other time the server needs to be able to contact the client.) > RM> I believe setting the following in the server's /etc/rc.conf > RM> and rebooting the server (or just killing off lockd on the server), > RM> combined with "nolock" as you have on the above Linux mount, might > RM> work ok: > RM> rpc_lockd_enable="NO" > RM> rpc_statd_enable="NO" > > I did not try that so far, as there are some clients which seem to work > fine with locking. > > RM> Imo, the nlm protocol was poorly designed and has always resulted in > RM> interoperability problems. Although I fiddle with NFS, I avoid the NLM > RM> like the plague:-) > > Seems so. Why would one want to have a server contact a client anyway? :-) For locking correctness, I would agree. For NFSv4, locking should work correctly without a callback network path. For blocking locks, the client must retry the lock request until it succeeds. For recovery, the client discovers that the server has rebooted via error codes returned from the server for open/byte range lock operations. My issues w.r.t. the NLM are: - For the blocking lock, the client is depending on the server to do a callback to let it know when it has the lock. Beyond your NAT case, there are issues related to network partitioning, server crashes,... - It also depends on the NSM to notify it that a server/client has crashed, rebooted, been network partitioned,... (my understanding of it is that a machine basically sends a notify of state to other machines that it thinks cares. If the messages get lost...) > Yesterday I played around with it some more, and have a solution now (at > least I hope so :-) with combining "nolock" with "tcp" on the client side. > I read some oder mails (from you?) here that stated problems with the new > server and strange combinations of mounting via udp and accessing via tcp > (although I did not look up what the Linux clients actually do). > Before I had either no protocol setting for the clients or they were > explicitely using udp (because that solved the problems I had with locking > when I was still using 7.0-stable :-). > > RM> Good luck with it, rick > RM> ps: If you need to run the lockd on the server, starting the lockd in > RM> the Linux client might help, although I'd still use "nolock" on > RM> the Linux mount. > > I think statd is running on the Linux client anyway. Will have to look for > lockd. Thanks for the hints. I still wonder a bit why nfs/locking is often > so much of a hassle. Shouldn't it be some kind of established standard > technique after all the years? Not that I would want to use smb instead, > but still... btw: are there any alternatives? > NFSv2 and 3 are stateless server protocols (no state to recover after a server crash/reboot) and since file locking is by definition "state", there was no locking support. Sun added the separate protocols NLM and NSM to provide locking support for NFS mounted volumes. These were all that was available prior to NFSv4 (which has integrated byte range locking and is not a stateless server). Beyond the fact that I think they were poorly designed protocols, they weren't well published. The only description I am aware of is in "Protocols for X/Open Internetworking: XNFS, Issue 4", which I had to buy for around $75 in 1993. I don't know if it has ever been put online and even it didn't describe the semantics very well, imho. (This delay in publication combined with my opinion on the protocols was why I never implemented them.) rick From gleb.kurtsou at gmail.com Fri Sep 18 17:57:11 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Fri Sep 18 17:57:17 2009 Subject: [patch] tmpfs mmap sync bug fix Message-ID: <20090918172816.GA1449@tops> [ pjd@ CCed to make sure it doesn't apply to zfs ] Mmaped pages can get out of sync in tmpfs. The bug is 100% reproducible by: # fsx -S 125 -d /tmpfs/file It breaks at operation 42. Fix is inspired by zfs, it calls vm_page_cache_free(). Reading zfs sources, it looks like it doesn't check v_object->cache, but never the less bug never shows up on there. Probably it's because of zfs using VOP_BMAP to do page mapping. tmpfs uses default vop_getpages/vop_putpages which invokes vop_read/vop_write accordingly. Removing v_object->cache == NULL checks breaks things again. I'm not entirely sure if it's correct fix and would appreciate vm guru having a look at it, because I do the same thing in my pefs filesystem and It works as expected for me: http://blogs.freebsdish.org/gleb/2009/09/16/pefs-benchmark/ Thank, Gleb. -------------- next part -------------- diff --git a/sys/fs/tmpfs/tmpfs_vnops.c b/sys/fs/tmpfs/tmpfs_vnops.c index db8ceea..59d94d7 100644 --- a/sys/fs/tmpfs/tmpfs_vnops.c +++ b/sys/fs/tmpfs/tmpfs_vnops.c @@ -444,7 +444,8 @@ tmpfs_mappedread(vm_object_t vobj, vm_object_t tobj, size_t len, struct uio *uio offset = addr & PAGE_MASK; tlen = MIN(PAGE_SIZE - offset, len); - if ((vobj == NULL) || (vobj->resident_page_count == 0)) + if ((vobj == NULL) || + (vobj->resident_page_count == 0 && vobj->cache == NULL)) goto nocache; VM_OBJECT_LOCK(vobj); @@ -555,7 +556,8 @@ tmpfs_mappedwrite(vm_object_t vobj, vm_object_t tobj, size_t len, struct uio *ui offset = addr & PAGE_MASK; tlen = MIN(PAGE_SIZE - offset, len); - if ((vobj == NULL) || (vobj->resident_page_count == 0)) { + if ((vobj == NULL) || + (vobj->resident_page_count == 0 && vobj->cache == NULL)) { vpg = NULL; goto nocache; } @@ -573,6 +575,8 @@ lookupvpg: VM_OBJECT_UNLOCK(vobj); error = uiomove_fromphys(&vpg, offset, tlen, uio); } else { + if (__predict_false(vobj->cache != NULL)) + vm_page_cache_free(vobj, idx, idx + 1); VM_OBJECT_UNLOCK(vobj); vpg = NULL; } From Ektron at weic15.com Fri Sep 18 22:39:15 2009 From: Ektron at weic15.com (Ektron) Date: Fri Sep 18 22:39:23 2009 Subject: Download this Web 2.0 Solution for your site - Instant Demo Message-ID: <20090918223915.D743C106566B@hub.freebsd.org> Ektron CMS400.NET provides a complete content management platform with built in SEO management features to ensure your Web site is prepared for the search engines! --------------------------- Register Now for an Instant Demo! (http://www.weic15.com/ets/clk.asp?82255X1M1883803) --------------------------- What if you could... Empower marketing teams to build Web pages on the fly, without sacrificing feature set or control Utilize the extensive out-of-the box features or take advantage of the open architecture Easily build and offer wikis, blogs, forums and the latest in social networking Eliminate risky glue code and make the most of your WCM investment with an integrated e-commerce platform Provide top tier results with our new enterprise search Easily offer RSS, secure subscriptions and web alerts Synchronize content, functionality and membership data securely, from staging to production and back. --------------------------- Register Now for an Instant Demo! (http://www.weic15.com/ets/clk.asp?82255X1M1883803) --------------------------- If you do not want to receive emails from Ektron, please send an email by clicking here (mailto:optout@ektron.com?subject=remove). Ektron, Inc . 542 Amherst Street . Nashua, NH 03063 . +1 (866) 4-EKTRON BizProGuide.com - The Resource for Business Professionals [ fs@freebsd.org ] The preceding is vendor information. If you no longer want to receive this type of information you may indicate that here http://www.weic15.com/r/rm.asp?m=fqqCqKC&o=qZZYY&j=gnKqZb&t=2&e=fs@freebsd.org 1883803 From ktouet at gmail.com Sun Sep 20 22:22:55 2009 From: ktouet at gmail.com (Kurt Touet) Date: Sun Sep 20 22:23:01 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool Message-ID: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> I am using ZFS pool based on a 4-drive raidz1 setup for storage. I believe that one of the drives is failing, and I'd like to remove/replace it. The drive has been causing some issues (such as becoming non-responsive and hanging the system with timeouts), so I'd like to offline it, and then run in degraded mode until I can grab a new drive (tomorrow). However, when I disconnected the drive (pulled the plug, not using a zpool offline command), the following occurred: NAME STATE READ WRITE CKSUM storage FAULTED 0 0 1 raidz1 DEGRADED 0 0 0 ad14 ONLINE 0 0 0 ad6 UNAVAIL 0 0 0 ad12 ONLINE 0 0 0 ad4 ONLINE 0 0 0 Note: That's my recreation of the output... not the actual text. At this point, I was unable to to do anything with the pool... and all data was inaccessible. Fortunately, the after sitting pulled for a bit, I tried putting the failing drive back into the array, and it booted properly. Of course, I still want to replace it, but this is what happens when I try to take it offline: monolith# zpool status storage pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad4 ONLINE 0 0 0 errors: No known data errors monolith# zpool offline storage ad6 cannot offline ad6: no valid replicas monolith# uname -a FreeBSD monolith 8.0-RC1 FreeBSD 8.0-RC1 #2 r197370: Sun Sep 20 15:32:08 CST 2009 k@monolith:/usr/obj/usr/src/sys/MONOLITH amd64 If the array is online and healthy, why can't I simply offline a drive and then replace it afterwards? Any thoughts? Also, how does a degraded raidz1 array end up faulting the entire pool? Thanks, -kurt From aaron at goflexitllc.com Mon Sep 21 11:06:22 2009 From: aaron at goflexitllc.com (Aaron Hurt) Date: Mon Sep 21 11:06:49 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> Message-ID: <4AB757E4.5060501@goflexitllc.com> Kurt Touet wrote: > I am using ZFS pool based on a 4-drive raidz1 setup for storage. I > believe that one of the drives is failing, and I'd like to > remove/replace it. The drive has been causing some issues (such as > becoming non-responsive and hanging the system with timeouts), so I'd > like to offline it, and then run in degraded mode until I can grab a > new drive (tomorrow). However, when I disconnected the drive (pulled > the plug, not using a zpool offline command), the following occurred: > > NAME STATE READ WRITE CKSUM > storage FAULTED 0 0 1 > raidz1 DEGRADED 0 0 0 > ad14 ONLINE 0 0 0 > ad6 UNAVAIL 0 0 0 > ad12 ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > > Note: That's my recreation of the output... not the actual text. > > At this point, I was unable to to do anything with the pool... and all > data was inaccessible. Fortunately, the after sitting pulled for a > bit, I tried putting the failing drive back into the array, and it > booted properly. Of course, I still want to replace it, but this is > what happens when I try to take it offline: > > monolith# zpool status storage > pool: storage > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad14 ONLINE 0 0 0 > ad6 ONLINE 0 0 0 > ad12 ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > > errors: No known data errors > monolith# zpool offline storage ad6 > cannot offline ad6: no valid replicas > monolith# uname -a > FreeBSD monolith 8.0-RC1 FreeBSD 8.0-RC1 #2 r197370: Sun Sep 20 > 15:32:08 CST 2009 k@monolith:/usr/obj/usr/src/sys/MONOLITH amd64 > > If the array is online and healthy, why can't I simply offline a drive > and then replace it afterwards? Any thoughts? Also, how does a > degraded raidz1 array end up faulting the entire pool? > > Thanks, > -kurt > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > !DSPAM:2,4ab6ac55126167777521459! > > I'm not sure why it would be giving you that message. In a raidz1 you should be able to sustain one failure. The only thing that comes to mind this early in the morning would be that somehow your data replication across your discs isn't totally in sync. I would suggest you try a scrub and then see if you can remove the drive afterwards. Aaron Hurt Managing Partner Flex I.T., LLC 611 Commerce Street Suite 3117 Nashville, TN 37203 Phone: 615.438.7101 E-mail: aaron@goflexitllc.com From bugmaster at FreeBSD.org Mon Sep 21 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 21 11:08:03 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200909211106.n8LB6rRe030229@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138367 fs [tmpfs] [panic] 'panic: Assertion pages > 0 failed' wh o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/138109 fs [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2f f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o bin/135314 fs [zfs] assertion failed for zdb(8) usage o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot f kern/134496 fs [zfs] [panic] ZFS pool export occasionally causes a ke o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122047 fs [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / o kern/122038 fs [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o usb/112640 fs [ext2fs] [hang] Kernel freezes when writing a file to o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/105093 fs [ext2fs] [patch] ext2fs on read-only media cannot be m o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/77826 fs [ext2fs] ext2fs usb filesystem will not mount RW o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 140 problems total. From ktouet at gmail.com Mon Sep 21 17:21:46 2009 From: ktouet at gmail.com (Kurt Touet) Date: Mon Sep 21 17:21:52 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <4AB757E4.5060501@goflexitllc.com> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> <4AB757E4.5060501@goflexitllc.com> Message-ID: <2a5e326f0909211021o431ef53bh3077589efb0bed6c@mail.gmail.com> I thought about that possibility as well.. but I had scrubbed the array within 10 days. I'll give it a shot again today and see if that brings up any other errors (or allows me to offline the drive afterwards). Cheers, -kurt On Mon, Sep 21, 2009 at 4:39 AM, Aaron Hurt wrote: > Kurt Touet wrote: >> >> I am using ZFS pool based on a 4-drive raidz1 setup for storage. ?I >> believe that one of the drives is failing, and I'd like to >> remove/replace it. ?The drive has been causing some issues (such as >> becoming non-responsive and hanging the system with timeouts), so I'd >> like to offline it, and then run in degraded mode until I can grab a >> new drive (tomorrow). ?However, when I disconnected the drive (pulled >> the plug, not using a zpool offline command), the following occurred: >> >> ? ? ? ?NAME ? ? ? ?STATE ? ? READ WRITE CKSUM >> ? ? ? ?storage ? ? FAULTED ? ? ? 0 ? ? 0 ? ? 1 >> ? ? ? ? ?raidz1 ? ?DEGRADED ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad14 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad6 ? ? UNAVAIL ? ? ?0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad12 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad4 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> >> Note: That's my recreation of the output... not the actual text. >> >> At this point, I was unable to to do anything with the pool... and all >> data was inaccessible. ?Fortunately, the after sitting pulled for a >> bit, I tried putting the failing drive back into the array, and it >> booted properly. ?Of course, I still want to replace it, but this is >> what happens when I try to take it offline: >> >> monolith# zpool status storage >> ?pool: storage >> ?state: ONLINE >> ?scrub: none requested >> config: >> >> ? ? ? ?NAME ? ? ? ?STATE ? ? READ WRITE CKSUM >> ? ? ? ?storage ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ?raidz1 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad14 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad6 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad12 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ?ad4 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> >> errors: No known data errors >> monolith# zpool offline storage ad6 >> cannot offline ad6: no valid replicas >> monolith# uname -a >> FreeBSD monolith 8.0-RC1 FreeBSD 8.0-RC1 #2 r197370: Sun Sep 20 >> 15:32:08 CST 2009 ? ? k@monolith:/usr/obj/usr/src/sys/MONOLITH ?amd64 >> >> If the array is online and healthy, why can't I simply offline a drive >> and then replace it afterwards? ?Any thoughts? ? Also, how does a >> degraded raidz1 array end up faulting the entire pool? >> >> Thanks, >> -kurt >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> >> !DSPAM:2,4ab6ac55126167777521459! >> >> > > I'm not sure why it would be giving you that message. ?In a raidz1 you > should be able to sustain one failure. ?The only thing that comes to mind > this early in the morning would be that somehow your data replication across > your discs isn't totally in sync. ?I would suggest you try a scrub and then > see if you can remove the drive afterwards. > > Aaron Hurt > Managing Partner > Flex I.T., LLC > 611 Commerce Street > Suite 3117 > Nashville, TN ?37203 > Phone: 615.438.7101 > E-mail: aaron@goflexitllc.com > > From ktouet at gmail.com Mon Sep 21 17:44:29 2009 From: ktouet at gmail.com (Kurt Touet) Date: Mon Sep 21 17:44:35 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <2a5e326f0909211021o431ef53bh3077589efb0bed6c@mail.gmail.com> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> <4AB757E4.5060501@goflexitllc.com> <2a5e326f0909211021o431ef53bh3077589efb0bed6c@mail.gmail.com> Message-ID: <2a5e326f0909211044k349d6bc1lb9bd9094e7216e41@mail.gmail.com> Apparently you were right Aaron: monolith# zpool scrub storage monolith# zpool status storage pool: storage state: ONLINE scrub: resilver completed after 0h1m with 0 errors on Mon Sep 21 11:37:24 2009 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad14 ONLINE 0 0 0 1.46M resilvered ad6 ONLINE 0 0 0 2K resilvered ad12 ONLINE 0 0 0 3K resilvered ad4 ONLINE 0 0 0 3K resilvered errors: No known data errors monolith# zpool offline storage ad6 monolith# zpool online storage ad6 monolith# zpool status storage pool: storage state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Mon Sep 21 11:40:12 2009 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad14 ONLINE 0 0 0 67.5K resilvered ad6 ONLINE 0 0 0 671K resilvered ad12 ONLINE 0 0 0 67.5K resilvered ad4 ONLINE 0 0 0 53K resilvered errors: No known data errors I wonder then, with the storage array reporting itself as healthy, how did it know that one drive had desynced data, and why wouldn't that have shown up as an error like DEGRADED? Cheers, -kurt On Mon, Sep 21, 2009 at 11:21 AM, Kurt Touet wrote: > I thought about that possibility as well.. but I had scrubbed the > array within 10 days. I'll give it a shot again today and see if that > brings up any other errors (or allows me to offline the drive > afterwards). > > Cheers, > -kurt > > On Mon, Sep 21, 2009 at 4:39 AM, Aaron Hurt wrote: >> Kurt Touet wrote: >>> >>> I am using ZFS pool based on a 4-drive raidz1 setup for storage. ?I >>> believe that one of the drives is failing, and I'd like to >>> remove/replace it. ?The drive has been causing some issues (such as >>> becoming non-responsive and hanging the system with timeouts), so I'd >>> like to offline it, and then run in degraded mode until I can grab a >>> new drive (tomorrow). ?However, when I disconnected the drive (pulled >>> the plug, not using a zpool offline command), the following occurred: >>> >>> ? ? ? ?NAME ? ? ? ?STATE ? ? READ WRITE CKSUM >>> ? ? ? ?storage ? ? FAULTED ? ? ? 0 ? ? 0 ? ? 1 >>> ? ? ? ? ?raidz1 ? ?DEGRADED ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad14 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad6 ? ? UNAVAIL ? ? ?0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad12 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad4 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> >>> Note: That's my recreation of the output... not the actual text. >>> >>> At this point, I was unable to to do anything with the pool... and all >>> data was inaccessible. ?Fortunately, the after sitting pulled for a >>> bit, I tried putting the failing drive back into the array, and it >>> booted properly. ?Of course, I still want to replace it, but this is >>> what happens when I try to take it offline: >>> >>> monolith# zpool status storage >>> ?pool: storage >>> ?state: ONLINE >>> ?scrub: none requested >>> config: >>> >>> ? ? ? ?NAME ? ? ? ?STATE ? ? READ WRITE CKSUM >>> ? ? ? ?storage ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ?raidz1 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad14 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad6 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad12 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> ? ? ? ? ? ?ad4 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >>> >>> errors: No known data errors >>> monolith# zpool offline storage ad6 >>> cannot offline ad6: no valid replicas >>> monolith# uname -a >>> FreeBSD monolith 8.0-RC1 FreeBSD 8.0-RC1 #2 r197370: Sun Sep 20 >>> 15:32:08 CST 2009 ? ? k@monolith:/usr/obj/usr/src/sys/MONOLITH ?amd64 >>> >>> If the array is online and healthy, why can't I simply offline a drive >>> and then replace it afterwards? ?Any thoughts? ? Also, how does a >>> degraded raidz1 array end up faulting the entire pool? >>> >>> Thanks, >>> -kurt >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>> >>> !DSPAM:2,4ab6ac55126167777521459! >>> >>> >> >> I'm not sure why it would be giving you that message. ?In a raidz1 you >> should be able to sustain one failure. ?The only thing that comes to mind >> this early in the morning would be that somehow your data replication across >> your discs isn't totally in sync. ?I would suggest you try a scrub and then >> see if you can remove the drive afterwards. >> >> Aaron Hurt >> Managing Partner >> Flex I.T., LLC >> 611 Commerce Street >> Suite 3117 >> Nashville, TN ?37203 >> Phone: 615.438.7101 >> E-mail: aaron@goflexitllc.com >> >> > From aaron at goflexitllc.com Tue Sep 22 01:26:16 2009 From: aaron at goflexitllc.com (Aaron Hurt) Date: Tue Sep 22 01:26:23 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <2a5e326f0909211044k349d6bc1lb9bd9094e7216e41@mail.gmail.com> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> <4AB757E4.5060501@goflexitllc.com> <2a5e326f0909211021o431ef53bh3077589efb0bed6c@mail.gmail.com> <2a5e326f0909211044k349d6bc1lb9bd9094e7216e41@mail.gmail.com> Message-ID: <4AB827AA.9080109@goflexitllc.com> Kurt Touet wrote: > Apparently you were right Aaron: > > monolith# zpool scrub storage > monolith# zpool status storage > pool: storage > state: ONLINE > scrub: resilver completed after 0h1m with 0 errors on Mon Sep 21 11:37:24 2009 > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad14 ONLINE 0 0 0 1.46M resilvered > ad6 ONLINE 0 0 0 2K resilvered > ad12 ONLINE 0 0 0 3K resilvered > ad4 ONLINE 0 0 0 3K resilvered > > errors: No known data errors > monolith# zpool offline storage ad6 > monolith# zpool online storage ad6 > monolith# zpool status storage > pool: storage > state: ONLINE > scrub: resilver completed after 0h0m with 0 errors on Mon Sep 21 11:40:12 2009 > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad14 ONLINE 0 0 0 67.5K resilvered > ad6 ONLINE 0 0 0 671K resilvered > ad12 ONLINE 0 0 0 67.5K resilvered > ad4 ONLINE 0 0 0 53K resilvered > > errors: No known data errors > > > I wonder then, with the storage array reporting itself as healthy, how > did it know that one drive had desynced data, and why wouldn't that > have shown up as an error like DEGRADED? > > Cheers, > -kurt > > > On Mon, Sep 21, 2009 at 11:21 AM, Kurt Touet wrote: > >> I thought about that possibility as well.. but I had scrubbed the >> array within 10 days. I'll give it a shot again today and see if that >> brings up any other errors (or allows me to offline the drive >> afterwards). >> >> Cheers, >> -kurt >> >> On Mon, Sep 21, 2009 at 4:39 AM, Aaron Hurt wrote: >> >>> Kurt Touet wrote: >>> >>>> I am using ZFS pool based on a 4-drive raidz1 setup for storage. I >>>> believe that one of the drives is failing, and I'd like to >>>> remove/replace it. The drive has been causing some issues (such as >>>> becoming non-responsive and hanging the system with timeouts), so I'd >>>> like to offline it, and then run in degraded mode until I can grab a >>>> new drive (tomorrow). However, when I disconnected the drive (pulled >>>> the plug, not using a zpool offline command), the following occurred: >>>> >>>> NAME STATE READ WRITE CKSUM >>>> storage FAULTED 0 0 1 >>>> raidz1 DEGRADED 0 0 0 >>>> ad14 ONLINE 0 0 0 >>>> ad6 UNAVAIL 0 0 0 >>>> ad12 ONLINE 0 0 0 >>>> ad4 ONLINE 0 0 0 >>>> >>>> Note: That's my recreation of the output... not the actual text. >>>> >>>> At this point, I was unable to to do anything with the pool... and all >>>> data was inaccessible. Fortunately, the after sitting pulled for a >>>> bit, I tried putting the failing drive back into the array, and it >>>> booted properly. Of course, I still want to replace it, but this is >>>> what happens when I try to take it offline: >>>> >>>> monolith# zpool status storage >>>> pool: storage >>>> state: ONLINE >>>> scrub: none requested >>>> config: >>>> >>>> NAME STATE READ WRITE CKSUM >>>> storage ONLINE 0 0 0 >>>> raidz1 ONLINE 0 0 0 >>>> ad14 ONLINE 0 0 0 >>>> ad6 ONLINE 0 0 0 >>>> ad12 ONLINE 0 0 0 >>>> ad4 ONLINE 0 0 0 >>>> >>>> errors: No known data errors >>>> monolith# zpool offline storage ad6 >>>> cannot offline ad6: no valid replicas >>>> monolith# uname -a >>>> FreeBSD monolith 8.0-RC1 FreeBSD 8.0-RC1 #2 r197370: Sun Sep 20 >>>> 15:32:08 CST 2009 k@monolith:/usr/obj/usr/src/sys/MONOLITH amd64 >>>> >>>> If the array is online and healthy, why can't I simply offline a drive >>>> and then replace it afterwards? Any thoughts? Also, how does a >>>> degraded raidz1 array end up faulting the entire pool? >>>> >>>> Thanks, >>>> -kurt >>>> _______________________________________________ >>>> freebsd-fs@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>>> >>>> >>>> >>>> >>>> >>> I'm not sure why it would be giving you that message. In a raidz1 you >>> should be able to sustain one failure. The only thing that comes to mind >>> this early in the morning would be that somehow your data replication across >>> your discs isn't totally in sync. I would suggest you try a scrub and then >>> see if you can remove the drive afterwards. >>> >>> Aaron Hurt >>> Managing Partner >>> Flex I.T., LLC >>> 611 Commerce Street >>> Suite 3117 >>> Nashville, TN 37203 >>> Phone: 615.438.7101 >>> E-mail: aaron@goflexitllc.com >>> >>> >>> > > !DSPAM:2,4ab7bc3e126161245783902! > > I had a buggy ata controller that was causing similar problems for me once upon a time. I replaced the controller card and drive cables and never had any more issues with it. That's still one of those things I just scratch my head over. I'm far from a ZFS code expert so I couldn't even begin to tell you the underlying reasons such things might be related...just my two cents worth of experience. Anyways...glad it's working for you now. -- Aaron Hurt Managing Partner Flex I.T., LLC 611 Commerce Street Suite 3117 Nashville, TN 37203 Phone: 615.438.7101 E-mail: aaron@goflexitllc.com From linimon at FreeBSD.org Tue Sep 22 04:16:19 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 22 04:16:31 2009 Subject: kern/139039: [zfs] zpool scrub makes system unbearably slow Message-ID: <200909220416.n8M4GJCf076367@freefall.freebsd.org> Old Synopsis: zpool scrub makes system unbearably slow New Synopsis: [zfs] zpool scrub makes system unbearably slow Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 22 04:16:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139039 From pjd at FreeBSD.org Tue Sep 22 12:56:29 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Sep 22 12:56:37 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> Message-ID: <20090922125625.GJ6038@garage.freebsd.pl> On Sun, Sep 20, 2009 at 04:00:10PM -0600, Kurt Touet wrote: > I am using ZFS pool based on a 4-drive raidz1 setup for storage. I > believe that one of the drives is failing, and I'd like to > remove/replace it. The drive has been causing some issues (such as > becoming non-responsive and hanging the system with timeouts), so I'd > like to offline it, and then run in degraded mode until I can grab a > new drive (tomorrow). However, when I disconnected the drive (pulled > the plug, not using a zpool offline command), the following occurred: > > NAME STATE READ WRITE CKSUM > storage FAULTED 0 0 1 > raidz1 DEGRADED 0 0 0 > ad14 ONLINE 0 0 0 > ad6 UNAVAIL 0 0 0 > ad12 ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > > Note: That's my recreation of the output... not the actual text. > > At this point, I was unable to to do anything with the pool... and all > data was inaccessible. Fortunately, the after sitting pulled for a > bit, I tried putting the failing drive back into the array, and it > booted properly. Of course, I still want to replace it, but this is > what happens when I try to take it offline: > > monolith# zpool status storage > pool: storage > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad14 ONLINE 0 0 0 > ad6 ONLINE 0 0 0 > ad12 ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > > errors: No known data errors > monolith# zpool offline storage ad6 > cannot offline ad6: no valid replicas Could you send the output of: # apply "zdb -l /dev/%1" ad{4,6,12,14} -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090922/33763e40/attachment.pgp From james-freebsd-fs2 at jrv.org Tue Sep 22 14:19:51 2009 From: james-freebsd-fs2 at jrv.org (James R. Van Artsdalen) Date: Tue Sep 22 14:19:58 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <2a5e326f0909211044k349d6bc1lb9bd9094e7216e41@mail.gmail.com> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> <4AB757E4.5060501@goflexitllc.com> <2a5e326f0909211021o431ef53bh3077589efb0bed6c@mail.gmail.com> <2a5e326f0909211044k349d6bc1lb9bd9094e7216e41@mail.gmail.com> Message-ID: <4AB8D829.4060301@jrv.org> Kurt Touet wrote: > I wonder then, with the storage array reporting itself as healthy, how > did it know that one drive had desynced data, and why wouldn't that > have shown up as an error like DEGRADED? The uberblock on each ZFS disk contains a txtag, in effect a revision number. When a pool is imported and one drive's txtag is older than the others then that drive needs resilvering. From ktouet at gmail.com Tue Sep 22 17:07:24 2009 From: ktouet at gmail.com (Kurt Touet) Date: Tue Sep 22 17:07:31 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <20090922125625.GJ6038@garage.freebsd.pl> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> <20090922125625.GJ6038@garage.freebsd.pl> Message-ID: <2a5e326f0909221007m71a84f34r8c07648f8bc8b1ac@mail.gmail.com> On Tue, Sep 22, 2009 at 6:56 AM, Pawel Jakub Dawidek wrote: > On Sun, Sep 20, 2009 at 04:00:10PM -0600, Kurt Touet wrote: >> I am using ZFS pool based on a 4-drive raidz1 setup for storage. ?I >> believe that one of the drives is failing, and I'd like to >> remove/replace it. ?The drive has been causing some issues (such as >> becoming non-responsive and hanging the system with timeouts), so I'd >> like to offline it, and then run in degraded mode until I can grab a >> new drive (tomorrow). ?However, when I disconnected the drive (pulled >> the plug, not using a zpool offline command), the following occurred: >> >> ? ? ? ? NAME ? ? ? ?STATE ? ? READ WRITE CKSUM >> ? ? ? ? storage ? ? FAULTED ? ? ? 0 ? ? 0 ? ? 1 >> ? ? ? ? ? raidz1 ? ?DEGRADED ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad14 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad6 ? ? UNAVAIL ? ? ?0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad12 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad4 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> >> Note: That's my recreation of the output... not the actual text. >> >> At this point, I was unable to to do anything with the pool... and all >> data was inaccessible. ?Fortunately, the after sitting pulled for a >> bit, I tried putting the failing drive back into the array, and it >> booted properly. ?Of course, I still want to replace it, but this is >> what happens when I try to take it offline: >> >> monolith# zpool status storage >> ? pool: storage >> ?state: ONLINE >> ?scrub: none requested >> config: >> >> ? ? ? ? NAME ? ? ? ?STATE ? ? READ WRITE CKSUM >> ? ? ? ? storage ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? raidz1 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad14 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad6 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad12 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? ? ? ad4 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> >> errors: No known data errors >> monolith# zpool offline storage ad6 >> cannot offline ad6: no valid replicas > > Could you send the output of: > > ? ? ? ?# apply "zdb -l /dev/%1" ad{4,6,12,14} > Sure thing. -------------- next part -------------- -------------------------------------------- LABEL 0 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6504613440151659848 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 1 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6504613440151659848 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 2 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6504613440151659848 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 3 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6504613440151659848 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 0 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=12485416462231715770 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 1 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=12485416462231715770 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 2 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=12485416462231715770 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 3 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=12485416462231715770 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 0 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6817203917234297503 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 1 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6817203917234297503 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 2 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6817203917234297503 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 3 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=6817203917234297503 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 0 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=4699988331335899116 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 1 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=4699988331335899116 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 2 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=4699988331335899116 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 -------------------------------------------- LABEL 3 -------------------------------------------- version=13 name='storage' state=0 txg=3688995 pool_guid=5578023476090267517 hostid=2292452270 hostname='monolith' top_guid=16261364677366705650 guid=4699988331335899116 vdev_tree type='raidz' id=0 guid=16261364677366705650 nparity=1 metaslab_array=14 metaslab_shift=32 ashift=9 asize=6001188143104 is_log=0 children[0] type='disk' id=0 guid=4699988331335899116 path='/dev/ad14' whole_disk=0 DTL=337 children[1] type='disk' id=1 guid=12485416462231715770 path='/dev/ad6' whole_disk=0 DTL=336 children[2] type='disk' id=2 guid=6817203917234297503 path='/dev/ad12' whole_disk=0 DTL=335 children[3] type='disk' id=3 guid=6504613440151659848 path='/dev/ad4' whole_disk=0 DTL=334 From scf at FreeBSD.org Tue Sep 22 18:57:06 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Sep 22 18:57:13 2009 Subject: Proper gmirror install Message-ID: I posted this about a week ago on freebsd-geom, but this list may be more appropriate for this. I have been experimenting with installing FreeBSD using only gpart from the 8.0-BETA4 DVD. It has been helping my understanding of GPT vs. MBR. Now, I would like to verify the setup[1] I have made and the messages I am getting from it. The basic setup is for both disks: Slice Type Size ad0s1 Windows7 system 100MB ad0s2 Windows7 20GB gm0s3 FreeBSD (non-swap) 20GB ad0s3 and ad1s3 ad0s4 FreeBSD (swap) 2GB I am creating the mirror prior to creating the BSD label. I also take it from this posting[2] that it is the preferred method. Everything appears correct, however, I am getting these messages: GEOM: ad0s3: geometry does not match label (255h,63s != 16h,63s). GEOM: ad0s3: media size does not match label. GEOM: ad1s3: geometry does not match label (255h,63s != 16h,63s) GEOM: ad1s3: media size does not match label. Questions: 1. Is this due to the BSD label being within the mirror and is considered safe? 2. Am I correct in my understanding that having the BSD label within the mirror takes care of the need to hardcode the provider's name and/or subtracting one from the c: partition? 3. Other than not being able to boot directly from those slices (untried; maybe not true) as opposed to the mirrored slice, is there any other concern doing it this way? 4. gpart allows more than four slices to be created. Are those primary, extended or something else? 5. Any other suggestions? I plan on putting this example on the wiki once it is verified to be correct. BTW, I must say I like using gpart after getting used to it. It would be nice if it could also handle creating and maintaining a hybrid MBR/GPT setup. Sean 1. http://people.freebsd.org/~scf/gmirror-install.txt 2. http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008638.html -- scf@FreeBSD.org From ktouet at gmail.com Tue Sep 22 19:30:31 2009 From: ktouet at gmail.com (Kurt Touet) Date: Tue Sep 22 19:30:37 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <20090922125625.GJ6038@garage.freebsd.pl> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> <20090922125625.GJ6038@garage.freebsd.pl> Message-ID: <2a5e326f0909221230m6c7e4828md5f70a5ac6c7892b@mail.gmail.com> On Tue, Sep 22, 2009 at 6:56 AM, Pawel Jakub Dawidek wrote: > > Could you send the output of: > > ? ? ? ?# apply "zdb -l /dev/%1" ad{4,6,12,14} > > -- > Pawel Jakub Dawidek ? ? ? ? ? ? ? ? ? ? ? http://www.wheel.pl > pjd@FreeBSD.org ? ? ? ? ? ? ? ? ? ? ? ? ? http://www.FreeBSD.org > FreeBSD committer ? ? ? ? ? ? ? ? ? ? ? ? Am I Evil? Yes, I Am! > I was looking back at the thread, and realized that you had replied to my first message and not the subsequent one (where I had successfully scrubbed and resilvered the drive) -- so the debug output was from the properly resilvered array. Although the one question that still stands (for me), is how the system would have reported itself as healthy after I successfully reattached the failing driving. It strikes me as the type of situation where a checksum error or degraded status should appear. Am I wrong in thinking that, or is there another way in which this could be detected? Looking at James comment, if the one drive had an older txtag, should that have generated a non-healthy state? Cheers, -kurt From linimon at FreeBSD.org Tue Sep 22 23:15:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 22 23:15:37 2009 Subject: kern/139059: [zfs] zfs(64bit) nfs server fails open(..., O_WRONLY|O_CREAT|O_EXCL, ...) Message-ID: <200909222315.n8MNFKJw067714@freefall.freebsd.org> Old Synopsis: zfs(64bit) nfs server fails open(..., O_WRONLY|O_CREAT|O_EXCL, ...) New Synopsis: [zfs] zfs(64bit) nfs server fails open(..., O_WRONLY|O_CREAT|O_EXCL, ...) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 22 23:15:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139059 From linimon at FreeBSD.org Wed Sep 23 05:43:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 23 05:44:01 2009 Subject: kern/139072: [zfs] zfs marked as production ready but it used a deprecated checksum algorithm Message-ID: <200909230543.n8N5hmLR059763@freefall.freebsd.org> Old Synopsis: zfs marked as production ready but it used a deprecated checksum algorithm New Synopsis: [zfs] zfs marked as production ready but it used a deprecated checksum algorithm Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 23 05:43:28 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139072 From gavin at FreeBSD.org Wed Sep 23 08:11:57 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Sep 23 08:12:09 2009 Subject: kern/139076: [zfs] ZFS file system has SysV group ownership semantics not BSD Message-ID: <200909230811.n8N8Bvfp039562@freefall.freebsd.org> Synopsis: [zfs] ZFS file system has SysV group ownership semantics not BSD Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Wed Sep 23 08:10:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). Not sure there's anything that can be done about this, other than documenting it. http://www.freebsd.org/cgi/query-pr.cgi?pr=139076 From pjd at FreeBSD.org Wed Sep 23 09:18:38 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 23 09:18:45 2009 Subject: kern/139076: [zfs] ZFS file system has SysV group ownership semantics not BSD Message-ID: <200909230918.n8N9IcQH003508@freefall.freebsd.org> Synopsis: [zfs] ZFS file system has SysV group ownership semantics not BSD State-Changed-From-To: open->patched State-Changed-By: pjd State-Changed-When: śro 23 wrz 2009 09:15:31 UTC State-Changed-Why: Fix committed to HEAD. Thank you for the report! Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: śro 23 wrz 2009 09:15:31 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=139076 From pjd at FreeBSD.org Wed Sep 23 09:19:13 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 23 09:19:19 2009 Subject: kern/139059: [zfs] zfs(64bit) nfs server fails open(..., O_WRONLY|O_CREAT|O_EXCL, ...) Message-ID: <200909230919.n8N9JC2N003617@freefall.freebsd.org> Synopsis: [zfs] zfs(64bit) nfs server fails open(..., O_WRONLY|O_CREAT|O_EXCL, ...) Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: śro 23 wrz 2009 09:18:57 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=139059 From pjd at FreeBSD.org Wed Sep 23 09:20:19 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Wed Sep 23 09:20:36 2009 Subject: kern/139072: [zfs] zfs marked as production ready but it used a deprecated checksum algorithm Message-ID: <200909230920.n8N9KIJ6005528@freefall.freebsd.org> Synopsis: [zfs] zfs marked as production ready but it used a deprecated checksum algorithm Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: śro 23 wrz 2009 09:19:57 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=139072 From gavin at FreeBSD.org Wed Sep 23 13:08:30 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Sep 23 13:08:36 2009 Subject: usb/112640: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk Message-ID: <200909231308.n8ND8T8l035372@freefall.freebsd.org> Synopsis: [ext2fs] [hang] Kernel freezes when writing a file to an ex2fs filesystem on a usb disk State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Wed Sep 23 13:07:06 UTC 2009 State-Changed-Why: Submitter was asked for feedback http://www.freebsd.org/cgi/query-pr.cgi?pr=112640 From pjd at FreeBSD.org Fri Sep 25 18:28:56 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Fri Sep 25 18:30:13 2009 Subject: kern/139039: [zfs] zpool scrub makes system unbearably slow Message-ID: <200909251828.n8PISu6Z031842@freefall.freebsd.org> Synopsis: [zfs] zpool scrub makes system unbearably slow State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: ptk 25 wrz 2009 18:27:48 UTC State-Changed-Why: Could you tell which threads are consuming most CPU time? Pasting first few lines from 'top -SH' should be enough. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: ptk 25 wrz 2009 18:27:48 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=139039 From sullrich at gmail.com Fri Sep 25 19:28:16 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Sep 25 19:28:22 2009 Subject: Slow disk write IO with ZFS / NFS Message-ID: Hello, Now that ZFS has been declared "Production ready" I have been playing around with RC1 + NFS + ZFS. It seems that write speeds when using ZFS + NFS are pretty poor (on average 5 megabyte a second). When I bench the ZFS pool without NFS I can see up to 175 megabytes a second write speed. The system in question is a Dell 2850 with 6 ULTRA 300 SCSI 10K RPM drives (Dual 3.4 ghz XEON) running RC1/AMD64: FreeBSD freebsd8.cre8.com 8.0-BETA4 FreeBSD 8.0-BETA4 #2: Fri Sep 25 10:55:46 UTC 2009 sullrich@freebsd8.cre8.com:/usr/obj/usr/src/sys/GENERIC amd64 NFS is setup like: /etc/rc.conf: rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_server_enable="YES" /etc/exports: /vmfs -maproot=root -network 10.0.250.0 -mask 255.255.255. Does anyone have any pointers on how to speed this up without putting the data in jeopardy during a power failure, etc (ie: leaving ZIL on). Thanks in advance, Scott From nwf at cs.jhu.edu Fri Sep 25 19:56:52 2009 From: nwf at cs.jhu.edu (Nathaniel W Filardo) Date: Fri Sep 25 19:57:24 2009 Subject: kern/139039: [zfs] zpool scrub makes system unbearably slow In-Reply-To: <200909251828.n8PISu6Z031842@freefall.freebsd.org> Message-ID: <20090925192156.GF22220@gradx.cs.jhu.edu> On Fri, Sep 25, 2009 at 06:28:56PM +0000, pjd@freebsd.org wrote: > Synopsis: [zfs] zpool scrub makes system unbearably slow > > State-Changed-From-To: open->feedback > State-Changed-By: pjd > State-Changed-When: ptk 25 wrz 2009 18:27:48 UTC > State-Changed-Why: > Could you tell which threads are consuming most CPU time? > Pasting first few lines from 'top -SH' should be enough. > > > Responsible-Changed-From-To: freebsd-fs->pjd > Responsible-Changed-By: pjd > Responsible-Changed-When: ptk 25 wrz 2009 18:27:48 UTC > Responsible-Changed-Why: > I'll take this one. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=139039 Thanks for looking at this. The system here is trying to build OpenLDAP in a jail, but that isn't frequently in the top. Typical output is... hydra# top -jSHP 267 processes: 15 running, 236 sleeping, 16 waiting CPU 0: 0.3% user, 0.0% nice, 97.4% system, 2.3% interrupt, 0.0% idle CPU 1: 10.7% user, 0.0% nice, 44.4% system, 1.8% interrupt, 43.0% idle Mem: 147M Active, 242M Inact, 926M Wired, 4008K Cache, 213M Buf, 672M Free Swap: 4096M Total, 4096M Free PID JID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 0 root 171 ki31 0K 64K RUN 1 376:41 57.18% {idle: cpu1} 0 0 root -16 0 0K 3520K CPU0 0 6:04 13.96% {spa_zio_7} 0 0 root -16 0 0K 3520K - 0 5:58 13.33% {spa_zio_0} 0 0 root -16 0 0K 3520K - 0 5:58 13.13% {spa_zio_3} 0 0 root -16 0 0K 3520K - 0 6:01 13.09% {spa_zio_5} 0 0 root -16 0 0K 3520K RUN 0 6:01 13.04% {spa_zio_2} 0 0 root -16 0 0K 3520K RUN 0 6:00 13.04% {spa_zio_6} 0 0 root -16 0 0K 3520K - 0 5:59 12.65% {spa_zio_1} 0 0 root -16 0 0K 3520K - 1 6:00 12.11% {spa_zio_4} 42 0 root -8 - 0K 480K spa->s 0 4:50 8.54% {txg_thread_enter} 4 0 root -8 - 0K 32K - 0 2:13 1.95% g_down 12 0 root -40 - 0K 544K WAIT 0 1:25 0.98% {swi2: cambio} 0 0 root -16 0 0K 3520K - 0 0:24 0.20% {spa_zio_7} 0 0 root -16 0 0K 3520K - 1 0:23 0.20% {spa_zio_3} 12 0 root -64 - 0K 544K RUN 0 0:45 0.15% {vec1860: mpt0} 0 0 root -16 0 0K 3520K - 1 0:58 0.10% {spa_zio} 12 0 root -32 - 0K 544K WAIT 0 1:58 0.05% {swi4: clock} 42 0 root -8 - 0K 480K tx->tx 1 0:31 0.05% {txg_thread_enter} 11 0 root 171 ki31 0K 64K RUN 0 774:48 0.00% {idle: cpu0} The only thing that seems odd to me is that CPU1 is sitting essientially idle (I have never seen CPU0 be idle when the system is scrubbing). The spa_zio_* threads do in fact run on CPU1, but seemingly rarely. --nwf; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090925/dfabdeb4/attachment.pgp From andrew at modulus.org Fri Sep 25 23:51:39 2009 From: andrew at modulus.org (Andrew Snow) Date: Fri Sep 25 23:51:45 2009 Subject: Slow disk write IO with ZFS / NFS In-Reply-To: References: Message-ID: <4ABD56D6.50301@modulus.org> Scott Ullrich wrote: > Does anyone have any pointers on how to speed this up without putting > the data in jeopardy during a power failure, etc (ie: leaving ZIL on). NFS writes are syncronous so ZFS is constantly syncing small datablocks to disk. By default the transaction log is stored on the same disks as the rest of the data. You might like to try an async NFS mount, but this isn't much different from just turning off the ZIL. Failing that, Add a log device to the pool, SSD or ramdisk is ideal, but separate disk HDD spindles to your data zpool also works pretty well. - Andrew From bugmaster at FreeBSD.org Mon Sep 28 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 28 11:07:57 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200909281106.n8SB6rgQ063987@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138367 fs [tmpfs] [panic] 'panic: Assertion pages > 0 failed' wh o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/138109 fs [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2f f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o bin/135314 fs [zfs] assertion failed for zdb(8) usage o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot f kern/134496 fs [zfs] [panic] ZFS pool export occasionally causes a ke o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122047 fs [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / o kern/122038 fs [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b f usb/112640 fs [ext2fs] [hang] Kernel freezes when writing a file to o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/105093 fs [ext2fs] [patch] ext2fs on read-only media cannot be m o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/77826 fs [ext2fs] ext2fs usb filesystem will not mount RW o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 140 problems total. From pjd at FreeBSD.org Mon Sep 28 17:26:08 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 28 17:26:14 2009 Subject: bin/135314: [zfs] assertion failed for zdb(8) usage Message-ID: <200909281726.n8SHQ761059343@freefall.freebsd.org> Synopsis: [zfs] assertion failed for zdb(8) usage State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: pon 28 wrz 2009 17:25:25 UTC State-Changed-Why: Can you reproduce it on 8.0-RC1? It works for me. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 28 wrz 2009 17:25:25 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=135314 From ktouet at gmail.com Mon Sep 28 17:29:20 2009 From: ktouet at gmail.com (Kurt Touet) Date: Mon Sep 28 17:29:26 2009 Subject: ZFS - Unable to offline drive in raidz1 based pool In-Reply-To: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> References: <2a5e326f0909201500w1513aeb5ra644f1c748e22f34@mail.gmail.com> Message-ID: <2a5e326f0909281029p17334ceeoff4bb3e7adeb5cef@mail.gmail.com> I've run into a similar experience again with my zfs raidz1 array reporting itself as healthy when it's not. This, again, was after some drive spin_retry_count errors (and a power cycle when unable to shutdown -h). The pattern goes as follows: 1) A hard drive in the zfs array (for whatever reason) repeatedly times out.. in this case, generating spin_retry_count errors in the smart status. 2) The box is semi-frozen because it cannot deal with activity on the zfs array, so it won't gracefully shutdown -h now. 3) The box is power cycled. 4) Everything spins up fine on the box, the array is now accessible. 5) zpool status - shows the array as online with no degraded status 6) zpool scrub - shows the drives to be desynced and resilvers a couple of them 7) presumably, everything is fine monolith# zpool status pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad4 ONLINE 0 0 0 spares ad22 AVAIL errors: No known data errors monolith# zpool scrub storage monolith# zpool status pool: storage state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Mon Sep 28 11:17:05 2009 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad14 ONLINE 0 0 0 1.17M resilvered ad6 ONLINE 0 0 0 1.50K resilvered ad12 ONLINE 0 0 0 2K resilvered ad4 ONLINE 0 0 0 2K resilvered spares ad22 AVAIL errors: No known data errors So, my question still stands.. how does zfs upon scrubbing, instantly know that the drives need to be resilvered (it completes in a few seconds), but previous declares the array to be fine with no known date errors? Cheers, -kurt From pjd at FreeBSD.org Mon Sep 28 17:52:33 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 28 17:52:40 2009 Subject: kern/134496: [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt") Message-ID: <200909281752.n8SHqX7i090329@freefall.freebsd.org> Synopsis: [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt") State-Changed-From-To: feedback->closed State-Changed-By: pjd State-Changed-When: pon 28 wrz 2009 17:49:56 UTC State-Changed-Why: I don't believe this problem still exists and I cannot reproduce it with proposed procedure. Let me know if the problem still exists in 8.0. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 28 wrz 2009 17:49:56 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=134496 From pjd at FreeBSD.org Mon Sep 28 17:59:57 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Mon Sep 28 18:00:04 2009 Subject: kern/128633: [zfs] [lor] lock order reversal in zfs Message-ID: <200909281759.n8SHxvBW090508@freefall.freebsd.org> Synopsis: [zfs] [lor] lock order reversal in zfs State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: pon 28 wrz 2009 17:58:06 UTC State-Changed-Why: Can you show how how lines around line 1123 in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c looks like on the source your kernel was compiled from? Same for sys/kern/vfs_subr.c:372. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 28 wrz 2009 17:58:06 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=128633 From rincebrain at gmail.com Mon Sep 28 18:41:44 2009 From: rincebrain at gmail.com (Rich) Date: Mon Sep 28 18:41:50 2009 Subject: zpool replace 'stuck' Message-ID: <5da0588e0909281120p301bf75fi1bfda50c1a0a7ef0@mail.gmail.com> Hello, world. On 8.0-RC1 amd64, I seem to have run into the same wedge condition noted in http://markmail.org/message/khini6ifoty2ecfd. Unfortunately, however, I can't use the workaround of removing the drive, aborting the scrub, and detaching one of the replacements, as it reports thus: [root@manticore ~]# zpool detach bukkit 7303939385138290847 cannot detach 7303939385138290847: no valid replicas [root@manticore ~]# zpool detach bukkit da14 cannot detach da14: no valid replicas da14 is offline (physically not attached), and has been for several reboots. Thoughts? - Rich -- Os amigos s?o a forma de Deus cuidar de n?s. From pjd at FreeBSD.org Tue Sep 29 07:18:32 2009 From: pjd at FreeBSD.org (pjd@FreeBSD.org) Date: Tue Sep 29 07:18:38 2009 Subject: kern/122888: [zfs] zfs hang w/ prefetch on, zil off while running transmission-daemon Message-ID: <200909290718.n8T7IWxO019856@freefall.freebsd.org> Synopsis: [zfs] zfs hang w/ prefetch on, zil off while running transmission-daemon State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: pon 28 wrz 2009 18:02:24 UTC State-Changed-Why: How much RAM do you systems have? PS. zfs:lo comes from zfs:lowmem, it means that process is stuck in ZFS trying to free memory, but if it is stuck for good, it means that ZFS cannot reclaim any memory. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 28 wrz 2009 18:02:24 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=122888 From bra at fsn.hu Tue Sep 29 11:04:39 2009 From: bra at fsn.hu (Attila Nagy) Date: Tue Sep 29 11:04:46 2009 Subject: ARC size constantly shrinks, then ZFS slows down extremely Message-ID: <4AC1E540.9070001@fsn.hu> Hello, I'm using FreeBSD 8 (previously 7) on a machine with a lot of disks and 32 GB RAM. With 7.x it ran very well for about 50 days, but suddenly every operation have slowed down. gstat showed that the disks are working a lot more than usual the zpool/zfs was pretty unusable. I've rebooted the machine then with FreeBSD 8 in the hope the new ZFS fixes will correct this issue (no 50 days have passed since then, so I don't know yet) and started to monitor ZFS's statistics. It seems that after a reboot, the ARC size starts to grow, then something flips the switch and it changes to shrinking, instead of maintaining the size. Please see the pictures here: http://people.fsn.hu/~bra/freebsd/20090929-zfs-arcsize/ Before the 27th, the machine ran FreeBSD 7, after that date it runs 8. As you can see, no user process tooks the memory, so I don't know why the ARC size grows first and then start to decrease. Could it be that the ARC size decreases such a big amount that it effectively disappears and this causes the IO activity go up and kill the machine? Thanks, From snnn119 at gmail.com Tue Sep 29 15:41:16 2009 From: snnn119 at gmail.com (snnn) Date: Tue Sep 29 15:41:49 2009 Subject: kern/128633: [zfs] [lor] lock order reversal in zfs In-Reply-To: <200909281759.n8SHxvBW090508@freefall.freebsd.org> References: <200909281759.n8SHxvBW090508@freefall.freebsd.org> Message-ID: <4AC224B7.3000201@gmail.com> pjd@FreeBSD.org ??: > Synopsis: [zfs] [lor] lock order reversal in zfs > > State-Changed-From-To: open->feedback > State-Changed-By: pjd > State-Changed-When: pon 28 wrz 2009 17:58:06 UTC > State-Changed-Why: > Can you show how how lines around line 1123 in > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c looks like > on the source your kernel was compiled from? Same for sys/kern/vfs_subr.c:372. > > I'm sorry.It is too far from this pr was sent. The kernel which I were used is 8.0-CURRENT-200810,it isn't compiled by myself but downloaded at ftp.freebsd.org From rincebrain at gmail.com Wed Sep 30 02:01:34 2009 From: rincebrain at gmail.com (Rich) Date: Wed Sep 30 02:01:41 2009 Subject: zpool replace 'stuck' In-Reply-To: <5da0588e0909281120p301bf75fi1bfda50c1a0a7ef0@mail.gmail.com> References: <5da0588e0909281120p301bf75fi1bfda50c1a0a7ef0@mail.gmail.com> Message-ID: <5da0588e0909291901o328f9b13x3eb61a93b98ddc37@mail.gmail.com> Oh, what a horrid fix! We modified src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:~3577 from: VERIFY(spa_scrub(spa, POOL_SCRUB_RESILVER) == 0); to: spa_scrub(spa, POOL_SCRUB_RESILVER); and ~3469: if (type == POOL_SCRUB_EVERYTHING && to: if ((type == POOL_SCRUB_EVERYTHING || type == POOL_SCRUB_RESILVER) && This allowed the scrub to finish sanely. Why is it sane to allow it to abort and start a new resilver when in mid-resilver? - Rich On Mon, Sep 28, 2009 at 2:20 PM, Rich wrote: > Hello, world. > > On 8.0-RC1 amd64, I seem to have run into the same wedge condition > noted in http://markmail.org/message/khini6ifoty2ecfd. > > Unfortunately, however, I can't use the workaround of removing the > drive, aborting the scrub, and detaching one of the replacements, as > it reports thus: > [root@manticore ~]# zpool detach bukkit 7303939385138290847 > cannot detach 7303939385138290847: no valid replicas > [root@manticore ~]# zpool detach bukkit da14 > cannot detach da14: no valid replicas > > da14 is offline (physically not attached), and has been for several reboots. > > Thoughts? > > - Rich > > -- > > Os amigos s?o a forma de Deus cuidar de n?s. > -- As senadoras? Sim! Missa, roda nessa! -- pal?ndromo From linimon at FreeBSD.org Wed Sep 30 16:12:50 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 30 16:12:57 2009 Subject: kern/139198: [nfs] Page Fault out of NLM Message-ID: <200909301612.n8UGCocI035810@freefall.freebsd.org> Old Synopsis: Page Fault out of NLM New Synopsis: [nfs] Page Fault out of NLM Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 30 16:12:16 UTC 2009 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=139198