From owner-freebsd-fs@freebsd.org Sun May 21 12:15:08 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AA20D6B1D4; Sun, 21 May 2017 12:15:08 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D9620398; Sun, 21 May 2017 12:15:07 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id 0FFC879; Sun, 21 May 2017 14:14:57 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id EF00E28497; Sun, 21 May 2017 14:14:56 +0200 (CEST) Date: Sun, 21 May 2017 14:14:56 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170521121456.GA21613@stack.nl> References: <20170420194314.GI1788@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170420194314.GI1788@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 12:15:08 -0000 On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > Inodes are data structures corresponding to objects in a file system, > such as files and directories. FreeBSD has historically used 32-bit > values to identify inodes, which limits file systems to somewhat under > 2^32 objects. Many modern file systems internally use 64-bit identifiers > and FreeBSD needs to follow suit to properly and fully support these > file systems. > The 64-bit inode project, also known as ino64, started life many years > ago as a project by Gleb Kurtsou (gleb@). After that time several > people have had a hand in updating it and addressing regressions, after > mckusick@ picked up and updated the patch, and acted as a flag-waver. > Sponsored by the FreeBSD Foundation I have spent a significant effort > on outstanding issues and integration -- fixing compat32 ABI, NFS and > ZFS, addressing ABI compat issues and investigating and fixing ports > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > jhb@ provided feedback and review on the ABI transition support. pho@ > performed extensive testing and identified a number of issues that > have now been fixed. kris@ performed an initial ports investigation > followed by an exp-run by antoine@. emaste@ helped with organization > of the process. > This note explains how to perform useful testing of the ino64 branch, > beyond typical smoke tests. > 1. Overview. > The ino64 branch extends the basic system types ino_t and dev_t from > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > layout is modified due to the larger size of ino_t, and also gains a > d_off (directory offset) member. As ino64 implies an ABI change anyway > the struct statfs f_mntfromname[] and f_mntonname[] array length > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > names. > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and by > employing other tricks. Unfortunately, not everything can be fixed, > especially outside the base system. For instance, third-party APIs > which pass struct stat around are broken in backward and forward- > incompatible way. We have another type in this area which is too small in some situations: uint8_t for struct dirent.d_namlen. For filesystems that store filenames as upto 255 UTF-16 code units, the name to be stored in d_name may be upto 765 bytes long in UTF-8. This was reported in PR 204643. The code currently handles this by returning the short (8.3) name, but this name may not be present or usable, leaving the file inaccessible. Actually allowing longer names seems too complicated to add to the ino64 change, but changing d_namlen to uint16_t (using d_pad0 space) and skipping entries with d_namlen > 255 in libc may be helpful. Note that applications using the deprecated readdir_r() will not be able to read such long names, since the API does not allow specifying that a larger buffer has been provided. (This could be avoided by making struct dirent.d_name 766 bytes long instead of 256.) Unfortunately, the existence of readdir_r() also prevents changing struct dirent.d_name to the more correct flexible array. -- Jilles Tjoelker From owner-freebsd-fs@freebsd.org Sun May 21 12:31:26 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3A6DD6BEBB; Sun, 21 May 2017 12:31:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80A761149; Sun, 21 May 2017 12:31:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4LCVIeJ019814 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 May 2017 15:31:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4LCVIeJ019814 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4LCVINU019813; Sun, 21 May 2017 15:31:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 May 2017 15:31:18 +0300 From: Konstantin Belousov To: Jilles Tjoelker Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170521123118.GH1622@kib.kiev.ua> References: <20170420194314.GI1788@kib.kiev.ua> <20170521121456.GA21613@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170521121456.GA21613@stack.nl> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 12:31:26 -0000 On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > We have another type in this area which is too small in some situations: > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > as upto 255 UTF-16 code units, the name to be stored in d_name may be > upto 765 bytes long in UTF-8. This was reported in PR 204643. The code > currently handles this by returning the short (8.3) name, but this name > may not be present or usable, leaving the file inaccessible. > > Actually allowing longer names seems too complicated to add to the ino64 > change, but changing d_namlen to uint16_t (using d_pad0 space) and > skipping entries with d_namlen > 255 in libc may be helpful. > > Note that applications using the deprecated readdir_r() will not be able > to read such long names, since the API does not allow specifying that a > larger buffer has been provided. (This could be avoided by making struct > dirent.d_name 766 bytes long instead of 256.) > > Unfortunately, the existence of readdir_r() also prevents changing > struct dirent.d_name to the more correct flexible array. Yes, changing the size of d_name at this stage of the project is out of question. My reading of your proposal is that we should extend the size of d_namlen to uint16_t, am I right ? Should we go to 32bit directly then, perhaps ? I did not committed the change below, nor did I tested or even build it. diff --git a/lib/libc/gen/readdir-compat11.c b/lib/libc/gen/readdir-compat11.c index 1c52f563c75..18d85adaa63 100644 --- a/lib/libc/gen/readdir-compat11.c +++ b/lib/libc/gen/readdir-compat11.c @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); #define _WANT_FREEBSD11_DIRENT #include #include +#include #include #include #include @@ -53,10 +54,12 @@ __FBSDID("$FreeBSD$"); #include "gen-compat.h" -static void +static bool freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct dirent *srcdp) { + if (srcdp->d_namelen >= sizeof(dstdp->d_name)) + return (false); dstdp->d_type = srcdp->d_type; dstdp->d_namlen = srcdp->d_namlen; dstdp->d_fileno = srcdp->d_fileno; /* truncate */ @@ -65,6 +68,7 @@ freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct dirent *srcdp) bzero(dstdp->d_name + dstdp->d_namlen, dstdp->d_reclen - offsetof(struct freebsd11_dirent, d_name) - dstdp->d_namlen); + return (true); } struct freebsd11_dirent * @@ -80,8 +84,10 @@ freebsd11_readdir(DIR *dirp) if (dirp->dd_compat_de == NULL) dirp->dd_compat_de = malloc(sizeof(struct freebsd11_dirent)); - freebsd11_cvtdirent(dirp->dd_compat_de, dp); - dstdp = dirp->dd_compat_de; + if (freebsd11_cvtdirent(dirp->dd_compat_de, dp)) + dstdp = dirp->dd_compat_de; + else + dstdp = NULL; } else dstdp = NULL; if (__isthreaded) @@ -101,8 +107,10 @@ freebsd11_readdir_r(DIR *dirp, struct freebsd11_dirent *entry, if (error != 0) return (error); if (xresult != NULL) { - freebsd11_cvtdirent(entry, &xentry); - *result = entry; + if (freebsd11_cvtdirent(entry, &xentry)) + *result = entry; + else + *result = NULL; } else *result = NULL; return (0); diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 784af836aee..27b2635030d 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -3733,7 +3733,8 @@ freebsd11_kern_getdirentries(struct thread *td, int fd, char *ubuf, u_int count, if (dp->d_reclen == 0) break; MPASS(dp->d_reclen >= _GENERIC_DIRLEN(0)); - /* dp->d_namlen <= sizeof(dstdp.d_name) - 1 always */ + if (dp->d_namlen >= sizeof(dstdp.d_name)) + continue; dstdp.d_type = dp->d_type; dstdp.d_namlen = dp->d_namlen; dstdp.d_fileno = dp->d_fileno; /* truncate */ diff --git a/sys/sys/dirent.h b/sys/sys/dirent.h index 341855d0530..691c4e8f90f 100644 --- a/sys/sys/dirent.h +++ b/sys/sys/dirent.h @@ -67,8 +67,9 @@ struct dirent { off_t d_off; /* directory offset of entry */ __uint16_t d_reclen; /* length of this record */ __uint8_t d_type; /* file type, see below */ - __uint8_t d_namlen; /* length of string in d_name */ - __uint32_t d_pad0; + __uint8_t d_pad0 + __uint16_t d_namlen; /* length of string in d_name */ + __uint16_t d_pad1; #if __BSD_VISIBLE #define MAXNAMLEN 255 char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */ From owner-freebsd-fs@freebsd.org Sun May 21 14:03:57 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 116DAD775DC; Sun, 21 May 2017 14:03:57 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D39F71A06; Sun, 21 May 2017 14:03:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id 658F979; Sun, 21 May 2017 16:03:55 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 4E80C28497; Sun, 21 May 2017 16:03:55 +0200 (CEST) Date: Sun, 21 May 2017 16:03:55 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170521140355.GC21613@stack.nl> References: <20170420194314.GI1788@kib.kiev.ua> <20170521121456.GA21613@stack.nl> <20170521123118.GH1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170521123118.GH1622@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 14:03:57 -0000 On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > > We have another type in this area which is too small in some situations: > > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > > as upto 255 UTF-16 code units, the name to be stored in d_name may be > > upto 765 bytes long in UTF-8. This was reported in PR 204643. The code > > currently handles this by returning the short (8.3) name, but this name > > may not be present or usable, leaving the file inaccessible. > > Actually allowing longer names seems too complicated to add to the ino64 > > change, but changing d_namlen to uint16_t (using d_pad0 space) and > > skipping entries with d_namlen > 255 in libc may be helpful. > > Note that applications using the deprecated readdir_r() will not be able > > to read such long names, since the API does not allow specifying that a > > larger buffer has been provided. (This could be avoided by making struct > > dirent.d_name 766 bytes long instead of 256.) > > Unfortunately, the existence of readdir_r() also prevents changing > > struct dirent.d_name to the more correct flexible array. > Yes, changing the size of d_name at this stage of the project is out of > question. My reading of your proposal is that we should extend the size > of d_namlen to uint16_t, am I right ? Should we go to 32bit directly > then, perhaps ? Yes, my proposal is to change d_namlen to uint16_t. Making it 32 bits is not useful with the 16-bit d_reclen, and increasing d_reclen does not seem useful to me with the current model of getdirentries() where the whole dirent must fit into the caller's buffer. > I did not committed the change below, nor did I tested or even build it. I'd like to skip overlong names in the native readdir_r() as well, so that long name support can be added to the kernel later without causing buffer overflows with applications using FreeBSD 12.0 libc. The native readdir() does not seem to have such a problem. > [patch snipped] -- Jilles Tjoelker From owner-freebsd-fs@freebsd.org Sun May 21 14:25:42 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DA06D77BB2; Sun, 21 May 2017 14:25:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B02F6841; Sun, 21 May 2017 14:25:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4LEPZCw044648 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 May 2017 17:25:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4LEPZCw044648 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4LEPZbb044646; Sun, 21 May 2017 17:25:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 May 2017 17:25:35 +0300 From: Konstantin Belousov To: Jilles Tjoelker Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170521142535.GI1622@kib.kiev.ua> References: <20170420194314.GI1788@kib.kiev.ua> <20170521121456.GA21613@stack.nl> <20170521123118.GH1622@kib.kiev.ua> <20170521140355.GC21613@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170521140355.GC21613@stack.nl> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 14:25:42 -0000 On Sun, May 21, 2017 at 04:03:55PM +0200, Jilles Tjoelker wrote: > On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: > > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > > > We have another type in this area which is too small in some situations: > > > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > > > as upto 255 UTF-16 code units, the name to be stored in d_name may be > > > upto 765 bytes long in UTF-8. This was reported in PR 204643. The code > > > currently handles this by returning the short (8.3) name, but this name > > > may not be present or usable, leaving the file inaccessible. > > > > Actually allowing longer names seems too complicated to add to the ino64 > > > change, but changing d_namlen to uint16_t (using d_pad0 space) and > > > skipping entries with d_namlen > 255 in libc may be helpful. > > > > Note that applications using the deprecated readdir_r() will not be able > > > to read such long names, since the API does not allow specifying that a > > > larger buffer has been provided. (This could be avoided by making struct > > > dirent.d_name 766 bytes long instead of 256.) > > > > Unfortunately, the existence of readdir_r() also prevents changing > > > struct dirent.d_name to the more correct flexible array. > > > Yes, changing the size of d_name at this stage of the project is out of > > question. My reading of your proposal is that we should extend the size > > of d_namlen to uint16_t, am I right ? Should we go to 32bit directly > > then, perhaps ? > > Yes, my proposal is to change d_namlen to uint16_t. > > Making it 32 bits is not useful with the 16-bit d_reclen, and increasing > d_reclen does not seem useful to me with the current model of > getdirentries() where the whole dirent must fit into the caller's > buffer. Bumping it now might cause less churn later, even if unused, but ok. > > > I did not committed the change below, nor did I tested or even build it. > > I'd like to skip overlong names in the native readdir_r() as well, so > that long name support can be added to the kernel later without causing > buffer overflows with applications using FreeBSD 12.0 libc. > > The native readdir() does not seem to have such a problem. Again, not even compiled. diff --git a/lib/libc/gen/readdir-compat11.c b/lib/libc/gen/readdir-compat11.c index 1c52f563c75..a865ab9157e 100644 --- a/lib/libc/gen/readdir-compat11.c +++ b/lib/libc/gen/readdir-compat11.c @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); #define _WANT_FREEBSD11_DIRENT #include #include +#include #include #include #include @@ -53,10 +54,12 @@ __FBSDID("$FreeBSD$"); #include "gen-compat.h" -static void +static bool freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct dirent *srcdp) { + if (srcdp->d_namelen >= sizeof(dstdp->d_name)) + return (false); dstdp->d_type = srcdp->d_type; dstdp->d_namlen = srcdp->d_namlen; dstdp->d_fileno = srcdp->d_fileno; /* truncate */ @@ -65,6 +68,7 @@ freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct dirent *srcdp) bzero(dstdp->d_name + dstdp->d_namlen, dstdp->d_reclen - offsetof(struct freebsd11_dirent, d_name) - dstdp->d_namlen); + return (true); } struct freebsd11_dirent * @@ -75,13 +79,15 @@ freebsd11_readdir(DIR *dirp) if (__isthreaded) _pthread_mutex_lock(&dirp->dd_lock); - dp = _readdir_unlocked(dirp, 1); + dp = _readdir_unlocked(dirp, RDU_SKIP); if (dp != NULL) { if (dirp->dd_compat_de == NULL) dirp->dd_compat_de = malloc(sizeof(struct freebsd11_dirent)); - freebsd11_cvtdirent(dirp->dd_compat_de, dp); - dstdp = dirp->dd_compat_de; + if (freebsd11_cvtdirent(dirp->dd_compat_de, dp)) + dstdp = dirp->dd_compat_de; + else + dstdp = NULL; } else dstdp = NULL; if (__isthreaded) @@ -101,8 +107,10 @@ freebsd11_readdir_r(DIR *dirp, struct freebsd11_dirent *entry, if (error != 0) return (error); if (xresult != NULL) { - freebsd11_cvtdirent(entry, &xentry); - *result = entry; + if (freebsd11_cvtdirent(entry, &xentry)) + *result = entry; + else /* should not happen due to RDU_SHORT */ + *result = NULL; } else *result = NULL; return (0); diff --git a/lib/libc/gen/readdir.c b/lib/libc/gen/readdir.c index dc7b0df18b2..c30d48273b8 100644 --- a/lib/libc/gen/readdir.c +++ b/lib/libc/gen/readdir.c @@ -49,7 +49,7 @@ __FBSDID("$FreeBSD$"); * get next entry in a directory. */ struct dirent * -_readdir_unlocked(DIR *dirp, int skip) +_readdir_unlocked(DIR *dirp, int flags) { struct dirent *dp; long initial_seek; @@ -80,10 +80,13 @@ _readdir_unlocked(DIR *dirp, int skip) dp->d_reclen > dirp->dd_len + 1 - dirp->dd_loc) return (NULL); dirp->dd_loc += dp->d_reclen; - if (dp->d_ino == 0 && skip) + if (dp->d_ino == 0 && (flags & RDU_SKIP) != 0) continue; if (dp->d_type == DT_WHT && (dirp->dd_flags & DTF_HIDEW)) continue; + if (dp->d_namlen >= sizeof(d_namlen) && + (flags & RDU_SHORT) != 0) + continue; return (dp); } } @@ -91,15 +94,13 @@ _readdir_unlocked(DIR *dirp, int skip) struct dirent * readdir(DIR *dirp) { - struct dirent *dp; + struct dirent *dp; - if (__isthreaded) { + if (__isthreaded) _pthread_mutex_lock(&dirp->dd_lock); - dp = _readdir_unlocked(dirp, 1); + dp = _readdir_unlocked(dirp, RDU_SKIP); + if (__isthreaded) _pthread_mutex_unlock(&dirp->dd_lock); - } - else - dp = _readdir_unlocked(dirp, 1); return (dp); } @@ -111,14 +112,13 @@ __readdir_r(DIR *dirp, struct dirent *entry, struct dirent **result) saved_errno = errno; errno = 0; - if (__isthreaded) { + if (__isthreaded) _pthread_mutex_lock(&dirp->dd_lock); - if ((dp = _readdir_unlocked(dirp, 1)) != NULL) - memcpy(entry, dp, _GENERIC_DIRSIZ(dp)); - _pthread_mutex_unlock(&dirp->dd_lock); - } - else if ((dp = _readdir_unlocked(dirp, 1)) != NULL) + dp = _readdir_unlocked(dirp, RDU_SKIP | RDU_SHORT); + if (dp != NULL) memcpy(entry, dp, _GENERIC_DIRSIZ(dp)); + if (__isthreaded) + _pthread_mutex_unlock(&dirp->dd_lock); if (errno != 0) { if (dp == NULL) diff --git a/lib/libc/gen/telldir.h b/lib/libc/gen/telldir.h index 96ff669a312..50adb351e91 100644 --- a/lib/libc/gen/telldir.h +++ b/lib/libc/gen/telldir.h @@ -66,4 +66,7 @@ void _reclaim_telldir(DIR *); void _seekdir(DIR *, long); void _fixtelldir(DIR *dirp, long oldseek, long oldloc); +#define RDU_SKIP 0x0001 +#define RDU_SHORT 0x0002 + #endif diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 784af836aee..27b2635030d 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -3733,7 +3733,8 @@ freebsd11_kern_getdirentries(struct thread *td, int fd, char *ubuf, u_int count, if (dp->d_reclen == 0) break; MPASS(dp->d_reclen >= _GENERIC_DIRLEN(0)); - /* dp->d_namlen <= sizeof(dstdp.d_name) - 1 always */ + if (dp->d_namlen >= sizeof(dstdp.d_name)) + continue; dstdp.d_type = dp->d_type; dstdp.d_namlen = dp->d_namlen; dstdp.d_fileno = dp->d_fileno; /* truncate */ diff --git a/sys/sys/dirent.h b/sys/sys/dirent.h index 341855d0530..472142f960b 100644 --- a/sys/sys/dirent.h +++ b/sys/sys/dirent.h @@ -58,8 +58,7 @@ typedef __off_t off_t; * * Explicit padding between the last member of the header (d_namelen) and * d_name avoids ABI padding at the end of dirent on LP64 architectures. - * There is code depending on d_name being last. Also, retaining this - * padding on ILP32 architectures simplifies the compat32 layer. + * There is code depending on d_name being last. */ struct dirent { @@ -67,8 +66,9 @@ struct dirent { off_t d_off; /* directory offset of entry */ __uint16_t d_reclen; /* length of this record */ __uint8_t d_type; /* file type, see below */ - __uint8_t d_namlen; /* length of string in d_name */ - __uint32_t d_pad0; + __uint8_t d_pad0; + __uint16_t d_namlen; /* length of string in d_name */ + __uint16_t d_pad1; #if __BSD_VISIBLE #define MAXNAMLEN 255 char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */ From owner-freebsd-fs@freebsd.org Sun May 21 21:00:58 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0751D77085 for ; Sun, 21 May 2017 21:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C669D82E for ; Sun, 21 May 2017 21:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4LL01ZG015108 for ; Sun, 21 May 2017 21:00:58 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201705212100.v4LL01ZG015108@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 21 May 2017 21:00:58 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 21:00:58 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic New | 217062 | for file systems mounted with -o noexec, exec=off Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 6 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun May 21 21:27:29 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82057D77C53; Sun, 21 May 2017 21:27:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F1E2171E; Sun, 21 May 2017 21:27:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id 095A279; Sun, 21 May 2017 23:27:27 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E68E928497; Sun, 21 May 2017 23:27:26 +0200 (CEST) Date: Sun, 21 May 2017 23:27:26 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170521212726.GA23821@stack.nl> References: <20170420194314.GI1788@kib.kiev.ua> <20170521121456.GA21613@stack.nl> <20170521123118.GH1622@kib.kiev.ua> <20170521140355.GC21613@stack.nl> <20170521142535.GI1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170521142535.GI1622@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 21:27:29 -0000 On Sun, May 21, 2017 at 05:25:35PM +0300, Konstantin Belousov wrote: > On Sun, May 21, 2017 at 04:03:55PM +0200, Jilles Tjoelker wrote: > > On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: > > > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > > > > We have another type in this area which is too small in some situations: > > > > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > > > > as upto 255 UTF-16 code units, the name to be stored in d_name may be > > > > upto 765 bytes long in UTF-8. This was reported in PR 204643. The code > > > > currently handles this by returning the short (8.3) name, but this name > > > > may not be present or usable, leaving the file inaccessible. > > > > Actually allowing longer names seems too complicated to add to the ino64 > > > > change, but changing d_namlen to uint16_t (using d_pad0 space) and > > > > skipping entries with d_namlen > 255 in libc may be helpful. > > > > Note that applications using the deprecated readdir_r() will not be able > > > > to read such long names, since the API does not allow specifying that a > > > > larger buffer has been provided. (This could be avoided by making struct > > > > dirent.d_name 766 bytes long instead of 256.) > > > > Unfortunately, the existence of readdir_r() also prevents changing > > > > struct dirent.d_name to the more correct flexible array. > > > Yes, changing the size of d_name at this stage of the project is out of > > > question. My reading of your proposal is that we should extend the size > > > of d_namlen to uint16_t, am I right ? Should we go to 32bit directly > > > then, perhaps ? > > Yes, my proposal is to change d_namlen to uint16_t. > > Making it 32 bits is not useful with the 16-bit d_reclen, and increasing > > d_reclen does not seem useful to me with the current model of > > getdirentries() where the whole dirent must fit into the caller's > > buffer. > Bumping it now might cause less churn later, even if unused, but ok. > > > I did not committed the change below, nor did I tested or even build it. > > I'd like to skip overlong names in the native readdir_r() as well, so > > that long name support can be added to the kernel later without causing > > buffer overflows with applications using FreeBSD 12.0 libc. > > The native readdir() does not seem to have such a problem. > Again, not even compiled. Looks good to me. > [patch snipped] -- Jilles Tjoelker From owner-freebsd-fs@freebsd.org Mon May 22 03:31:32 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63739D77DFE for ; Mon, 22 May 2017 03:31:32 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47E731023 for ; Mon, 22 May 2017 03:31:31 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id v4M3X43q007873; Sun, 21 May 2017 20:33:04 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201705220333.v4M3X43q007873@chez.mckusick.com> From: Kirk McKusick To: Konstantin Belousov Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing cc: Jilles Tjoelker , freebsd-fs@freebsd.org In-reply-to: <20170521142535.GI1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7871.1495423984.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Sun, 21 May 2017 20:33:04 -0700 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 03:31:32 -0000 I think that kib's proposed change is a sensible thing to do and it does make sense to do it in the context of this change. I regret that it is coming so late in the testing phase of this commit and that is my only reluctancy in making it. If Peter Holm (pho@) can at least run his test suite with this change and if it does not turn up any problems, then I would be inclined to make kib's proposed change. But I fully understand not wanting to risk screwing up this patch with this last minute change. Kirk McKusick =3D-=3D-=3D Date: Sun, 21 May 2017 17:25:35 +0300 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing On Sun, May 21, 2017 at 04:03:55PM +0200, Jilles Tjoelker wrote: > On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: >> On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: >>> We have another type in this area which is too small in some situation= s: >>> uint8_t for struct dirent.d_namlen. For filesystems that store filenam= es >>> as upto 255 UTF-16 code units, the name to be stored in d_name may be >>> upto 765 bytes long in UTF-8. This was reported in PR 204643. The code >>> currently handles this by returning the short (8.3) name, but this nam= e >>> may not be present or usable, leaving the file inaccessible. > = >>> Actually allowing longer names seems too complicated to add to the ino= 64 >>> change, but changing d_namlen to uint16_t (using d_pad0 space) and >>> skipping entries with d_namlen > 255 in libc may be helpful. > = >>> Note that applications using the deprecated readdir_r() will not be ab= le >>> to read such long names, since the API does not allow specifying that = a >>> larger buffer has been provided. (This could be avoided by making stru= ct >>> dirent.d_name 766 bytes long instead of 256.) > = >>> Unfortunately, the existence of readdir_r() also prevents changing >>> struct dirent.d_name to the more correct flexible array. > = >> Yes, changing the size of d_name at this stage of the project is out of >> question. My reading of your proposal is that we should extend the size >> of d_namlen to uint16_t, am I right ? Should we go to 32bit directly >> then, perhaps ? > = > Yes, my proposal is to change d_namlen to uint16_t. > = > Making it 32 bits is not useful with the 16-bit d_reclen, and increasing > d_reclen does not seem useful to me with the current model of > getdirentries() where the whole dirent must fit into the caller's > buffer. Bumping it now might cause less churn later, even if unused, but ok. > = >> I did not committed the change below, nor did I tested or even build it= . > = > I'd like to skip overlong names in the native readdir_r() as well, so > that long name support can be added to the kernel later without causing > buffer overflows with applications using FreeBSD 12.0 libc. > = > The native readdir() does not seem to have such a problem. Again, not even compiled. diff --git a/lib/libc/gen/readdir-compat11.c b/lib/libc/gen/readdir-compat= 11.c index 1c52f563c75..a865ab9157e 100644 --- a/lib/libc/gen/readdir-compat11.c +++ b/lib/libc/gen/readdir-compat11.c @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); #define _WANT_FREEBSD11_DIRENT #include #include +#include #include #include #include @@ -53,10 +54,12 @@ __FBSDID("$FreeBSD$"); #include "gen-compat.h" -static void +static bool freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, struct dirent *srcdp) { + if (srcdp->d_namelen >=3D sizeof(dstdp->d_name)) + return (false); dstdp->d_type =3D srcdp->d_type; dstdp->d_namlen =3D srcdp->d_namlen; dstdp->d_fileno =3D srcdp->d_fileno; /* truncate */ @@ -65,6 +68,7 @@ freebsd11_cvtdirent(struct freebsd11_dirent *dstdp, stru= ct dirent *srcdp) bzero(dstdp->d_name + dstdp->d_namlen, dstdp->d_reclen - offsetof(struct freebsd11_dirent, d_name) - dstdp->d_namlen); + return (true); } struct freebsd11_dirent * @@ -75,13 +79,15 @@ freebsd11_readdir(DIR *dirp) if (__isthreaded) _pthread_mutex_lock(&dirp->dd_lock); - dp =3D _readdir_unlocked(dirp, 1); + dp =3D _readdir_unlocked(dirp, RDU_SKIP); if (dp !=3D NULL) { if (dirp->dd_compat_de =3D=3D NULL) dirp->dd_compat_de =3D malloc(sizeof(struct freebsd11_dirent)); - freebsd11_cvtdirent(dirp->dd_compat_de, dp); - dstdp =3D dirp->dd_compat_de; + if (freebsd11_cvtdirent(dirp->dd_compat_de, dp)) + dstdp =3D dirp->dd_compat_de; + else + dstdp =3D NULL; } else dstdp =3D NULL; if (__isthreaded) @@ -101,8 +107,10 @@ freebsd11_readdir_r(DIR *dirp, struct freebsd11_diren= t *entry, if (error !=3D 0) return (error); if (xresult !=3D NULL) { - freebsd11_cvtdirent(entry, &xentry); - *result =3D entry; + if (freebsd11_cvtdirent(entry, &xentry)) + *result =3D entry; + else /* should not happen due to RDU_SHORT */ + *result =3D NULL; } else *result =3D NULL; return (0); diff --git a/lib/libc/gen/readdir.c b/lib/libc/gen/readdir.c index dc7b0df18b2..c30d48273b8 100644 --- a/lib/libc/gen/readdir.c +++ b/lib/libc/gen/readdir.c @@ -49,7 +49,7 @@ __FBSDID("$FreeBSD$"); * get next entry in a directory. */ struct dirent * -_readdir_unlocked(DIR *dirp, int skip) +_readdir_unlocked(DIR *dirp, int flags) { struct dirent *dp; long initial_seek; @@ -80,10 +80,13 @@ _readdir_unlocked(DIR *dirp, int skip) dp->d_reclen > dirp->dd_len + 1 - dirp->dd_loc) return (NULL); dirp->dd_loc +=3D dp->d_reclen; - if (dp->d_ino =3D=3D 0 && skip) + if (dp->d_ino =3D=3D 0 && (flags & RDU_SKIP) !=3D 0) continue; if (dp->d_type =3D=3D DT_WHT && (dirp->dd_flags & DTF_HIDEW)) continue; + if (dp->d_namlen >=3D sizeof(d_namlen) && + (flags & RDU_SHORT) !=3D 0) + continue; return (dp); } } @@ -91,15 +94,13 @@ _readdir_unlocked(DIR *dirp, int skip) struct dirent * readdir(DIR *dirp) { - struct dirent *dp; + struct dirent *dp; - if (__isthreaded) { + if (__isthreaded) _pthread_mutex_lock(&dirp->dd_lock); - dp =3D _readdir_unlocked(dirp, 1); + dp =3D _readdir_unlocked(dirp, RDU_SKIP); + if (__isthreaded) _pthread_mutex_unlock(&dirp->dd_lock); - } - else - dp =3D _readdir_unlocked(dirp, 1); return (dp); } @@ -111,14 +112,13 @@ __readdir_r(DIR *dirp, struct dirent *entry, struct = dirent **result) saved_errno =3D errno; errno =3D 0; - if (__isthreaded) { + if (__isthreaded) _pthread_mutex_lock(&dirp->dd_lock); - if ((dp =3D _readdir_unlocked(dirp, 1)) !=3D NULL) - memcpy(entry, dp, _GENERIC_DIRSIZ(dp)); - _pthread_mutex_unlock(&dirp->dd_lock); - } - else if ((dp =3D _readdir_unlocked(dirp, 1)) !=3D NULL) + dp =3D _readdir_unlocked(dirp, RDU_SKIP | RDU_SHORT); + if (dp !=3D NULL) memcpy(entry, dp, _GENERIC_DIRSIZ(dp)); + if (__isthreaded) + _pthread_mutex_unlock(&dirp->dd_lock); if (errno !=3D 0) { if (dp =3D=3D NULL) diff --git a/lib/libc/gen/telldir.h b/lib/libc/gen/telldir.h index 96ff669a312..50adb351e91 100644 --- a/lib/libc/gen/telldir.h +++ b/lib/libc/gen/telldir.h @@ -66,4 +66,7 @@ void _reclaim_telldir(DIR *); void _seekdir(DIR *, long); void _fixtelldir(DIR *dirp, long oldseek, long oldloc); +#define RDU_SKIP 0x0001 +#define RDU_SHORT 0x0002 + #endif diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 784af836aee..27b2635030d 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -3733,7 +3733,8 @@ freebsd11_kern_getdirentries(struct thread *td, int = fd, char *ubuf, u_int count, if (dp->d_reclen =3D=3D 0) break; MPASS(dp->d_reclen >=3D _GENERIC_DIRLEN(0)); - /* dp->d_namlen <=3D sizeof(dstdp.d_name) - 1 always */ + if (dp->d_namlen >=3D sizeof(dstdp.d_name)) + continue; dstdp.d_type =3D dp->d_type; dstdp.d_namlen =3D dp->d_namlen; dstdp.d_fileno =3D dp->d_fileno; /* truncate */ diff --git a/sys/sys/dirent.h b/sys/sys/dirent.h index 341855d0530..472142f960b 100644 --- a/sys/sys/dirent.h +++ b/sys/sys/dirent.h @@ -58,8 +58,7 @@ typedef __off_t off_t; * * Explicit padding between the last member of the header (d_namelen) and * d_name avoids ABI padding at the end of dirent on LP64 architectures. - * There is code depending on d_name being last. Also, retaining this - * padding on ILP32 architectures simplifies the compat32 layer. + * There is code depending on d_name being last. */ struct dirent { @@ -67,8 +66,9 @@ struct dirent { off_t d_off; /* directory offset of entry */ __uint16_t d_reclen; /* length of this record */ __uint8_t d_type; /* file type, see below */ - __uint8_t d_namlen; /* length of string in d_name */ - __uint32_t d_pad0; + __uint8_t d_pad0; + __uint16_t d_namlen; /* length of string in d_name */ + __uint16_t d_pad1; #if __BSD_VISIBLE #define MAXNAMLEN 255 char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */ _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Mon May 22 10:13:34 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB7C1D7748F for ; Mon, 22 May 2017 10:13:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C4EF1012 for ; Mon, 22 May 2017 10:13:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4MADSiv004859 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 13:13:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4MADSiv004859 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4MADRWN004858; Mon, 22 May 2017 13:13:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 22 May 2017 13:13:27 +0300 From: Konstantin Belousov To: Kirk McKusick Cc: Jilles Tjoelker , freebsd-fs@freebsd.org Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170522101327.GN1622@kib.kiev.ua> References: <20170521142535.GI1622@kib.kiev.ua> <201705220333.v4M3X43q007873@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201705220333.v4M3X43q007873@chez.mckusick.com> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 10:13:35 -0000 On Sun, May 21, 2017 at 08:33:04PM -0700, Kirk McKusick wrote: > I think that kib's proposed change is a sensible thing to do and > it does make sense to do it in the context of this change. I regret > that it is coming so late in the testing phase of this commit and > that is my only reluctancy in making it. > > If Peter Holm (pho@) can at least run his test suite with this > change and if it does not turn up any problems, then I would be > inclined to make kib's proposed change. But I fully understand not > wanting to risk screwing up this patch with this last minute change. I think that the change is worth it. I asked Peter to do some minimal re-testing with the patch applied. From owner-freebsd-fs@freebsd.org Mon May 22 12:15:18 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F3C7D77F08 for ; Mon, 22 May 2017 12:15:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F07D1D24 for ; Mon, 22 May 2017 12:15:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4MCFIVs035376 for ; Mon, 22 May 2017 12:15:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219433] ZFS volume cannot be created by delegated user Date: Mon, 22 May 2017 12:15:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 12:15:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219433 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon May 22 14:23:44 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AC01D78D24 for ; Mon, 22 May 2017 14:23:44 +0000 (UTC) (envelope-from hillabby@aquamassagechiropractic.com) Received: from cornsilk.cedar.relay.mailchannels.net (cornsilk.cedar.relay.mailchannels.net [23.83.210.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0F851982 for ; Mon, 22 May 2017 14:23:43 +0000 (UTC) (envelope-from hillabby@aquamassagechiropractic.com) X-Sender-Id: asmallorange|x-authuser|hillabby@aquamassagechiropractic.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C7BD25C684E for ; Mon, 22 May 2017 13:48:22 +0000 (UTC) Received: from uscentral71.myserverhosts.com (unknown [100.96.136.211]) (Authenticated sender: asmallorange) by relay.mailchannels.net (Postfix) with ESMTPA id 4371E5C5018 for ; Mon, 22 May 2017 13:48:22 +0000 (UTC) X-Sender-Id: asmallorange|x-authuser|hillabby@aquamassagechiropractic.com Received: from uscentral71.myserverhosts.com (uscentral71.myserverhosts.com [172.20.108.37]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.3); Mon, 22 May 2017 13:48:22 +0000 X-MC-Relay: Bad X-MailChannels-SenderId: asmallorange|x-authuser|hillabby@aquamassagechiropractic.com X-MailChannels-Auth-Id: asmallorange X-Whispering-Descriptive: 1e0616fc754a783e_1495460902554_959226569 X-MC-Loop-Signature: 1495460902554:566015036 X-MC-Ingress-Time: 1495460902553 Received: from [112.196.101.46] (port=56233 helo=imark) by uscentral71.myserverhosts.com with esmtpa (Exim 4.87) (envelope-from ) id 1dCnHn-000lCP-0s for freebsd-fs@FreeBSD.org; Mon, 22 May 2017 09:22:12 -0400 From: "Abby Hill" To: Subject: Designing/Re-designing of websites Date: Mon, 22 May 2017 18:47:39 +0530 Message-ID: <10e601d2d2fe$68ebb690$3ac323b0$@aquamassagechiropractic.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdLS/VjXfYjR5GbsS1CuZZShqTC0mg== Content-Language: en-us X-AuthUser: hillabby@aquamassagechiropractic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 14:23:44 -0000 Hello Sir/ Ma'am, Greetings! Would you be interested in building your website? We are a professional web design company based in India. We are expert in the following: . Joomla Websites . Word press Websites . Magento Websites . Shopify Websites . Drupal Website . E-Commerce Solutions . Payment Gateway Integration . Custom Websites . Mobile Apps . Digital Marketing If you want to know the price/cost and examples of our website design project, please share your requirements and website URL. Warm Regards, Abby Hill Business Development Executive ******* Disclaimer: PS: If you do not wish to hear from us. Please reply with "UNSUBSCRIBE" From owner-freebsd-fs@freebsd.org Mon May 22 15:40:15 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA8D4D78600 for ; Mon, 22 May 2017 15:40:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA3951600 for ; Mon, 22 May 2017 15:40:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4MFeFLA095789 for ; Mon, 22 May 2017 15:40:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 216964] boot1.efi: can't boot from ZFS on 4kn HDD Date: Mon, 22 May 2017 15:40:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gjb@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:40:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216964 Glen Barber changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue May 23 03:57:00 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36AC7D79F56 for ; Tue, 23 May 2017 03:57:00 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBF691A1C for ; Tue, 23 May 2017 03:56:59 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-ua0-x22c.google.com with SMTP id y4so64607500uay.2 for ; Mon, 22 May 2017 20:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XNyrNGTnpVpEOq15SLV3kaUNN6oJO+bgMCHNWZanL2Y=; b=S43RmqtW1HQ5W7ZQD76zYlUL9c+BfaLB5JG7WcDEZY7OVVlGQh4ntLbOghKlkUn9mc OivL3Vj/H9ov3CQbbdOFacTJ7Y9P2PcXLQOt+nP5J54jBO5ZaJ4LuLM4BrQZ6SQdd5jg Eg3GsaTdcciGoejcV45FAY0/wux5qK9qF6yVaIaFCVHV99F1ijIy22XLxdi17y8HhTeO 5xMmA60zLrQbefdL4FuoaF8ECePzXMU2g3PAF86UOASSlLA/UgEOKMGaT93/AI8h2z4n KD2v5YRJ1vhUSOOOhrj1CmYty9uVnAzFdz2UkNnjNOYwj66IsC5KnO1WOt6br/2pydQs /dhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XNyrNGTnpVpEOq15SLV3kaUNN6oJO+bgMCHNWZanL2Y=; b=ObaFs1JM1jdYg4WC+zczQ20bV0BHQLNJI95OB97Gg7asVHPOk9EsY2ZQx4YzaprRnP i15v63v+rpdAL9/DgDBtWxMFyHS8ntKNaDdZWKkzTKdr6VrMNBGaXPJp22UeI4o5gu8v 12N3xJ0QpapbzV8QzlgmHarOmL1zMyPV+FxgUVnR6Cytt6M4CssTmDtZhkeC4MXXzIMr jw7guxRlbkuVf5dhnPWxKDvdoNZex8iGzXheSAjjAZiTwg9Uj3a8frMZ/fh/y3Z6N5tQ whnc0p5ukzwibcj778NzBdEvpf/FSUN5ZwcDg/As/BIMXBbmiCXpJJoIuVE/StrxY/2l oVgA== X-Gm-Message-State: AODbwcDvNiztNfF3aD51jATQSxTu/9zp7S9bxsT3BTIBOtqIIyRFCrQ/ 1wSi+7bQhXazATNj8nOOv3zzapcKvkRx X-Received: by 10.176.16.235 with SMTP id x43mr14253863uab.15.1495511818700; Mon, 22 May 2017 20:56:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.204.195 with HTTP; Mon, 22 May 2017 20:56:58 -0700 (PDT) From: Aijaz Baig Date: Tue, 23 May 2017 09:26:58 +0530 Message-ID: Subject: Debugging nullfs - cannot access memory at address To: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 03:57:00 -0000 I am trying to debug the nullfs kernel module so to that end, I do the following: On the target machine: kldstat gives Id Refs Address Size Name 1 10 0xffffffff80200000 17e10c8 kernel 2 1 0xffffffff819e2000 4cf0 vmxnet.ko 3 1 0xffffffff819e7000 16e0 echo.ko 4 1 0xffffffff81c11000 23dc vmmemctl.ko 5 1 0xffffffff81c14000 641b nullfs.ko nm /boot/kernel/nullfs.ko | grep mount 00000000000018f0 t null_getwritemount 0000000000000540 t nullfs_mount 0000000000000930 t nullfs_unmount U vfs_mountedfrom U vop_getwritemount_desc On the local machine (which connects to the target via a named pipe acting as a serial console (I am using virtual machines): (kgdb) tr0 kdb_sysctl_enter (oidp=, arg1=, arg2=0xfffffe004e7cc7f0, req=) at /usr/src/sys/kern/subr_kdb.c:446 446 kdb_why = KDB_WHY_UNSET; Current language: auto; currently minimal (kgdb) getsyms During symbol reading, Incomplete CFI data; unspecified registers at 0xffffffff8099497a. Id Refs Address Size Name 1 10 0x80200000 17e10c8 kernel 2 1 0x819e2000 4cf0 vmxnet.ko 3 1 0x819e7000 16e0 echo.ko 4 1 0x81c11000 23dc vmmemctl.ko 5 1 0x81c14000 641b nullfs.ko Select the list above with the mouse, paste into the screen and then press ^D. Yes, this is annoying. 5 1 0x81c14000 641b nullfs.ko add symbol table from file "/usr/obj/usr/src/sys/AIJAZ- DEBUG/modules/usr/src/sys/modules/nullfs/nullfs.ko.debug" at .text_addr = 0x81c14000 .data_addr = 0x81c14000 .bss_addr = 0x81c14000 (kgdb) add-kld nullfs.ko add symbol table from file "/boot/kernel/nullfs.ko.symbols" at .text_addr = 0xffffffff81c14000 set_sysinit_set_addr = 0xffffffff81c15c90 set_sysuninit_set_addr = 0xffffffff81c15cb0 .rodata.str1.1_addr = 0xffffffff81c15cc8 set_modmetadata_set_addr = 0xffffffff81c15e48 set_sysctl_set_addr = 0xffffffff81c15e58 .data_addr = 0xffffffff81c15e60 .bss_addr = 0xffffffff81c16360 (y or n) y Reading symbols from /boot/kernel/nullfs.ko.symbols... location expression too complex...done. (kgdb) b nullfs_mount Cannot access memory at address 0x81c14540 As one can see from the output of 'nm' and 'kldstat' above, the addresses are indeed proper. I even tried setting a "hardware breakpoint" at the above address (kgdb) hbreak *0x81c14540 Hardware assisted breakpoint 1 at 0x81c14540: file /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c, line 74. (kgdb) c Continuing. Warning: Cannot insert breakpoint 1. Error accessing memory address 0x81c14540: Input/output error. On searching for this error on Linux, it appears that this is taken care of by turning off CONFIG_DEBUG_RODATA as part of the kernel config (which as per this:http://elinux.org/Overwrite_detection_for_ kernel_text_and_read-only_data link appears to be some sort of a protection mechanism which detects when the text section of the kernel is being overwritten for some reason). This helps with the setting of software breakpoints which would otherwise be not set. Is there something similar for FreeBSD systems as well?? Keen to hear -- Best Regards, Aijaz Baig From owner-freebsd-fs@freebsd.org Wed May 24 10:09:39 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34754D7AE5D for ; Wed, 24 May 2017 10:09:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 243641594 for ; Wed, 24 May 2017 10:09:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4OA9cnw049513 for ; Wed, 24 May 2017 10:09:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Wed, 24 May 2017 10:09:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 10:09:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed May 24 14:07:10 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DA0FD7AD06 for ; Wed, 24 May 2017 14:07:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D9B412F0 for ; Wed, 24 May 2017 14:07:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4OE788Y042070 for ; Wed, 24 May 2017 14:07:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Wed, 24 May 2017 14:07:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 14:07:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 karl@denninger.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |karl@denninger.net --- Comment #7 from karl@denninger.net --- There have been a number of changes made to the ZFS code since 10.3-RELEASE; there is a version of a patch that I have been running which *should* apply against 10.3 in the following bug thread (I'm currently on 11 with the vers= ion for it in production here): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 25 03:55:37 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 656E9D812BE; Thu, 25 May 2017 03:55:37 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 007BB1272; Thu, 25 May 2017 03:55:36 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wr0-f175.google.com with SMTP id l50so65096071wrc.3; Wed, 24 May 2017 20:55:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=denZGa0E7R+2zwrbI2YNAlSG+9qZEkN29uS8oV5zyOk=; b=lBQrtZ2y5+kZ1odgef5E1VdMRBbYW5Q+La0hi4H7QN8wqs71DWgzsz2FDihe5drnHs RbSus5ZNevz6HM4hwiSyTs9GgP/3a1TTav9gAuPo+Fk5fLkOLhfbZ891qNDJaifVURQJ 7pKta3NvxtdzrIgO0LOowhV5WfJwKFVdEZBhfB3L9XKZQNLlis2h4pgp7w3Uual5g+mm rGEKrI8HL2C1tah448bQP5sQqDnR/I8PytNf1PgJLOjpLmb2aTcmdPdnAVGXN9b7NDib /H95qpK5rZ2jqpdvwv6fT3Y36J/XNZwEvshcO1wkwlNjiN2v9Kop00uAokGgz4dLx2iO vY6Q== X-Gm-Message-State: AODbwcB3eJRAULB5yt0kxWg4sefqKs3gvBl1MW+5ksTYWRF2TxKjJQNu tAlSmiuvyYV/9w== X-Received: by 10.223.174.200 with SMTP id y66mr26944855wrc.79.1495684146203; Wed, 24 May 2017 20:49:06 -0700 (PDT) Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com. [74.125.82.42]) by smtp.gmail.com with ESMTPSA id j44sm6014205wre.67.2017.05.24.20.49.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 20:49:05 -0700 (PDT) Received: by mail-wm0-f42.google.com with SMTP id d127so84454804wmf.0; Wed, 24 May 2017 20:49:05 -0700 (PDT) X-Received: by 10.80.184.129 with SMTP id l1mr26296183ede.88.1495684145147; Wed, 24 May 2017 20:49:05 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Wed, 24 May 2017 20:49:04 -0700 (PDT) In-Reply-To: <20170521121456.GA21613@stack.nl> References: <20170420194314.GI1788@kib.kiev.ua> <20170521121456.GA21613@stack.nl> From: Conrad Meyer Date: Wed, 24 May 2017 20:49:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing To: Jilles Tjoelker Cc: freebsd-current , freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 03:55:37 -0000 Hi Jilles, Thanks for bringing this up. And of course, thanks to kib@ for including the d_namlen size bump and for his work in driving the rest of this change through to completion. On Sun, May 21, 2017 at 5:14 AM, Jilles Tjoelker wrote: > We have another type in this area which is too small in some situations: > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > as upto 255 UTF-16 code units, the name to be stored in d_name may be > upto 765 bytes long in UTF-8. This was reported in PR 204643. The code > currently handles this by returning the short (8.3) name, but this name > may not be present or usable, leaving the file inaccessible. We've been working to add such support to our FreeBSD-derivative product. A big piece of it is expanding d_namlen out to 16 bits. We've also been trying to divorce system-wide constants like MAXNAMLEN / NAME_MAX and MAXPATHLEN / PATH_MAX from filesystem-specific limitations (UFS' limit of 255 bytes). And push that upstream when possible, e.g., r313475, r316509. Bumping d_namlen in FreeBSD reduces the amount of ABI breakage we have to introduce in our product relative to FreeBSD, and leaves open the possibility of supporting 255-unicode-character filesystems natively in FreeBSD down the road. > Actually allowing longer names seems too complicated to add to the ino64 > change, but changing d_namlen to uint16_t (using d_pad0 space) and > skipping entries with d_namlen > 255 in libc may be helpful. > > Note that applications using the deprecated readdir_r() will not be able > to read such long names, since the API does not allow specifying that a > larger buffer has been provided. (This could be avoided by making struct > dirent.d_name 766 bytes long instead of 256.) We're looking at 255 Unicode code points, which can be 4 bytes a piece in UTF8, or 1020 bytes potentially. > Unfortunately, the existence of readdir_r() also prevents changing > struct dirent.d_name to the more correct flexible array. Best, Conrad From owner-freebsd-fs@freebsd.org Thu May 25 09:01:05 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFAC0D811A7 for ; Thu, 25 May 2017 09:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CED9718FB for ; Thu, 25 May 2017 09:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4P914fV083817 for ; Thu, 25 May 2017 09:01:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 208882] zfs root filesystem mount failure on startup in FreeBSD 10.3-RELEASE if USB hdd with zpool is attached to another port Date: Thu, 25 May 2017 09:01:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pete@twisted.org.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 09:01:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208882 --- Comment #13 from pete@twisted.org.uk --- Is there any chance of this match making it into 11.1 which is now in prerelease ? I am running perfectly happily with this in Azure and it has f= ixed my mount issues. I understand the arguments for it not being the correct pl= ace for the fix, but in practical terms this its us reliably boot FreeBSD somew= here that it does not reliably boot without it, so theres surely at least an argument for committing it for now until a better fix can be applied ? As written is doesn't have any negative effects after all... Would like to not have to run a custom patched kernel after 11.1 comes out = if possible... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu May 25 16:37:07 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B88A8D822DE for ; Thu, 25 May 2017 16:37:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A86EB126E for ; Thu, 25 May 2017 16:37:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4PGb7ex072965 for ; Thu, 25 May 2017 16:37:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219537] OpenZFS 8166 - zpool scrub thinks it repaired offline device Date: Thu, 25 May 2017 16:37:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 16:37:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219537 g_amanakis@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Fri May 26 09:46:39 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A7C8D7B939 for ; Fri, 26 May 2017 09:46:39 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A205185B for ; Fri, 26 May 2017 09:46:38 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:2:1276::1]) by mail.freebsd.systems (Postfix) with ESMTP id 9C03ABCF for ; Fri, 26 May 2017 11:40:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([IPv6:2001:41d0:2:1276::1]) by mail.freebsd.systems (scan.freebsd.systems [IPv6:2001:41d0:2:1276::1]) (amavisd-new, port 10026) with ESMTP id nUvOEahElcF7 for ; Fri, 26 May 2017 11:40:16 +0200 (CEST) Received: from [192.168.138.100] (unknown [194.181.68.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id 45417BCC for ; Fri, 26 May 2017 11:40:16 +0200 (CEST) Authentication-Results: mail.freebsd.systems; dmarc=none header.from=wasikowski.net Authentication-Results: mail.freebsd.systems; spf=pass smtp.mailfrom=lukasz@wasikowski.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1495791616; bh=29BNoCbjlyGy0kvxq5X+LMccS16EikuPaXV8S6WXEdE=; h=To:From:Date; b=fH2Psgt5aEEwGvQNynJ+xqOGcqrs6eXe1uNkOKzxcz/WJOxDfhoZb6w6/B9n5wi2r zOebzwPXchY0E+ehao9CFIA2yjcHqZq5UuWs8gtFheQGI6evRirTXWWheVmCokp94e Ili0MuE4n3IUpR0fbZiQMI5VMlW9JLC/acqok+TeutM5TS+NVNjqk9S/xLtQ4r1cGs wpT+u+VE+OpYpxe6+EJX2rjayf+7Ade7eMwGH2JvLZcOldgK5UH6oR0Ra6U0bzgTpF /JuPOF6F+0g/LWM3AbXkP/9ErcNiV1GssBeORNZTaiSkTtRY1Md7b8GcaXvRQyGGeZ UFEpvo9+E3vbg== To: freebsd-fs@freebsd.org From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Subject: Problem with zpool remove of log device Message-ID: <9188a169-cd81-f64d-6b9e-0e3c6b4af1bb@wasikowski.net> Date: Fri, 26 May 2017 11:40:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 09:46:39 -0000 Hi, I cant remove log device from pool - operation ends ok, but log device is still in the pool (bug?). # uname -a FreeBSD xxx.yyy.com 11.0-STABLE FreeBSD 11.0-STABLE #0 r316543: Thu Apr 6 08:22:43 CEST 2017 root@xxx.yyy.com:/usr/obj/usr/src/sys/YYY amd64 # zpool status tank pool: tank state: ONLINE status: One or more devices are configured to use a non-native block size. Expect reduced performance. action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool. scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 02:26:36 2017 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 gpt/tankssdzil0 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/tankssdzil1 ONLINE 0 0 0 block size: 512B configured, 4096B native errors: No known data errors When I try to remove log device operation ends without errors: # zpool remove tank mirror-1; echo $? 0 But the log device is still there: # zpool status tank pool: tank state: ONLINE status: One or more devices are configured to use a non-native block size. Expect reduced performance. action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool. scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 02:26:36 2017 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 gpt/tankssdzil0 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/tankssdzil1 ONLINE 0 0 0 block size: 512B configured, 4096B native errors: No known data errors I'd like to remove it - how should I proceed? -- best regards, Lukasz Wasikowski From owner-freebsd-fs@freebsd.org Fri May 26 10:28:00 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FC4AD813E4 for ; Fri, 26 May 2017 10:28:00 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from mail.inparadise.se (h-246-50.a444.priv.bahnhof.se [155.4.246.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 264EB1A04 for ; Fri, 26 May 2017 10:27:58 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 017CF479AB; Fri, 26 May 2017 12:20:27 +0200 (CEST) Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id RIKte2hIB0Hx; Fri, 26 May 2017 12:20:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 51D54479AC; Fri, 26 May 2017 12:20:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.inparadise.se 51D54479AC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inparadise.se; s=ECF0F226-2F14-11E7-BBE9-ECFEB9BC1D67; t=1495794025; bh=owN8HvY/giWwNQ9o4M8fV/6Jl/qEmxtxzLZcwLJVaWY=; h=Date:Message-ID:To:From:MIME-Version; b=CveAF91NPPKvQOu5rDvuAQ5GkpxTnXtYjQHBrnj7Nmdgb13i9+GLouchccfz3/JRb GvXxTyBNcLcNab8B6wy6tG4BBOpQp2FhoQsWJc3zD6KfS89HWhdBdsHBZt2F9ivd6H G0GLS4tbkYGLYa/1RzNTHNpuKEZsogqLt+GNdlAOL232tZztEyDNv/7+UV1Zq4rAC5 +HA1pMPOAQDjcfheiRhHEukWwUQOyrONiamETodPJTY0uxnI2+OcB9F2evAOlVpeG8 2HB+sbwzOSooZi4uPaY6fmJV9hs91uzTGWFauJhiczCu6mmtZ3egKJ2lTGNDNZVv6Z b9T2C1Zq6zocA== X-Virus-Scanned: amavisd-new at inparadise.se Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZQ1FHgef-Bp7; Fri, 26 May 2017 12:20:24 +0200 (CEST) Received: from mail.inparadise.se (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id DDD34479AB; Fri, 26 May 2017 12:20:23 +0200 (CEST) Date: Fri, 26 May 2017 12:20:23 +0200 (CEST) Subject: Re: Problem with zpool remove of log device Message-ID: X-Android-Message-ID: To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Cc: freebsd-fs@freebsd.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= X-Originating-IP: [185.173.199.108, 127.0.0.1] X-Mailer: Zimbra 8.7.1_GA_1670 (Android-Mail/7.4.23.154506495.release(...883836) devip=185.173.199.108 ZPZB/66) Thread-Index: cS+Ve7pnjgAe2EaRGH4PewMoFIigLw== Thread-Topic: Problem with zpool remove of log device MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 10:28:00 -0000 From owner-freebsd-fs@freebsd.org Fri May 26 10:30:17 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BC30D8151C for ; Fri, 26 May 2017 10:30:17 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28FA91AC9 for ; Fri, 26 May 2017 10:30:16 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:2:1276::1]) by mail.freebsd.systems (Postfix) with ESMTP id 2147ACBD; Fri, 26 May 2017 12:30:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([5.196.167.1]) by mail.freebsd.systems (scan.freebsd.systems [5.196.167.1]) (amavisd-new, port 10026) with ESMTP id 4DaDEDd-i9OU; Fri, 26 May 2017 12:30:14 +0200 (CEST) Received: from [192.168.138.100] (unknown [194.181.68.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id EB822CBA; Fri, 26 May 2017 12:30:13 +0200 (CEST) Authentication-Results: mail.freebsd.systems; dmarc=none header.from=wasikowski.net Authentication-Results: mail.freebsd.systems; spf=pass smtp.mailfrom=lukasz@wasikowski.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1495794614; bh=fMNZdbw5ZxRM+ommCBydbGAMheSARfvmj238gNrDmEg=; h=To:Cc:References:From:Date:In-Reply-To; b=vFoNhGzq6nsAMklGyeOxB1CFggo2yGaRi4yV10vLpuu3EaPEhomZ6PtsPgKkMBtUC wnmUkuqKK/TTEgrZJsftf8n2rv73lYR+4HWKDdVIzBEptkdm4pa7haALlGDtmmKXiy 6PpQo23jiVsNg1MV++6viNQ0D2MgAa/CaCmSUPiKWoAOc+ftSvZ0ttRg3fK1FcHh3C t5wmeqt5bq3j+OpV6wlu/nAexdjYglFeYR+I2Tqr59c0wGzYIZsUEOuz/KJB/3vvyI ny6J7LD8nLDtxeUw4Nw6CGIvQBj4B+TKB65MdbYqemwomW7YBtEPXq+lOvQ15t99os QS1IRgePxqq+Q== Subject: Re: Problem with zpool remove of log device To: =?UTF-8?Q?Karli_Sj=c3=b6berg?= Cc: freebsd-fs@freebsd.org References: From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Message-ID: Date: Fri, 26 May 2017 12:30:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 10:30:17 -0000 W dniu 2017-05-26 o 12:20, Karli Sjöberg pisze: > > > Den 26 maj 2017 11:47 fm skrev Łukasz Wąsikowski : > > Hi, > > I cant remove log device from pool - operation ends ok, but log device > is still in the pool (bug?). > > # uname -a > FreeBSD xxx.yyy.com 11.0-STABLE FreeBSD 11.0-STABLE #0 r316543: Thu Apr > 6 08:22:43 CEST 2017 root@xxx.yyy.com:/usr/obj/usr/src/sys/YYY amd64 > > # zpool status tank > pool: tank > state: ONLINE > status: One or more devices are configured to use a non-native block > size. > Expect reduced performance. > action: Replace affected devices with devices that support the > configured block size, or migrate data to a properly configured > pool. > scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 > 02:26:36 2017 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > ada2p3 ONLINE 0 0 0 > ada3p3 ONLINE 0 0 0 > logs > mirror-1 ONLINE 0 0 0 > gpt/tankssdzil0 ONLINE 0 0 0 block size: > 512B configured, 4096B native > gpt/tankssdzil1 ONLINE 0 0 0 block size: > 512B configured, 4096B native > > errors: No known data errors > > When I try to remove log device operation ends without errors: > > # zpool remove tank mirror-1; echo $? > 0 > > > You are missing the actual disk you want to remove from the mirror: > # zpool remove tank gpt/tankssdzil1 # zpool remove tank gpt/tankssdzil0 cannot remove gpt/tankssdzil0: operation not supported on this type of pool According to man zpool: zpool remove pool device ... Removes the specified device from the pool. This command currently only supports removing hot spares, cache, and log devices. A mirrored log device can be removed by specifying the top-level mirror for the log. So zpool remove tank mirror-1 should work. In fact in works fine on other box with similar configuration. -- best regards, Lukasz Wasikowski From owner-freebsd-fs@freebsd.org Fri May 26 10:37:25 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F11DD8181B for ; Fri, 26 May 2017 10:37:25 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from mail.inparadise.se (h-246-50.a444.priv.bahnhof.se [155.4.246.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 402891104 for ; Fri, 26 May 2017 10:37:24 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id BE59D479B2; Fri, 26 May 2017 12:37:22 +0200 (CEST) Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7uNmNEnTwsQX; Fri, 26 May 2017 12:37:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 7ECCF479B3; Fri, 26 May 2017 12:37:20 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.inparadise.se 7ECCF479B3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inparadise.se; s=ECF0F226-2F14-11E7-BBE9-ECFEB9BC1D67; t=1495795040; bh=dzY66WRmh92qPsGeOM7Wsk2wgtYOyo6SqGfRSSJQoBM=; h=Date:Message-ID:To:From:MIME-Version; b=pPJeev3VflY24ycSpOk3d/FA9pzgr6RHI5jxgavE7opnvNvHR2dbzJ1NWIsj/qay7 lElM4pCIBNL+PWUt+TRe2ACM1r0EUJXwuTgs3reh7SId/Q2+xnK7zWVk6FqkNMZMU6 AFFkyPB3d680QO8pe9UiF9GWQL3q35h/DaM8hsK45qlcsOuvHg2gLT1HIjBW2SLD4l qoD5zYvV11G4Uk7B8fGaZ1SC8iwntXVjcL2eulionJI0Epc4zYtfta2+djC0Iu8SPR MkmBu8CRP7FOTxly3IZfk0g/Z5jfrCRayYhhFzZwXUtXobcH3QspC3MeaMWYrzoQTY CBw8fXI8Yl/kA== X-Virus-Scanned: amavisd-new at inparadise.se Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jNLY1Ne8yoCh; Fri, 26 May 2017 12:37:20 +0200 (CEST) Received: from mail.inparadise.se (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 58B2C479B2; Fri, 26 May 2017 12:37:20 +0200 (CEST) Date: Fri, 26 May 2017 12:37:19 +0200 (CEST) Subject: Re: Problem with zpool remove of log device Message-ID: <2ce18904-9fc6-47f8-945c-ef1270a3b56e@email.android.com> X-Android-Message-ID: <2ce18904-9fc6-47f8-945c-ef1270a3b56e@email.android.com> To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Cc: freebsd-fs@freebsd.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= X-Originating-IP: [185.173.199.108, 127.0.0.1] X-Mailer: Zimbra 8.7.1_GA_1670 (Android-Mail/7.4.23.154506495.release(...883836) devip=185.173.199.108 ZPZB/66) Thread-Index: UNp8BEPXJZfXMJVwCo/6W3zsmvs2Yg== Thread-Topic: Problem with zpool remove of log device MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 10:37:25 -0000 From owner-freebsd-fs@freebsd.org Fri May 26 10:43:13 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2271BD81BA7 for ; Fri, 26 May 2017 10:43:13 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B488E16E3 for ; Fri, 26 May 2017 10:43:12 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:2:1276::1]) by mail.freebsd.systems (Postfix) with ESMTP id 52D49D0B; Fri, 26 May 2017 12:43:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([5.196.167.1]) by mail.freebsd.systems (scan.freebsd.systems [5.196.167.1]) (amavisd-new, port 10026) with ESMTP id Xr9MnKMOXwom; Fri, 26 May 2017 12:43:10 +0200 (CEST) Received: from [192.168.138.100] (unknown [194.181.68.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id 6C8BCD05; Fri, 26 May 2017 12:43:09 +0200 (CEST) Authentication-Results: mail.freebsd.systems; dmarc=none header.from=wasikowski.net Authentication-Results: mail.freebsd.systems; spf=pass smtp.mailfrom=lukasz@wasikowski.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1495795389; bh=LceJx8UcWa2MFcOJJb3HUotO0/L+06uOn3KaRJYSMDo=; h=To:Cc:References:From:Date:In-Reply-To; b=h+PmaSz7bDQuyjUjT3PT6RgeVtnbRH30t+OMJmVh5NDo07FQqEKb8cBGM30A6ZSjW 6sditvXUPtG/M8wIy1iXnkqELofw98+8EnnaR4zC4vRgeOpBIffGVlH8MfP5pKMnX+ awdqM4EOFllQZ1N0CYosqgY6xdz5l62fMZW/kFv4txtVfeQL9TTzk1XABfCycXXEKC ++4OtLUTapt6HHxh1RXl4B2F7oloUVFVSWeyraZ3psYpQBolyPfGsr+ZqfV9tKGK4X leyH+HsGzpiO10ImnUBgjkq19uJGpHwB5yxpSyXLZxCpex4c8w1E6lfW9a1vCNMUdb 8opn2atHDTn3A== Subject: Re: Problem with zpool remove of log device To: =?UTF-8?Q?Karli_Sj=c3=b6berg?= Cc: freebsd-fs@freebsd.org References: <2ce18904-9fc6-47f8-945c-ef1270a3b56e@email.android.com> From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Message-ID: <0f7be3c4-de84-527d-95b2-aead2f7d6afa@wasikowski.net> Date: Fri, 26 May 2017 12:42:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <2ce18904-9fc6-47f8-945c-ef1270a3b56e@email.android.com> Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 10:43:13 -0000 W dniu 2017-05-26 o 12:37, Karli Sjöberg pisze: > Den 26 maj 2017 12:30 em skrev Łukasz Wąsikowski : > > W dniu 2017-05-26 o 12:20, Karli Sjöberg pisze: > > > > > > Den 26 maj 2017 11:47 fm skrev Łukasz Wąsikowski : > > > > Hi, > > > > I cant remove log device from pool - operation ends ok, but log device > > is still in the pool (bug?). > > > > # uname -a > > FreeBSD xxx.yyy.com 11.0-STABLE FreeBSD 11.0-STABLE #0 r316543: > Thu Apr > > 6 08:22:43 CEST 2017 root@xxx.yyy.com:/usr/obj/usr/src/sys/YYY amd64 > > > > # zpool status tank > > pool: tank > > state: ONLINE > > status: One or more devices are configured to use a non-native block > > size. > > Expect reduced performance. > > action: Replace affected devices with devices that support the > > configured block size, or migrate data to a properly configured > > pool. > > scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 > > 02:26:36 2017 > > config: > > > > NAME STATE READ WRITE CKSUM > > tank ONLINE 0 0 0 > > mirror-0 ONLINE 0 0 0 > > ada2p3 ONLINE 0 0 0 > > ada3p3 ONLINE 0 0 0 > > logs > > mirror-1 ONLINE 0 0 0 > > gpt/tankssdzil0 ONLINE 0 0 0 block size: > > 512B configured, 4096B native > > gpt/tankssdzil1 ONLINE 0 0 0 block size: > > 512B configured, 4096B native > > > > errors: No known data errors > > > > When I try to remove log device operation ends without errors: > > > > # zpool remove tank mirror-1; echo $? > > 0 > > > > > > You are missing the actual disk you want to remove from the mirror: > > # zpool remove tank gpt/tankssdzil1 > > # zpool remove tank gpt/tankssdzil0 > cannot remove gpt/tankssdzil0: operation not supported on this type > of pool > > > Yeah, that's because you're booting off of it right? Boot from CD or > whatev, should work. Or if it was the "bootfs" zpool option, can't > remember, but it's something along those lines. Really silly, but anyway... Yes, it's root-on-zfs. But as I said on other box with similar configuration it works. Strange. It's production box so boot from CD is not an easy option. I'll check it during next service window. Thank you for your help. -- best regards, Lukasz Wasikowski From owner-freebsd-fs@freebsd.org Fri May 26 10:46:10 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DCA0D81CC6 for ; Fri, 26 May 2017 10:46:10 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from mail.inparadise.se (h-246-50.a444.priv.bahnhof.se [155.4.246.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3533917C3 for ; Fri, 26 May 2017 10:46:09 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 94BD7479B6; Fri, 26 May 2017 12:46:07 +0200 (CEST) Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pj6Fwnw6f4oI; Fri, 26 May 2017 12:46:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 341A4479B8; Fri, 26 May 2017 12:46:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.inparadise.se 341A4479B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inparadise.se; s=ECF0F226-2F14-11E7-BBE9-ECFEB9BC1D67; t=1495795565; bh=QsFTuMo46Q2HUO1tlt4KyA7qDdae0WFvYHVJIJxgOvw=; h=Date:Message-ID:To:From:MIME-Version; b=iAegiePYQDUrMdmVwOnv2IJTScOmOGSoheQcrz7h4xhjxPpx3EORsSOhBaOJWIvTQ k5uaH1TdVZemozFM+vysBJhi3m1us0SynoiX451ayKTnFCGmmdHblQmaSDGOLS2rDB OXrfyaPYVwl6p7Doiv33mA4wMaa6ysgZ+MDHFdM/ZLiF79EdxK2zQiv0MSij9PlwHU AtCCaJwTX6S0GYNMl7geu20VzrQbKgZ71/lTS6p8MIAYLFhnx721UEdeWQQONqb9a3 qlSXyZsxzuXH+HM48jJ4Dr4S7OeD/61XIQsvY141Jwx5eDg3BsgWMBxU5SGlANXw+n HtoCnxZvZ2Sgg== X-Virus-Scanned: amavisd-new at inparadise.se Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id w9j2NzBHieqB; Fri, 26 May 2017 12:46:05 +0200 (CEST) Received: from mail.inparadise.se (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id DCC43479BD; Fri, 26 May 2017 12:46:04 +0200 (CEST) Date: Fri, 26 May 2017 12:46:03 +0200 (CEST) Subject: Re: Problem with zpool remove of log device Message-ID: <7fc4a6f3-df1b-47b4-9399-0dd6614ddf94@email.android.com> X-Android-Message-ID: <7fc4a6f3-df1b-47b4-9399-0dd6614ddf94@email.android.com> To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Cc: freebsd-fs@freebsd.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= X-Originating-IP: [185.173.199.108, 127.0.0.1] X-Mailer: Zimbra 8.7.1_GA_1670 (Android-Mail/7.4.23.154506495.release(...883836) devip=185.173.199.108 ZPZB/66) Thread-Index: 45UEQqyQTOCTQ+z6DxbFlq1JzrmoSA== Thread-Topic: Problem with zpool remove of log device MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 10:46:10 -0000 From owner-freebsd-fs@freebsd.org Fri May 26 11:11:04 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85DD9D7BA41 for ; Fri, 26 May 2017 11:11:04 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01082178D for ; Fri, 26 May 2017 11:11:03 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:2:1276::1]) by mail.freebsd.systems (Postfix) with ESMTP id 65168D8E; Fri, 26 May 2017 13:10:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([IPv6:2001:41d0:2:1276::1]) by mail.freebsd.systems (scan.freebsd.systems [IPv6:2001:41d0:2:1276::1]) (amavisd-new, port 10026) with ESMTP id 8Bh2hF6EDKSf; Fri, 26 May 2017 13:10:30 +0200 (CEST) Received: from [192.168.138.100] (unknown [194.181.68.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id 086ADD88; Fri, 26 May 2017 13:10:28 +0200 (CEST) Authentication-Results: mail.freebsd.systems; dmarc=none header.from=wasikowski.net Authentication-Results: mail.freebsd.systems; spf=pass smtp.mailfrom=lukasz@wasikowski.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1495797029; bh=EsOYUdRlqAwdoQbnBTFwd3KzUAJOWoleA5JWcgXbdDw=; h=To:Cc:References:From:Date:In-Reply-To; b=SG+gLicVKxeSdeSU3whWldGrxjoY90nkFbQGXp8pQiji0Oahxm2b8mHQCg97SSP5k 0f5QocFXEuoyWXAdug91OZs01eJLWypfE+BtpF7ct9CQ0Eccelem4uvQPmpT5zKZ9w DhwJWxMMsK+dQXYn8wly7CXL6HshtYem0CD7s0FlUyT1012VyI9Kax6hHFj3Pv7HGm 6D3rwjNR7e4bYulQuFkkCLb+uG0wtjuJSH5q1a0LivSEi6jchb4+mYczcbGIi6dqgM 28EUx62tQGRzbD3XO/mknhtWBdo2lFq57YqUaTeXSF8rCTXTRg4Q0QB1GftaNhlu/v hrhxComuH2ryA== Subject: Re: Problem with zpool remove of log device To: =?UTF-8?Q?Karli_Sj=c3=b6berg?= Cc: freebsd-fs@freebsd.org References: <7fc4a6f3-df1b-47b4-9399-0dd6614ddf94@email.android.com> From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Message-ID: Date: Fri, 26 May 2017 13:10:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <7fc4a6f3-df1b-47b4-9399-0dd6614ddf94@email.android.com> Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 11:11:04 -0000 W dniu 2017-05-26 o 12:46, Karli Sjöberg pisze: > > > Den 26 maj 2017 12:43 em skrev Łukasz Wąsikowski : > > W dniu 2017-05-26 o 12:37, Karli Sjöberg pisze: > > > Den 26 maj 2017 12:30 em skrev Łukasz Wąsikowski : > > > > W dniu 2017-05-26 o 12:20, Karli Sjöberg pisze: > > > > > > > > > Den 26 maj 2017 11:47 fm skrev Łukasz Wąsikowski : > > > > > > Hi, > > > > > > I cant remove log device from pool - operation ends ok, but log > device > > > is still in the pool (bug?). > > > > > > # uname -a > > > FreeBSD xxx.yyy.com 11.0-STABLE FreeBSD 11.0-STABLE #0 r316543: > > Thu Apr > > > 6 08:22:43 CEST 2017 root@xxx.yyy.com:/usr/obj/usr/src/sys/YYY amd64 > > > > > > # zpool status tank > > > pool: tank > > > state: ONLINE > > > status: One or more devices are configured to use a non-native block > > > size. > > > Expect reduced performance. > > > action: Replace affected devices with devices that support the > > > configured block size, or migrate data to a properly configured > > > pool. > > > scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 > > > 02:26:36 2017 > > > config: > > > > > > NAME STATE READ WRITE CKSUM > > > tank ONLINE 0 0 0 > > > mirror-0 ONLINE 0 0 0 > > > ada2p3 ONLINE 0 0 0 > > > ada3p3 ONLINE 0 0 0 > > > logs > > > mirror-1 ONLINE 0 0 0 > > > gpt/tankssdzil0 ONLINE 0 0 0 block size: > > > 512B configured, 4096B native > > > gpt/tankssdzil1 ONLINE 0 0 0 block size: > > > 512B configured, 4096B native > > > > > > errors: No known data errors > > > > > > When I try to remove log device operation ends without errors: > > > > > > # zpool remove tank mirror-1; echo $? > > > 0 > > > > > > > > > You are missing the actual disk you want to remove from the mirror: > > > # zpool remove tank gpt/tankssdzil1 > > > > # zpool remove tank gpt/tankssdzil0 > > cannot remove gpt/tankssdzil0: operation not supported on this type > > of pool > > > > > > Yeah, that's because you're booting off of it right? Boot from CD or > > whatev, should work. Or if it was the "bootfs" zpool option, can't > > remember, but it's something along those lines. Really silly, but > anyway... > > Yes, it's root-on-zfs. But as I said on other box with similar > configuration it works. Strange. > > It's production box so boot from CD is not an easy option. I'll check it > during next service window. Thank you for your help. > > > AFAIR you just need to null the bootfs zpool option, remove the log disk > and then reset bootfs to what it was before. No luck. # zpool get bootfs NAME PROPERTY VALUE SOURCE tank bootfs tank/ROOTFS local tankssd bootfs - default # zpool set bootfs='' tank # zpool get bootfs tank NAME PROPERTY VALUE SOURCE tank bootfs - default # zpool remove tank mirror-1; echo $? 0 # zpool status tank pool: tank state: ONLINE status: One or more devices are configured to use a non-native block size. Expect reduced performance. action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool. scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 02:26:36 2017 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 gpt/tankssdzil0 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/tankssdzil1 ONLINE 0 0 0 block size: 512B configured, 4096B native errors: No known data errors # zpool remove tank gpt/tankssdzil0; echo $? cannot remove gpt/tankssdzil0: operation not supported on this type of pool 1 -- best regards, Lukasz Wasikowski From owner-freebsd-fs@freebsd.org Fri May 26 11:23:08 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1383D82136 for ; Fri, 26 May 2017 11:23:08 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from mail.inparadise.se (h-246-50.a444.priv.bahnhof.se [155.4.246.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A70E1E8B for ; Fri, 26 May 2017 11:23:07 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 18A59479BA; Fri, 26 May 2017 13:23:05 +0200 (CEST) Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XHAt7JT0e4Fy; Fri, 26 May 2017 13:23:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 0D7E7479BB; Fri, 26 May 2017 13:23:04 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.inparadise.se 0D7E7479BB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inparadise.se; s=ECF0F226-2F14-11E7-BBE9-ECFEB9BC1D67; t=1495797784; bh=j7pIp7QJYpFRMd7W4lhHWGhjeNp8e8CAr2awF0SacEw=; h=Date:Message-ID:To:From:MIME-Version; b=jsIujGwDsVB3k6cURhO0e1LmTFmlILNTBbMjLswoqG5yHvY2X0V0A5Up9/ubNKin8 GksD2h5VuUOStIW7/oB3MJsu77sWMj4+3V+2MfpRehxoJ8C/anhZ6NEf8zThnclYVo Ctg8wVbvih7oDPdClE/kngX3RXwjCKuAPrRjvWUeGJuJokr/JkNddKmF9afAveU2tu o6M0zN3TnaLQHSQA2C0CcRH/hHx357GTAN2+cuW5SgG6e5CF5614Dtv3bfXP0fy7Hy uL7aVftiIMd7mH5lE4ms7/LTUwgt9fjB5vyQwbacFQcjldcmj+yamavkVNkhb85fFN ssXtczGyN4++w== X-Virus-Scanned: amavisd-new at inparadise.se Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hm0BpDmpGWhM; Fri, 26 May 2017 13:23:03 +0200 (CEST) Received: from mail.inparadise.se (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 73A78479BA; Fri, 26 May 2017 13:23:03 +0200 (CEST) Date: Fri, 26 May 2017 13:23:03 +0200 (CEST) Subject: Re: Problem with zpool remove of log device Message-ID: <2b0e5c3a-06ae-4205-be6a-ea9772afc771@email.android.com> X-Android-Message-ID: <2b0e5c3a-06ae-4205-be6a-ea9772afc771@email.android.com> To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Cc: freebsd-fs@freebsd.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= X-Originating-IP: [185.173.199.108, 127.0.0.1] X-Mailer: Zimbra 8.7.1_GA_1670 (Android-Mail/7.4.23.154506495.release(...883836) devip=185.173.199.108 ZPZB/66) Thread-Index: XPAYv11BjiRZYbQ0eGUNNAL/bttK9g== Thread-Topic: Problem with zpool remove of log device MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 11:23:09 -0000 From owner-freebsd-fs@freebsd.org Fri May 26 14:19:37 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DB61D82A24 for ; Fri, 26 May 2017 14:19:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id E20C71F1F; Fri, 26 May 2017 14:19:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 6024B8D0; Fri, 26 May 2017 17:19:35 +0300 (MSK) To: freebsd-fs@freebsd.org, Andriy Gapon Reply-To: lev@FreeBSD.org From: Lev Serebryakov Subject: Strange behavior of .zfs/snapshot/* directories in respect to ".." path. Organization: FreeBSD Message-ID: <1acc5917-f10f-b18a-50e0-84661173e85d@FreeBSD.org> Date: Fri, 26 May 2017 17:19:34 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 14:19:37 -0000 I have some filesystem with multiple snapshots. And behavior of "cd .." in snapshot directories is very strange: when I'm in one of dnapshot directories "cd ../other" doesn't work and "cd .." brings me to the root of file system. $ pwd /usr/home/lev $ cd .zfs/snapshot $ pwd /usr/home/lev/.zfs/snapshot $ ls | tail -2 weekly-2017-05-06_05.17.18--1y weekly-2017-05-13_04.18.37--1y $ cd weekly-2017-05-06_05.17.18--1y $ pwd /usr/home/lev/.zfs/snapshot/weekly-2017-05-06_05.17.18--1y $ cd ../weekly-2017-05-13_04.18.37--1y ../weekly-2017-05-13_04.18.37--1y: No such file or directory. $ pwd /usr/home/lev/.zfs/snapshot/weekly-2017-05-06_05.17.18--1y $ cd .. $ pwd /usr/home/lev $ uname -i -K -v FreeBSD 11.1-PRERELEASE #16 r318576: Sat May 20 22:30:06 MSK 2017 root@blob.home.serebryakov.spb.ru:/usr/obj/usr/src/sys/BLOB BLOB 1100513 $ Is it Ok? -- // Lev Serebryakov From owner-freebsd-fs@freebsd.org Fri May 26 15:36:23 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FBC2D831BC for ; Fri, 26 May 2017 15:36:23 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49E161932 for ; Fri, 26 May 2017 15:36:23 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id y201so10179979qka.0 for ; Fri, 26 May 2017 08:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ErIrClBfxw+c4bE0AWwtunBMT2Py5ZCbL6yW/yOSktI=; b=IntaYE/3je0DGCMyjdOJpSs7dDkKo/cKI3mOtsk51S0+yv7gg+euaIcNHU9Z1b2QtS 1H1J2ebcJ6SefZ3wLjwPCKA3ly7YcWAcIdn8E9nKtUGITyTePgZVNMjpSe4sZB4sDuw8 XWjYQI1Ns8J+lXSqwO4w+fVWOtVKxhunHUkn+M5GP3GNzLo2ssYMGkfKQxUvbVcfswKF QNYAMDpHK6PfE+5wIX2RI0utAX+Jy2JRlvKcNz8QBOxw4U06Neq6dW5wASGNdHFIFRYf KoUyZ3FGu6J84On0CVTqrla2sIco7zmZA7UMamtQxEPwSDgWVELziIL+TY2TeJQocdhl N6aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ErIrClBfxw+c4bE0AWwtunBMT2Py5ZCbL6yW/yOSktI=; b=I+LFMS6SR861u9t2/5s9pdnu96ZX3JeSguVBQ4Vc/v50SleupntcyA/tkc1negNVau VI0UNCn+d7juM1TymOsdhzpUufPFgN+V6E1KlzT7twIJavo49qwr/W9Zrixj8TsPmbHY mfaOx3+1URwa1A1HRJe3OklHg5zOUea7P3tmcwe+uFK9aWViwQ3nrt/6LCON6vYd29PR 3judBzw/ZNVDB9Tch9ROJYULnoGzTwqdlYy5sKzdkxg92WgfNN/1nCO5u+D2619+OTVC MzVVZeGJ5Tye6F0Cn89qx+SAHRLO8gW/33TiWpRaQA8fpr+VT5EdK1bmjMBSnCQtWmuL LxHA== X-Gm-Message-State: AODbwcBFI54Pb2aoKK+GCEc8B0S/2AX7WAg6Y2mO/6U+OLP1spCUw+f4 8VrkqbkzHsOBjd75zEAQQPTXX1CCfaQh X-Received: by 10.55.113.199 with SMTP id m190mr2598841qkc.176.1495812982366; Fri, 26 May 2017 08:36:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.20.206 with HTTP; Fri, 26 May 2017 08:36:21 -0700 (PDT) In-Reply-To: References: <7fc4a6f3-df1b-47b4-9399-0dd6614ddf94@email.android.com> From: Freddie Cash Date: Fri, 26 May 2017 08:36:21 -0700 Message-ID: Subject: Re: Problem with zpool remove of log device To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Cc: =?UTF-8?Q?Karli_Sj=C3=B6berg?= , FreeBSD Filesystems Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 15:36:23 -0000 On Fri, May 26, 2017 at 4:10 AM, =C5=81ukasz W=C4=85sikowski wrote: > W dniu 2017-05-26 o 12:46, Karli Sj=C3=B6berg pisze: > > > > > > Den 26 maj 2017 12:43 em skrev =C5=81ukasz W=C4=85sikowski >: > > > > W dniu 2017-05-26 o 12:37, Karli Sj=C3=B6berg pisze: > > > > > Den 26 maj 2017 12:30 em skrev =C5=81ukasz W=C4=85sikowski : > > > > > > W dniu 2017-05-26 o 12:20, Karli Sj=C3=B6berg pisze: > > > > > > > > > > > > Den 26 maj 2017 11:47 fm skrev =C5=81ukasz W=C4=85sikowski : > > > > > > > > Hi, > > > > > > > > I cant remove log device from pool - operation ends ok, but log > > device > > > > is still in the pool (bug?). > > > > > > > > # uname -a > > > > FreeBSD xxx.yyy.com 11.0-STABLE FreeBSD 11.0-STABLE #0 r316543: > > > Thu Apr > > > > 6 08:22:43 CEST 2017 root@xxx.yyy.com:/usr/obj/usr/src/sys/YYY > amd64 > > > > > > > > # zpool status tank > > > > pool: tank > > > > state: ONLINE > > > > status: One or more devices are configured to use a non-native > block > > > > size. > > > > Expect reduced performance. > > > > action: Replace affected devices with devices that support the > > > > configured block size, or migrate data to a properly configured > > > > pool. > > > > scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 > > > > 02:26:36 2017 > > > > config: > > > > > > > > NAME STATE READ WRITE CKSUM > > > > tank ONLINE 0 0 0 > > > > mirror-0 ONLINE 0 0 0 > > > > ada2p3 ONLINE 0 0 0 > > > > ada3p3 ONLINE 0 0 0 > > > > logs > > > > mirror-1 ONLINE 0 0 0 > > > > gpt/tankssdzil0 ONLINE 0 0 0 block size: > > > > 512B configured, 4096B native > > > > gpt/tankssdzil1 ONLINE 0 0 0 block size: > > > > 512B configured, 4096B native > > > > > > > > errors: No known data errors > > > > > > > > When I try to remove log device operation ends without errors: > > > > > > > > # zpool remove tank mirror-1; echo $? > > > > 0 > > > > > > > > > > > > You are missing the actual disk you want to remove from the > mirror: > > > > # zpool remove tank gpt/tankssdzil1 > > > > > > # zpool remove tank gpt/tankssdzil0 > > > cannot remove gpt/tankssdzil0: operation not supported on this ty= pe > > > of pool > > > > > > > > > Yeah, that's because you're booting off of it right? Boot from CD > or > > > whatev, should work. Or if it was the "bootfs" zpool option, can'= t > > > remember, but it's something along those lines. Really silly, but > > anyway... > > > > Yes, it's root-on-zfs. But as I said on other box with similar > > configuration it works. Strange. > > > > It's production box so boot from CD is not an easy option. I'll > check it > > during next service window. Thank you for your help. > > > > > > AFAIR you just need to null the bootfs zpool option, remove the log dis= k > > and then reset bootfs to what it was before. > > No luck. > > # zpool get bootfs > NAME PROPERTY VALUE SOURCE > tank bootfs tank/ROOTFS local > tankssd bootfs - default > > # zpool set bootfs=3D'' tank > > # zpool get bootfs tank > NAME PROPERTY VALUE SOURCE > tank bootfs - default > > # zpool remove tank mirror-1; echo $? > 0 > > # zpool status tank > pool: tank > state: ONLINE > status: One or more devices are configured to use a non-native block size= . > Expect reduced performance. > action: Replace affected devices with devices that support the > configured block size, or migrate data to a properly configured > pool. > scan: scrub repaired 0 in 22h21m with 0 errors on Thu May 25 02:26:36 > 2017 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > ada2p3 ONLINE 0 0 0 > ada3p3 ONLINE 0 0 0 > logs > mirror-1 ONLINE 0 0 0 > gpt/tankssdzil0 ONLINE 0 0 0 block size: > 512B configured, 4096B native > gpt/tankssdzil1 ONLINE 0 0 0 block size: > 512B configured, 4096B native > > errors: No known data errors > > > # zpool remove tank gpt/tankssdzil0; echo $? > cannot remove gpt/tankssdzil0: operation not supported on this type of po= ol > 1 > =E2=80=8BYou have your log devices in a mirror vdev. First you need to "br= eak" the mirror: # zpool detach tank =E2=80=8Bgpt/tankssdzil1 That will make the log vdev into a single-disk vdev, and then you can remove it: # zpool remove tank =E2=80=8Bgpt/tankssdzil0 After that, you should be able to re-enable the bootfs option and reboot to make sure everything is still working. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@freebsd.org Fri May 26 16:16:39 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A1BCD83FD2 for ; Fri, 26 May 2017 16:16:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 933901AF1; Fri, 26 May 2017 16:16:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07134; Fri, 26 May 2017 19:16:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dEHul-000IUz-3c; Fri, 26 May 2017 19:16:35 +0300 Subject: Re: Strange behavior of .zfs/snapshot/* directories in respect to ".." path. To: lev@FreeBSD.org, freebsd-fs@FreeBSD.org References: <1acc5917-f10f-b18a-50e0-84661173e85d@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Fri, 26 May 2017 19:15:14 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1acc5917-f10f-b18a-50e0-84661173e85d@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 16:16:39 -0000 On 26/05/2017 17:19, Lev Serebryakov wrote: > > I have some filesystem with multiple snapshots. And behavior of "cd .." > in snapshot directories is very strange: when I'm in one of dnapshot > directories "cd ../other" doesn't work and "cd .." brings me to the root > of file system. > > $ pwd > /usr/home/lev > $ cd .zfs/snapshot > $ pwd > /usr/home/lev/.zfs/snapshot > $ ls | tail -2 > weekly-2017-05-06_05.17.18--1y > weekly-2017-05-13_04.18.37--1y > $ cd weekly-2017-05-06_05.17.18--1y > $ pwd > /usr/home/lev/.zfs/snapshot/weekly-2017-05-06_05.17.18--1y > $ cd ../weekly-2017-05-13_04.18.37--1y > ../weekly-2017-05-13_04.18.37--1y: No such file or directory. > $ pwd > /usr/home/lev/.zfs/snapshot/weekly-2017-05-06_05.17.18--1y > $ cd .. > $ pwd > /usr/home/lev > $ uname -i -K -v > FreeBSD 11.1-PRERELEASE #16 r318576: Sat May 20 22:30:06 MSK 2017 > root@blob.home.serebryakov.spb.ru:/usr/obj/usr/src/sys/BLOB BLOB 1100513 > $ > > Is it Ok? This is not okay, obviously. But I can not reproduce it so far. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Fri May 26 17:17:17 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C928FD83153 for ; Fri, 26 May 2017 17:17:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EAD7017CB; Fri, 26 May 2017 17:17:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA07238; Fri, 26 May 2017 20:17:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dEIrS-000IXl-T6; Fri, 26 May 2017 20:17:14 +0300 Subject: Re: Strange behavior of .zfs/snapshot/* directories in respect to ".." path. From: Andriy Gapon To: lev@FreeBSD.org, freebsd-fs@FreeBSD.org References: <1acc5917-f10f-b18a-50e0-84661173e85d@FreeBSD.org> Message-ID: Date: Fri, 26 May 2017 20:16:18 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 17:17:17 -0000 On 26/05/2017 19:15, Andriy Gapon wrote: > On 26/05/2017 17:19, Lev Serebryakov wrote: >> >> I have some filesystem with multiple snapshots. And behavior of "cd .." >> in snapshot directories is very strange: when I'm in one of dnapshot >> directories "cd ../other" doesn't work and "cd .." brings me to the root >> of file system. >> >> $ pwd >> /usr/home/lev >> $ cd .zfs/snapshot >> $ pwd >> /usr/home/lev/.zfs/snapshot >> $ ls | tail -2 >> weekly-2017-05-06_05.17.18--1y >> weekly-2017-05-13_04.18.37--1y >> $ cd weekly-2017-05-06_05.17.18--1y >> $ pwd >> /usr/home/lev/.zfs/snapshot/weekly-2017-05-06_05.17.18--1y >> $ cd ../weekly-2017-05-13_04.18.37--1y >> ../weekly-2017-05-13_04.18.37--1y: No such file or directory. >> $ pwd >> /usr/home/lev/.zfs/snapshot/weekly-2017-05-06_05.17.18--1y >> $ cd .. >> $ pwd >> /usr/home/lev >> $ uname -i -K -v >> FreeBSD 11.1-PRERELEASE #16 r318576: Sat May 20 22:30:06 MSK 2017 >> root@blob.home.serebryakov.spb.ru:/usr/obj/usr/src/sys/BLOB BLOB 1100513 >> $ >> >> Is it Ok? > > This is not okay, obviously. > But I can not reproduce it so far. > > Actually, I can... I will take a look. Thank you for the report. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Fri May 26 21:10:05 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09BA0D830CA for ; Fri, 26 May 2017 21:10:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDAD8176B for ; Fri, 26 May 2017 21:10:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4QLA412070637 for ; Fri, 26 May 2017 21:10:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Fri, 26 May 2017 21:10:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:10:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 --- Comment #8 from Anton Sayetsky --- Created attachment 182943 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D182943&action= =3Dedit output of "zfs-stats -a" when ARC reaches minimum (w/o swap) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 26 21:10:46 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABAB6D831AB for ; Fri, 26 May 2017 21:10:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98E3919D7 for ; Fri, 26 May 2017 21:10:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4QLAk7x099585 for ; Fri, 26 May 2017 21:10:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Fri, 26 May 2017 21:10:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:10:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 --- Comment #9 from Anton Sayetsky --- Created attachment 182944 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D182944&action= =3Dedit output of "vmstat -z" when ARC reaches minimum (w/o swap) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 26 21:11:14 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56E50D83364 for ; Fri, 26 May 2017 21:11:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46D541BE6 for ; Fri, 26 May 2017 21:11:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4QLBEOG019577 for ; Fri, 26 May 2017 21:11:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Fri, 26 May 2017 21:11:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:11:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 --- Comment #10 from Anton Sayetsky --- Created attachment 182945 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D182945&action= =3Dedit output of "procstat -kka" when ARC reaches minimum (w/o swap) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 26 21:11:44 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FE19D833EE for ; Fri, 26 May 2017 21:11:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FDA61CCF for ; Fri, 26 May 2017 21:11:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4QLBiL2024874 for ; Fri, 26 May 2017 21:11:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Fri, 26 May 2017 21:11:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:11:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 --- Comment #11 from Anton Sayetsky --- Created attachment 182946 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D182946&action= =3Dedit output of "sysctl vm" when ARC reaches minimum (w/o swap) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 26 21:22:58 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E993D83700 for ; Fri, 26 May 2017 21:22:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E5EB12A7 for ; Fri, 26 May 2017 21:22:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4QLMvIK053277 for ; Fri, 26 May 2017 21:22:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Fri, 26 May 2017 21:22:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:22:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 --- Comment #12 from Anton Sayetsky --- (In reply to Fabian Keil from comment #6) > The procstat output suggests that you might be using geli for the swap de= vice. Yes, you're right. I'm using GELI (AES-256-XTS/SHA256/onetime) over gmirror= of 2 gpt partitions. > This is known to cause deadlocks under memory pressure: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209759 Disabled GELI swap & stopped relevant gmirror -- still got ARC eviction aft= er running tar... > You could reduce vfs.zfs.deadman_synctime_ms to more quickly get a panic when the system becomes unresponsive. Unfortunately, I cannot see any panics (and thus, stack traces). System just hangs w/o any output to logs or console, and all that I can do - reset or p= ower cycle through IPMI interface. I'm thinking about compiling kernel with KDB/= DDB and collecting coredump with NMI. > It would probably help to see the counters in vm_cnt. Attached relevant sysctl output & similar diagnostics as before, but w/o sw= ap. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri May 26 21:24:08 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D0C7D83770 for ; Fri, 26 May 2017 21:24:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F11961380 for ; Fri, 26 May 2017 21:24:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4QLO7x3054657 for ; Fri, 26 May 2017 21:24:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219457] ZFS ARC eviction & system hangup Date: Fri, 26 May 2017 21:24:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:24:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219457 --- Comment #13 from Anton Sayetsky --- (In reply to Fabian Keil from comment #6) > The procstat output suggests that you might be using geli for the swap de= vice. Yes, you're right. I'm using GELI (AES-256-XTS/SHA256/onetime) over gmirror= of 2 gpt partitions. > This is known to cause deadlocks under memory pressure: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209759 Disabled GELI swap & stopped relevant gmirror -- still got ARC eviction aft= er running tar... > You could reduce vfs.zfs.deadman_synctime_ms to more quickly get a panic = when the system becomes unresponsive. Unfortunately, I cannot see any panics (and thus, stack traces). System just hangs w/o any output to logs or console, and all that I can do - reset or p= ower cycle through IPMI interface. I'm thinking about compiling kernel with KDB/= DDB and collecting coredump with NMI. > It would probably help to see the counters in vm_cnt. Attached relevant sysctl output & similar diagnostics as before, but w/o sw= ap. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat May 27 02:08:44 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0AF0D832DF for ; Sat, 27 May 2017 02:08:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9091716E1 for ; Sat, 27 May 2017 02:08:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4R28ifu094355 for ; Sat, 27 May 2017 02:08:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219537] OpenZFS 8166 - zpool scrub thinks it repaired offline device Date: Sat, 27 May 2017 02:08:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: allanjude@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 02:08:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219537 Allan Jude changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #1 from Allan Jude --- This only landed upstream 3 days ago, but it is a small fix so we should be able to grab it easily. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Sat May 27 02:10:45 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09F56D83659 for ; Sat, 27 May 2017 02:10:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDE731871 for ; Sat, 27 May 2017 02:10:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4R2Aib7007461 for ; Sat, 27 May 2017 02:10:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219537] OpenZFS 8166 - zpool scrub thinks it repaired offline device Date: Sat, 27 May 2017 02:10:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: allanjude@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 02:10:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219537 Allan Jude changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avg@FreeBSD.org, | |jpaetzel@FreeBSD.org, | |re@FreeBSD.org --- Comment #2 from Allan Jude --- This should get merged in time for 11.1 since it is low risk and high impac= t. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Sat May 27 02:36:37 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 889F3D83E65 for ; Sat, 27 May 2017 02:36:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7895B1CD8 for ; Sat, 27 May 2017 02:36:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4R2abXr069025 for ; Sat, 27 May 2017 02:36:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219433] ZFS volume cannot be created by delegated user Date: Sat, 27 May 2017 02:36:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: allanjude@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 02:36:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219433 --- Comment #1 from Allan Jude --- A regular user cannot create a device node, like /dev/zvol/mypool/container/myvolume so this cannot work. --=20 You are receiving this mail because: You are the assignee for the bug.=