From owner-freebsd-fs@FreeBSD.ORG Sun Jan 26 02:06:09 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 586F1A3D; Sun, 26 Jan 2014 02:06:09 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id ECA971C9B; Sun, 26 Jan 2014 02:06:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: X-IronPort-AV: E=Sophos;i="4.95,721,1384318800"; d="scan'208";a="91061919" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Jan 2014 21:05:54 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5FF6AB4049; Sat, 25 Jan 2014 21:05:54 -0500 (EST) Date: Sat, 25 Jan 2014 21:05:54 -0500 (EST) From: Rick Macklem To: Roman Divacky Message-ID: <1647701889.16319715.1390701954380.JavaMail.root@uoguelph.ca> In-Reply-To: <20140126051258.M1750@besplex.bde.org> Subject: Re: BUG: possible NULL pointer dereference in nfs server MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 02:06:09 -0000 Bruce Evans wrote: > On Sat, 25 Jan 2014, Dimitry Andric wrote: > > > On 25 Jan 2014, at 01:38, Rick Macklem > > wrote: > > ... > > If it inlines this, the result looks approximately like: > > > > 1 { > > 2 fhandle_t *fhp = NULL; > > 3 struct nfslockfile *new_lfp; > > 4 int error; > > 5 > > 6 if (new_stp->ls_flags & NFSLCK_OPEN) { > > 7 new_lfp = *NULL; > > 8 fhp = &new_lfp->lf_fh; > > 9 } else if (&nfh) { > > 10 fhp = &nfh; > > 11 } else { > > 12 panic("nfsrv_getlockfh"); > > 13 } > > 14 error = nfsvno_getfh(vp, fhp, p); > > 15 NFSEXITCODE(error); > > 16 getlckret = error; > > 17 } > > > > The code in line 7 is the problematic part. Since this is > > undefined, > > the compiler inserts a trap instruction here. I think the problem > > Roman > > encountered is that on sparc64, there is no equivalent to x86's ud2 > > instruction, so it inserts a call to abort() instead, and that > > function > > is not available in kernel-land. > > Compiler bug. abort() is not available in freestanding > implementations. > The behaviour is only undefined if the null pointer is dereferenced > at > runtime, so it doesn't include failing to link to abort() at compile > time. > > > ... > >> Sorry, I'm not a compiler guy, so I don't know why a compiler > >> would > >> generate a trap instruction, but since new_lfpp is never NULL when > >> this is executed, I don't see a problem. > >> > >> If others feel that this needs to be re-coded, please let me know > >> what > >> you think the code should look like? (A test for non-NULL with a > >> panic() > >> before it is used?) > >> > >> Is a trap instruction that never gets executed a problem? > > > > It's better to avoid undefined behavior in any case. Just add a > > NULL > > check, that should be sufficient. > > That might only add bloat and unimprove debugging. Since the null > pointer > case cannot happen, it cannot be handed properly. It can be > mishandled in > the following ways: > - return an error, so that all callers have to handle the null > pointer case > that can't happen. If the compiler is too smart, it will notice > more > undefined behaviour (that can't happen) in callers and "force" you > to > handle it there too > - KASSERT() that the pointer cannot be null. Then: > - on production systems where KASSERT() is null, this won't work > around > the compiler bug. Use a panic() instead. To maximize source > code > bloat, ifdef all of this. > - when KASSERT() is not null, it will work around the compiler > bug. > If the case that can't happen actually happens, then this > unimproves > the debugging by messing up stack traces and turning restartable > null pointer or SIGILL traps to non-restartable panics. > Optimizations that replace a large block of code ending with a > null pointer trap by a single unimplemented instruction would > probably break restarting anyway. > > Bruce > So Roman, all I can suggest is to try adding something like: if (new_lfpp == NULL) panic("new_lfpp NULL"); after line#6. If that makes the compiler happy, I can commit it in April. (Can't do commits before then.) I agree with Bruce, but the check might be a good idea, in case a future code change introduces a bug where the function is called with new_lfpp NULL and NFSLCK_OPEN set. If this doesn't make the compiler happy, all I can suggest is to play around until you come up with something that works. Have fun with it, rick ps: I haven't seen this reported by tinderbox. Is the problem specific to your setup? From owner-freebsd-fs@FreeBSD.ORG Sun Jan 26 02:25:33 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A6C6DD8; Sun, 26 Jan 2014 02:25:33 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCAB41DB2; Sun, 26 Jan 2014 02:25:32 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0Q2PU2n045130; Sat, 25 Jan 2014 21:25:30 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s0Q2PUp1045129; Sat, 25 Jan 2014 21:25:30 -0500 (EST) (envelope-from wollman) Date: Sat, 25 Jan 2014 21:25:30 -0500 (EST) Message-Id: <201401260225.s0Q2PUp1045129@hergotha.csail.mit.edu> From: wollman@freebsd.org To: rmacklem@uoguelph.ca Subject: Re: Terrible NFS performance under 9.2-RELEASE? X-Newsgroups: mit.lcs.mail.freebsd-net In-Reply-To: <278396201.16318356.1390701347722.JavaMail.root@uoguelph.ca> References: Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 25 Jan 2014 21:25:30 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 02:25:33 -0000 In article <278396201.16318356.1390701347722.JavaMail.root@uoguelph.ca>, Rick Macklem writes: >Well, when I get home in April, I'll try the fairly recent Linux client >I have at home and see what it does. Not sure what trick they could use >to avoid the read before write for partial pages. (I suppose I can >look at their sources, but that could be pretty scary;-) For what it's worth, our performance for large-block 100%-read workloads is also not what it could (or ought to) be. Between two 20G-attached servers, I can get about 12 Gbit/s with three parallel TCP connections. (Multiple connections are required to trick the lagg hash into balancing the load across both 10G links, because the hash function used for load-balancing uses the source and destination ports.) On the same pair of servers, "dd if=/mnt/test bs=1024k" runs at about 3 Gbit/s, whereas reading from the local filesystem goes anywhere from 1.5 to 3 G*byte*/s (i.e., eight times faster) with much higher CPU utilization. Luckily, most of our users are only connected at 1G so they don't notice. I'm going to lose my test server soon (it has to go into production shortly), so I'm not really able to work on this. I'll have another test server soon (old hardware being replaced by the new server) and hope to be able to try out the new code that's going to be in 10.1, with the expectation of upgrading to 10.x over summer break. -GAWollman From owner-freebsd-fs@FreeBSD.ORG Sun Jan 26 02:36:33 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64AC9257; Sun, 26 Jan 2014 02:36:33 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 03BF11E4D; Sun, 26 Jan 2014 02:36:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8UACJ05FKDaFve/2dsb2JhbABagXICAYFPVoJ9tVKDL0+BH3SCJQEBAQMBAQEBICsgCwUWGAICDRkCKQEJJg4HBAEcBIdcCA2rYJwvF4EpjRMBAQ0ONAcWglmBSQSJSIwMhAWQbINLHjF9Bxci X-IronPort-AV: E=Sophos;i="4.95,721,1384318800"; d="scan'208";a="90488526" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Jan 2014 21:36:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 026E5B4042; Sat, 25 Jan 2014 21:36:26 -0500 (EST) Date: Sat, 25 Jan 2014 21:36:26 -0500 (EST) From: Rick Macklem To: wollman@freebsd.org Message-ID: <188195924.16327973.1390703786000.JavaMail.root@uoguelph.ca> In-Reply-To: <201401260225.s0Q2PUp1045129@hergotha.csail.mit.edu> Subject: Re: Terrible NFS performance under 9.2-RELEASE? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 02:36:33 -0000 Garrett Wollman wrote: > In article > <278396201.16318356.1390701347722.JavaMail.root@uoguelph.ca>, Rick > Macklem writes: > > >Well, when I get home in April, I'll try the fairly recent Linux > >client > >I have at home and see what it does. Not sure what trick they could > >use > >to avoid the read before write for partial pages. (I suppose I can > >look at their sources, but that could be pretty scary;-) > > For what it's worth, our performance for large-block 100%-read > workloads is also not what it could (or ought to) be. Between two > 20G-attached servers, I can get about 12 Gbit/s with three parallel > TCP connections. (Multiple connections are required to trick the > lagg > hash into balancing the load across both 10G links, because the hash > function used for load-balancing uses the source and destination > ports.) On the same pair of servers, "dd if=/mnt/test bs=1024k" runs > at about 3 Gbit/s, whereas reading from the local filesystem goes > anywhere from 1.5 to 3 G*byte*/s (i.e., eight times faster) with much > higher CPU utilization. Luckily, most of our users are only > connected > at 1G so they don't notice. > Have you tried increasing readahead by any chance? I think the default is 1, which means the client will make 2 read requests and then wait for those replies before doing any more reads. Since you have fast links, maybe the 2 * 64K reads isn't enough to keep the pipe filled? (This depends on latency, which you didn't mention.) Might be worth trying, rick ps: If/when you have a test server, you could also try compiling a kernel with MAXBSIZE set to 128Kbytes instead of 64Kbytes. You'll need to boot this kernel on both the server and client (assuming a FreeBSD client) before the default rsize will increase to 128Kbytes. I'm no ZFS guy, but I understand 128Kbytes is the blocksize it likes. > I'm going to lose my test server soon (it has to go into production > shortly), so I'm not really able to work on this. I'll have another > test server soon (old hardware being replaced by the new server) and > hope to be able to try out the new code that's going to be in 10.1, > with the expectation of upgrading to 10.x over summer break. > > -GAWollman > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sun Jan 26 03:01:59 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BA1481F for ; Sun, 26 Jan 2014 03:01:59 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 250B9109D for ; Sun, 26 Jan 2014 03:01:58 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0Q31s1K045572; Sat, 25 Jan 2014 22:01:54 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s0Q31rXu045569; Sat, 25 Jan 2014 22:01:53 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21220.31393.533799.991163@hergotha.csail.mit.edu> Date: Sat, 25 Jan 2014 22:01:53 -0500 From: Garrett Wollman To: Matthew Ahrens Subject: Re: ZFS read performance anomaly / performance regression In-Reply-To: References: <21219.21690.165105.561362@hergotha.csail.mit.edu> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 25 Jan 2014 22:01:54 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 03:01:59 -0000 < said: > How are you reading the files? Could you be reading in less than > block-size chunks (default 128K)? Nope. dd bs=1024k. > This sounds similar to issue discussed in the thread with subject "ZFS slow > reads for unallocated blocks", which was comparing sparse vs cached reads. > Since your storage is so fast, prefetch will probably read and cache the > blocks by the time you issue the read() syscall, so you may be hitting a > similar issue. How would that have changed between 9.1 and 9.2? -GAWollman From owner-freebsd-fs@FreeBSD.ORG Sun Jan 26 03:13:17 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AD51B4D; Sun, 26 Jan 2014 03:13:17 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 452041188; Sun, 26 Jan 2014 03:13:17 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0Q3DFEw045684; Sat, 25 Jan 2014 22:13:15 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s0Q3DFYt045681; Sat, 25 Jan 2014 22:13:15 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21220.32074.958702.595502@hergotha.csail.mit.edu> Date: Sat, 25 Jan 2014 22:13:14 -0500 From: Garrett Wollman To: Rick Macklem Subject: Re: Terrible NFS performance under 9.2-RELEASE? In-Reply-To: <188195924.16327973.1390703786000.JavaMail.root@uoguelph.ca> References: <201401260225.s0Q2PUp1045129@hergotha.csail.mit.edu> <188195924.16327973.1390703786000.JavaMail.root@uoguelph.ca> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 25 Jan 2014 22:13:15 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 03:13:17 -0000 < said: > Have you tried increasing readahead by any chance? I think the default > is 1, which means the client will make 2 read requests and then wait for > those replies before doing any more reads. Since you have fast links, > maybe the 2 * 64K reads isn't enough to keep the pipe filled? (This > depends on latency, which you didn't mention.) -o readahead=4 nearly doubles the speed, to a bit over 5 Gbit/s. Oddly, when I unmount the filesystem, the test client sometimes freezes for 15-30 seconds. Since I'm not on the console I can't tell what it's doing when this happens. -GAWollman From owner-freebsd-fs@FreeBSD.ORG Sun Jan 26 03:19:24 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 576EFCC4; Sun, 26 Jan 2014 03:19:24 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id EA2CF11C8; Sun, 26 Jan 2014 03:19:23 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAHF95FKDaFve/2dsb2JhbABag0RWgn25AU+BH3SCJQEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASHXAgNq1+cLheBKY0TAQEbNAeCb4FJBIlIjAyEBZBsg0seMYEEOQ X-IronPort-AV: E=Sophos;i="4.95,721,1384318800"; d="scan'208";a="90491411" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Jan 2014 22:19:23 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 15FD7B4054; Sat, 25 Jan 2014 22:19:23 -0500 (EST) Date: Sat, 25 Jan 2014 22:19:23 -0500 (EST) From: Rick Macklem To: Garrett Wollman Message-ID: <688905116.16333139.1390706363082.JavaMail.root@uoguelph.ca> In-Reply-To: <21220.32074.958702.595502@hergotha.csail.mit.edu> Subject: Re: Terrible NFS performance under 9.2-RELEASE? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 03:19:24 -0000 Garrett Wollman wrote: > < said: > > > Have you tried increasing readahead by any chance? I think the > > default > > is 1, which means the client will make 2 read requests and then > > wait for > > those replies before doing any more reads. Since you have fast > > links, > > maybe the 2 * 64K reads isn't enough to keep the pipe filled? (This > > depends on latency, which you didn't mention.) > > -o readahead=4 nearly doubles the speed, to a bit over 5 Gbit/s. > And "-o readahead=8" is slower or faster? (I think you can go up to at least 16, but I can't remember the upper bound. It's in one of the .h files.;-) > Oddly, when I unmount the filesystem, the test client sometimes > freezes for 15-30 seconds. Since I'm not on the console I can't tell > what it's doing when this happens. > Hmm, no idea. Maybe it takes a while to throw away all the buffer cache blocks? I run such small systems by to-days standards, I wouldn't see a delay that "might" occur for a large buffer cache. At least a little progress, rick > -GAWollman > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sun Jan 26 10:06:32 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B622F9D for ; Sun, 26 Jan 2014 10:06:32 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6424B1959 for ; Sun, 26 Jan 2014 10:06:31 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 659021251B78; Sun, 26 Jan 2014 11:06:22 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 6.3857] X-CRM114-CacheID: sfid-20140126_11062_3C9F5317 X-CRM114-Status: Good ( pR: 6.3857 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Jan 26 11:06:22 2014 X-DSPAM-Confidence: 0.9938 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52e4de1e907001756277832 X-DSPAM-Factors: 27, kernel, 0.00088, cache, 0.00176, Is+this, 0.00278, the+kernel, 0.00310, From*"Nagy, Attila" , 0.00330, ZFS, 0.00439, noticed+that, 0.00439, Subject*ZFS, 0.00479, Cache, 0.00527, there+a, 0.00585, sysctl, 0.00585, Received*online.co.hu+[195.228.243.99]), 0.00657, Received*[195.228.243.99]), 0.00657, Received*online.co.hu, 0.00657, Received*(japan.t, 0.00657, Received*(japan.t+online.co.hu, 0.00657, Is+there, 0.00751, output, 0.00782, VM, 0.00875, Received*from+japan.t, 0.00875, Header, 0.00875, Received*online.private+(japan.t, 0.00875, Received*japan.t+online.private, 0.00875, Received*japan.t, 0.00875, releasing, 0.00875, (and, 0.00912, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 3E83E1251B69 for ; Sun, 26 Jan 2014 11:06:21 +0100 (CET) Message-ID: <52E4DE17.3000206@fsn.hu> Date: Sun, 26 Jan 2014 11:06:15 +0100 From: "Nagy, Attila" MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Lot more swapping in stable/10 with ZFS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 10:06:32 -0000 Hi, Running stable/10@r261157 (and earlier too), I've noticed that it swaps much more than previous (stable/9) versions. Current top output from such a machine: Mem: 251M Active, 21M Inact, 7491M Wired, 118M Cache, 17M Buf, 51M Free ARC: 5112M Total, 1455M MFU, 2155M MRU, 7761K Anon, 293M Header, 1223M Other Swap: 2045M Total, 757M Used, 1287M Free, 37% Inuse, 1280K Out (there are frequent ins too, so I wouldn't say that the kernel just throws unused pages out) Why ZFS keeps its cache instead of releasing it and free up memory to avoid swapping? Is there a better way to change this than lowering ARC's maximum usage? All *swap* sysctl values are the same as on 9 versions. Is this something changed in the VM handling or in ZFS? Thanks, From owner-freebsd-fs@FreeBSD.ORG Mon Jan 27 11:06:46 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6673BC36 for ; Mon, 27 Jan 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 459701A82 for ; Mon, 27 Jan 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0RB6kYw012985 for ; Mon, 27 Jan 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0RB6j0O012983 for freebsd-fs@FreeBSD.org; Mon, 27 Jan 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Jan 2014 11:06:45 GMT Message-Id: <201401271106.s0RB6j0O012983@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/185858 fs [zfs] zvol clone can't see new device o kern/184478 fs [smbfs] mount_smbfs cannot read/write files o kern/182536 fs [zfs] zfs deadlock o kern/181966 fs [zfs] Kernel panic in ZFS I/O: solaris assert: BP_EQUA o kern/181834 fs [nfs] amd mounting NFS directories can drive a dead-lo o kern/181565 fs [swap] Problem with vnode-backed swap space. o kern/181377 fs [zfs] zfs recv causes an inconsistant pool o kern/181281 fs [msdosfs] stack trace after successfull 'umount /mnt' o kern/181082 fs [fuse] [ntfs] Write to mounted NTFS filesystem using F o kern/180979 fs [netsmb][patch]: Fix large files handling o kern/180876 fs [zfs] [hast] ZFS with trim,bio_flush or bio_delete loc o kern/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS s kern/178467 fs [zfs] [request] Optimized Checksum Code for ZFS o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178387 fs [zfs] [patch] sparse files performance improvements o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/145750 fs [unionfs] [hang] unionfs locks the machine s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/67326 fs [msdosfs] crash after attempt to mount write protected o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t o kern/9619 fs [nfs] Restarting mountd kills existing mounts 335 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 27 18:37:51 2014 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EF5A2E4; Mon, 27 Jan 2014 18:37:51 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [95.129.96.251]) by mx1.freebsd.org (Postfix) with ESMTP id A259A13C9; Mon, 27 Jan 2014 18:37:50 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 0FC8E1CC5593; Mon, 27 Jan 2014 19:37:43 +0100 (CET) Date: Mon, 27 Jan 2014 19:37:43 +0100 From: Roman Divacky To: Rick Macklem Subject: Re: BUG: possible NULL pointer dereference in nfs server Message-ID: <20140127183743.GA74668@freebsd.org> References: <20140126051258.M1750@besplex.bde.org> <1647701889.16319715.1390701954380.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1647701889.16319715.1390701954380.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:37:51 -0000 On Sat, Jan 25, 2014 at 09:05:54PM -0500, Rick Macklem wrote: > Bruce Evans wrote: > > On Sat, 25 Jan 2014, Dimitry Andric wrote: > > > > > On 25 Jan 2014, at 01:38, Rick Macklem > > > wrote: > > > ... > > > If it inlines this, the result looks approximately like: > > > > > > 1 { > > > 2 fhandle_t *fhp = NULL; > > > 3 struct nfslockfile *new_lfp; > > > 4 int error; > > > 5 > > > 6 if (new_stp->ls_flags & NFSLCK_OPEN) { > > > 7 new_lfp = *NULL; > > > 8 fhp = &new_lfp->lf_fh; > > > 9 } else if (&nfh) { > > > 10 fhp = &nfh; > > > 11 } else { > > > 12 panic("nfsrv_getlockfh"); > > > 13 } > > > 14 error = nfsvno_getfh(vp, fhp, p); > > > 15 NFSEXITCODE(error); > > > 16 getlckret = error; > > > 17 } > > > > > > The code in line 7 is the problematic part. Since this is > > > undefined, > > > the compiler inserts a trap instruction here. I think the problem > > > Roman > > > encountered is that on sparc64, there is no equivalent to x86's ud2 > > > instruction, so it inserts a call to abort() instead, and that > > > function > > > is not available in kernel-land. > > > > Compiler bug. abort() is not available in freestanding > > implementations. > > The behaviour is only undefined if the null pointer is dereferenced > > at > > runtime, so it doesn't include failing to link to abort() at compile > > time. > > > > > ... > > >> Sorry, I'm not a compiler guy, so I don't know why a compiler > > >> would > > >> generate a trap instruction, but since new_lfpp is never NULL when > > >> this is executed, I don't see a problem. > > >> > > >> If others feel that this needs to be re-coded, please let me know > > >> what > > >> you think the code should look like? (A test for non-NULL with a > > >> panic() > > >> before it is used?) > > >> > > >> Is a trap instruction that never gets executed a problem? > > > > > > It's better to avoid undefined behavior in any case. Just add a > > > NULL > > > check, that should be sufficient. > > > > That might only add bloat and unimprove debugging. Since the null > > pointer > > case cannot happen, it cannot be handed properly. It can be > > mishandled in > > the following ways: > > - return an error, so that all callers have to handle the null > > pointer case > > that can't happen. If the compiler is too smart, it will notice > > more > > undefined behaviour (that can't happen) in callers and "force" you > > to > > handle it there too > > - KASSERT() that the pointer cannot be null. Then: > > - on production systems where KASSERT() is null, this won't work > > around > > the compiler bug. Use a panic() instead. To maximize source > > code > > bloat, ifdef all of this. > > - when KASSERT() is not null, it will work around the compiler > > bug. > > If the case that can't happen actually happens, then this > > unimproves > > the debugging by messing up stack traces and turning restartable > > null pointer or SIGILL traps to non-restartable panics. > > Optimizations that replace a large block of code ending with a > > null pointer trap by a single unimplemented instruction would > > probably break restarting anyway. > > > > Bruce > > > So Roman, all I can suggest is to try adding something like: > if (new_lfpp == NULL) > panic("new_lfpp NULL"); > after line#6. If that makes the compiler happy, I can commit it in > April. (Can't do commits before then.) The compiler already inserts "trap" instruction when such a condition happens so this seem superfluous. > I agree with Bruce, but the check might be a good idea, in case a > future code change introduces a bug where the function is called with > new_lfpp NULL and NFSLCK_OPEN set. > > If this doesn't make the compiler happy, all I can suggest is to > play around until you come up with something that works. KASSERT() doesnt communicate that it's an assert, because it can just log into console a carry on. Would you be ok with this patch? Index: fs/nfsserver/nfs_nfsdstate.c =================================================================== --- fs/nfsserver/nfs_nfsdstate.c (revision 261037) +++ fs/nfsserver/nfs_nfsdstate.c (working copy) @@ -1384,7 +1384,8 @@ * If we are doing Lock/LockU and local locking is enabled, sleep * lock the nfslockfile structure. */ - getlckret = nfsrv_getlockfh(vp, new_stp->ls_flags, NULL, &nfh, p); + KASSERT((new_stp->ls_flags & NFSLCK_OPEN) == 0, ("nfsrv_lockctrl: calling nfsrv_getlockfh with NFSLCK_OPEN")); + getlckret = nfsrv_getlockfh(vp, new_stp->ls_flags & ~NFSLCK_OPEN, NULL, &nfh, p); NFSLOCKSTATE(); if (getlckret == 0) { if ((new_stp->ls_flags & (NFSLCK_LOCK | NFSLCK_UNLOCK)) != 0 && > Have fun with it, rick > ps: I haven't seen this reported by tinderbox. Is the problem > specific to your setup? It is present even in your setup :) Just "objdump -d kernel | grep ud2" on kernel compiled by clang. Roman From owner-freebsd-fs@FreeBSD.ORG Mon Jan 27 23:04:20 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E242D277; Mon, 27 Jan 2014 23:04:19 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD621A91; Mon, 27 Jan 2014 23:04:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: X-IronPort-AV: E=Sophos;i="4.95,731,1384318800"; d="scan'208";a="91462958" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 27 Jan 2014 18:04:17 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BFA18B4044; Mon, 27 Jan 2014 18:04:17 -0500 (EST) Date: Mon, 27 Jan 2014 18:04:17 -0500 (EST) From: Rick Macklem To: Roman Divacky Message-ID: <410866336.17211125.1390863857778.JavaMail.root@uoguelph.ca> In-Reply-To: <20140127183743.GA74668@freebsd.org> Subject: Re: BUG: possible NULL pointer dereference in nfs server MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:04:20 -0000 Roman Divacky wrote: > On Sat, Jan 25, 2014 at 09:05:54PM -0500, Rick Macklem wrote: > > Bruce Evans wrote: > > > On Sat, 25 Jan 2014, Dimitry Andric wrote: > > > > > > > On 25 Jan 2014, at 01:38, Rick Macklem > > > > wrote: > > > > ... > > > > If it inlines this, the result looks approximately like: > > > > > > > > 1 { > > > > 2 fhandle_t *fhp = NULL; > > > > 3 struct nfslockfile *new_lfp; > > > > 4 int error; > > > > 5 > > > > 6 if (new_stp->ls_flags & NFSLCK_OPEN) { > > > > 7 new_lfp = *NULL; > > > > 8 fhp = &new_lfp->lf_fh; > > > > 9 } else if (&nfh) { > > > > 10 fhp = &nfh; > > > > 11 } else { > > > > 12 panic("nfsrv_getlockfh"); > > > > 13 } > > > > 14 error = nfsvno_getfh(vp, fhp, p); > > > > 15 NFSEXITCODE(error); > > > > 16 getlckret = error; > > > > 17 } > > > > > > > > The code in line 7 is the problematic part. Since this is > > > > undefined, > > > > the compiler inserts a trap instruction here. I think the > > > > problem > > > > Roman > > > > encountered is that on sparc64, there is no equivalent to x86's > > > > ud2 > > > > instruction, so it inserts a call to abort() instead, and that > > > > function > > > > is not available in kernel-land. > > > > > > Compiler bug. abort() is not available in freestanding > > > implementations. > > > The behaviour is only undefined if the null pointer is > > > dereferenced > > > at > > > runtime, so it doesn't include failing to link to abort() at > > > compile > > > time. > > > > > > > ... > > > >> Sorry, I'm not a compiler guy, so I don't know why a compiler > > > >> would > > > >> generate a trap instruction, but since new_lfpp is never NULL > > > >> when > > > >> this is executed, I don't see a problem. > > > >> > > > >> If others feel that this needs to be re-coded, please let me > > > >> know > > > >> what > > > >> you think the code should look like? (A test for non-NULL with > > > >> a > > > >> panic() > > > >> before it is used?) > > > >> > > > >> Is a trap instruction that never gets executed a problem? > > > > > > > > It's better to avoid undefined behavior in any case. Just add > > > > a > > > > NULL > > > > check, that should be sufficient. > > > > > > That might only add bloat and unimprove debugging. Since the > > > null > > > pointer > > > case cannot happen, it cannot be handed properly. It can be > > > mishandled in > > > the following ways: > > > - return an error, so that all callers have to handle the null > > > pointer case > > > that can't happen. If the compiler is too smart, it will > > > notice > > > more > > > undefined behaviour (that can't happen) in callers and "force" > > > you > > > to > > > handle it there too > > > - KASSERT() that the pointer cannot be null. Then: > > > - on production systems where KASSERT() is null, this won't > > > work > > > around > > > the compiler bug. Use a panic() instead. To maximize > > > source > > > code > > > bloat, ifdef all of this. > > > - when KASSERT() is not null, it will work around the compiler > > > bug. > > > If the case that can't happen actually happens, then this > > > unimproves > > > the debugging by messing up stack traces and turning > > > restartable > > > null pointer or SIGILL traps to non-restartable panics. > > > Optimizations that replace a large block of code ending with > > > a > > > null pointer trap by a single unimplemented instruction > > > would > > > probably break restarting anyway. > > > > > > Bruce > > > > > So Roman, all I can suggest is to try adding something like: > > if (new_lfpp == NULL) > > panic("new_lfpp NULL"); > > after line#6. If that makes the compiler happy, I can commit it in > > April. (Can't do commits before then.) > > The compiler already inserts "trap" instruction when such a condition > happens so this seem superfluous. > Ok, now I'm confused. I thought the problem was an "abort()" call for sparc64. I certainly run the code with the trap instruction in it and since it never gets executed, it doesn't bother me on i386. > > I agree with Bruce, but the check might be a good idea, in case a > > future code change introduces a bug where the function is called > > with > > new_lfpp NULL and NFSLCK_OPEN set. > > > > If this doesn't make the compiler happy, all I can suggest is to > > play around until you come up with something that works. > > KASSERT() doesnt communicate that it's an assert, because it can > just log into console a carry on. Would you be ok with this patch? > > Index: fs/nfsserver/nfs_nfsdstate.c > =================================================================== > --- fs/nfsserver/nfs_nfsdstate.c (revision 261037) > +++ fs/nfsserver/nfs_nfsdstate.c (working copy) > @@ -1384,7 +1384,8 @@ > * If we are doing Lock/LockU and local locking is enabled, > sleep > * lock the nfslockfile structure. > */ > - getlckret = nfsrv_getlockfh(vp, new_stp->ls_flags, NULL, > &nfh, p); > + KASSERT((new_stp->ls_flags & NFSLCK_OPEN) == 0, > ("nfsrv_lockctrl: calling nfsrv_getlockfh with NFSLCK_OPEN")); > + getlckret = nfsrv_getlockfh(vp, new_stp->ls_flags & > ~NFSLCK_OPEN, NULL, &nfh, p); > NFSLOCKSTATE(); > if (getlckret == 0) { > if ((new_stp->ls_flags & (NFSLCK_LOCK | > NFSLCK_UNLOCK)) != 0 && > > > > Have fun with it, rick > > ps: I haven't seen this reported by tinderbox. Is the problem > > specific to your setup? > Yea, so long as it includes a comment that states this is done to work around a stupid compiler bug. > It is present even in your setup :) Just "objdump -d kernel | grep > ud2" on kernel compiled > by clang. > I actually use gcc, but I believe you. I'll admit I still don't understand why having a trap instruction that never gets executed is a bad thing? I can commit the above in April. If for some reason the fix is needed sooner, we'll need to find someone else willing to do the commit. rick > Roman > From owner-freebsd-fs@FreeBSD.ORG Tue Jan 28 01:02:04 2014 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 961C6BC9; Tue, 28 Jan 2014 01:02:04 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 40AB5143A; Tue, 28 Jan 2014 01:02:03 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 0DFE11A3A01; Tue, 28 Jan 2014 12:01:54 +1100 (EST) Date: Tue, 28 Jan 2014 12:01:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem Subject: Re: BUG: possible NULL pointer dereference in nfs server In-Reply-To: <410866336.17211125.1390863857778.JavaMail.root@uoguelph.ca> Message-ID: <20140128112731.S1362@besplex.bde.org> References: <410866336.17211125.1390863857778.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=HZAtEE08 c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=vWCuAoM2T_8A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=vwpRgUSxFbAA:10 a=GqbB8SJ1b8qnInoI_ykA:9 a=CjuIK1q_8ugA:10 Cc: Roman Divacky , Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:02:04 -0000 On Mon, 27 Jan 2014, Rick Macklem wrote: > Roman Divacky wrote: >> On Sat, Jan 25, 2014 at 09:05:54PM -0500, Rick Macklem wrote: >>> Bruce Evans wrote: >>>> On Sat, 25 Jan 2014, Dimitry Andric wrote: >>>> >>>>> On 25 Jan 2014, at 01:38, Rick Macklem >>>>> wrote: >>>>> ... >>>>> If it inlines this, the result looks approximately like: >>>>> >>>>> 1 { >>>>> 2 fhandle_t *fhp = NULL; >>>>> 3 struct nfslockfile *new_lfp; >>>>> 4 int error; >>>>> 5 >>>>> 6 if (new_stp->ls_flags & NFSLCK_OPEN) { >>>>> 7 new_lfp = *NULL; >>>>> 8 fhp = &new_lfp->lf_fh; >>>>> 9 } else if (&nfh) { >>>>> 10 fhp = &nfh; >>>>> 11 } else { >>>>> 12 panic("nfsrv_getlockfh"); >>>>> 13 } >>>>> 14 error = nfsvno_getfh(vp, fhp, p); >>>>> 15 NFSEXITCODE(error); >>>>> 16 getlckret = error; >>>>> 17 } >>>>> >>>>> The code in line 7 is the problematic part. Since this is >>>>> undefined, >>>>> the compiler inserts a trap instruction here. I think the >>>>> problem >>>>> Roman >>>>> encountered is that on sparc64, there is no equivalent to x86's >>>>> ud2 >>>>> instruction, so it inserts a call to abort() instead, and that >>>>> function >>>>> is not available in kernel-land. >>>> >>>> Compiler bug. abort() is not available in freestanding >>>> implementations. >>>> The behaviour is only undefined if the null pointer is >>>> dereferenced >>>> at >>>> runtime, so it doesn't include failing to link to abort() at >>>> compile >>>> time. >>>> >>>>> ... >>>>>> Sorry, I'm not a compiler guy, so I don't know why a compiler >>>>>> would >>>>>> generate a trap instruction, but since new_lfpp is never NULL >>>>>> when >>>>>> this is executed, I don't see a problem. >>>>>> >>>>>> If others feel that this needs to be re-coded, please let me >>>>>> know >>>>>> what >>>>>> you think the code should look like? (A test for non-NULL with >>>>>> a >>>>>> panic() >>>>>> before it is used?) >>>>>> >>>>>> Is a trap instruction that never gets executed a problem? >>>>> >>>>> It's better to avoid undefined behavior in any case. Just add >>>>> a >>>>> NULL >>>>> check, that should be sufficient. >>>> >>>> That might only add bloat and unimprove debugging. Since the >>>> null >>>> pointer >>>> case cannot happen, it cannot be handed properly. It can be >>>> mishandled in >>>> the following ways: >>>> - return an error, so that all callers have to handle the null >>>> pointer case >>>> that can't happen. If the compiler is too smart, it will >>>> notice >>>> more >>>> undefined behaviour (that can't happen) in callers and "force" >>>> you >>>> to >>>> handle it there too >>>> - KASSERT() that the pointer cannot be null. Then: >>>> - on production systems where KASSERT() is null, this won't >>>> work >>>> around >>>> the compiler bug. Use a panic() instead. To maximize >>>> source >>>> code >>>> bloat, ifdef all of this. >>>> - when KASSERT() is not null, it will work around the compiler >>>> bug. >>>> If the case that can't happen actually happens, then this >>>> unimproves >>>> the debugging by messing up stack traces and turning >>>> restartable >>>> null pointer or SIGILL traps to non-restartable panics. >>>> Optimizations that replace a large block of code ending with >>>> a >>>> null pointer trap by a single unimplemented instruction >>>> would >>>> probably break restarting anyway. >>>> >>>> Bruce >>>> >>> So Roman, all I can suggest is to try adding something like: >>> if (new_lfpp == NULL) >>> panic("new_lfpp NULL"); >>> after line#6. If that makes the compiler happy, I can commit it in >>> April. (Can't do commits before then.) >> >> The compiler already inserts "trap" instruction when such a condition >> happens so this seem superfluous. >> > Ok, now I'm confused. I thought the problem was an "abort()" call for > sparc64. I certainly run the code with the trap instruction in it and > since it never gets executed, it doesn't bother me on i386. > >>> I agree with Bruce, but the check might be a good idea, in case a >>> future code change introduces a bug where the function is called >>> with >>> new_lfpp NULL and NFSLCK_OPEN set. >>> >>> If this doesn't make the compiler happy, all I can suggest is to >>> play around until you come up with something that works. >> >> KASSERT() doesnt communicate that it's an assert, because it can >> just log into console a carry on. Would you be ok with this patch? >> >> Index: fs/nfsserver/nfs_nfsdstate.c >> =================================================================== >> --- fs/nfsserver/nfs_nfsdstate.c (revision 261037) >> +++ fs/nfsserver/nfs_nfsdstate.c (working copy) >> @@ -1384,7 +1384,8 @@ >> * If we are doing Lock/LockU and local locking is enabled, >> sleep >> * lock the nfslockfile structure. >> */ >> - getlckret = nfsrv_getlockfh(vp, new_stp->ls_flags, NULL, >> &nfh, p); >> + KASSERT((new_stp->ls_flags & NFSLCK_OPEN) == 0, >> ("nfsrv_lockctrl: calling nfsrv_getlockfh with NFSLCK_OPEN")); >> + getlckret = nfsrv_getlockfh(vp, new_stp->ls_flags & >> ~NFSLCK_OPEN, NULL, &nfh, p); >> NFSLOCKSTATE(); >> if (getlckret == 0) { >> if ((new_stp->ls_flags & (NFSLCK_LOCK | >> NFSLCK_UNLOCK)) != 0 && >> >>> Have fun with it, rick >>> ps: I haven't seen this reported by tinderbox. Is the problem >>> specific to your setup? >> > Yea, so long as it includes a comment that states this is done to > work around a stupid compiler bug. Ugh. The above has the following bugs: - gross style bugs (lines longer than 80 characters) - large code to do nothing - would be even larger with a comment - cannot actually work around any compiler bug involving abort(), since it has no effect on production kernels where KASSERT() is null. >> It is present even in your setup :) Just "objdump -d kernel | grep >> ud2" on kernel compiled >> by clang. >> > I actually use gcc, but I believe you. I'll admit I still don't understand > why having a trap instruction that never gets executed is a bad thing? It isn't but trying to link to the noexistent function abort() on arches that don't have any trap instruction is a bad thing. According the above, this occurs on sparc64. It must be a gcc bug, since sparc64 doesn't have clang. However, I couldn't get gcc on sparc64 to generate an abort() for *NULL. Similarly on x86 (gcc is hard to test on x86, since it is broken (not installed) on FreeBSD cluster machines for newer versions of FreeBSD). clang on x86 warns that it removes *NULL, removes *NULL, and then sometimes but not always generares ud2 for reachable code following *NULL. For the following test code: % extern int flags; % % int % main(void) % { % if (flags & 1) % *(char *)1 = 0; % else { % *(char *)0 = 0; % *(char *)1 = 0; % } % } clang generates ud2 for the second *1, but if the second *1 is removed so that the code falls through to return, it doesn't generate ud2. -Werror should make the warning fatal, so it is surprising that everyone doesn't see this compiler bug. > I can commit the above in April. If for some reason the fix is needed sooner, > we'll need to find someone else willing to do the commit. Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Jan 28 09:40:47 2014 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D75BC9A5; Tue, 28 Jan 2014 09:40:47 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [95.129.96.251]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD411A6F; Tue, 28 Jan 2014 09:40:47 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id EFE491CC559F; Tue, 28 Jan 2014 10:40:45 +0100 (CET) Date: Tue, 28 Jan 2014 10:40:45 +0100 From: Roman Divacky To: Bruce Evans Subject: Re: BUG: possible NULL pointer dereference in nfs server Message-ID: <20140128094045.GB16311@freebsd.org> References: <410866336.17211125.1390863857778.JavaMail.root@uoguelph.ca> <20140128112731.S1362@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140128112731.S1362@besplex.bde.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:40:47 -0000 > > Yea, so long as it includes a comment that states this is done to > > work around a stupid compiler bug. > > Ugh. > > The above has the following bugs: > - gross style bugs (lines longer than 80 characters) > - large code to do nothing > - would be even larger with a comment > - cannot actually work around any compiler bug involving abort(), since it > has no effect on production kernels where KASSERT() is null. > > >> It is present even in your setup :) Just "objdump -d kernel | grep > >> ud2" on kernel compiled > >> by clang. > >> > > I actually use gcc, but I believe you. I'll admit I still don't understand > > why having a trap instruction that never gets executed is a bad thing? > > It isn't but trying to link to the noexistent function abort() on > arches that don't have any trap instruction is a bad thing. According > the above, this occurs on sparc64. It must be a gcc bug, since sparc64 > doesn't have clang. However, I couldn't get gcc on sparc64 to generate > an abort() for *NULL. Similarly on x86 (gcc is hard to test on x86, > since it is broken (not installed) on FreeBSD cluster machines for I was testing clang compiled kernel on sparc64. The problem is that there's nothing making sure that the NULL pointer dereference doesnt happen. So if someone happens to call the function with wrong flags it will crash. Thats why I want to add the KASSERT, to catch possible future cases when this happens. Unfortunately our KASSERT is not an assert so to remove the actual abort/trap/ud2 I have to remove the flag. Ok? Roman From owner-freebsd-fs@FreeBSD.ORG Tue Jan 28 15:37:33 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E47BE03 for ; Tue, 28 Jan 2014 15:37:33 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C64D1187F for ; Tue, 28 Jan 2014 15:37:32 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so474678lbv.24 for ; Tue, 28 Jan 2014 07:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=aT7NXe1LN6/gBkEBZHmQGR9/avJNTxzY4uumE1MTAT4=; b=ei5GcwY+CtgeMFOdOyXKa/oOBkXUvqDr9J53sEPnzCIPFE3XhHaXpi5VfSWbWomH5P ojupJjj5sRDgyNu2hxBkXzuw1+HL//cnAaLiSDNUaAeR+KLo5ZDNiYRf3jNHEnQ7Do7N 2u+dmrCf94uYhAFMTI6mq9QUOARumvXHktrgfKy/mpLDmoXOycbcCq/aq6KvXwLGQrHc ibyXu8YbVoxYCbvDpT5xLGT/chiJEPRTeD+KH/ypi1Xh9P7Qh1fHW+6GUjq5FN214INx v1JKd+lDi7u8K18UTfkebGTu8vs7QfNEJ6DeQHyUO3rgMuo27OzANpvFRfBfAo7L9B3+ J4/Q== X-Received: by 10.112.126.135 with SMTP id my7mr143074lbb.56.1390923450709; Tue, 28 Jan 2014 07:37:30 -0800 (PST) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id w2sm19192568lad.4.2014.01.28.07.37.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 07:37:29 -0800 (PST) Message-ID: <52E7CEB8.7010906@gmail.com> Date: Tue, 28 Jan 2014 17:37:28 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Nagy, Attila" , freebsd-fs@freebsd.org Subject: Re: Lot more swapping in stable/10 with ZFS References: <52E4DE17.3000206@fsn.hu> In-Reply-To: <52E4DE17.3000206@fsn.hu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 15:37:33 -0000 26.01.2014 12:06, Nagy, Attila wrote: > Hi, > > Running stable/10@r261157 (and earlier too), I've noticed that it swaps > much more than previous (stable/9) versions. > Current top output from such a machine: > Mem: 251M Active, 21M Inact, 7491M Wired, 118M Cache, 17M Buf, 51M Free > ARC: 5112M Total, 1455M MFU, 2155M MRU, 7761K Anon, 293M Header, 1223M > Other > Swap: 2045M Total, 757M Used, 1287M Free, 37% Inuse, 1280K Out Just a +1 from me: Mem: 1440M Active, 412M Inact, 5889M Wired, 82M Cache, 90M Free ARC: 3990M Total, 1981M MFU, 1505M MRU, 533K Anon, 79M Header, 424M Other Swap: 8192M Total, 1434M Used, 6758M Free, 17% Inuse This machine is up for 1+03:13:06 -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 28 16:34:13 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80AFBCA3 for ; Tue, 28 Jan 2014 16:34:13 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CC7D21EA0 for ; Tue, 28 Jan 2014 16:34:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA28554; Tue, 28 Jan 2014 18:34:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W8Bc1-000PAv-Bp; Tue, 28 Jan 2014 18:34:09 +0200 Message-ID: <52E7DBC9.6000708@FreeBSD.org> Date: Tue, 28 Jan 2014 18:33:13 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Volodymyr Kostyrko , "Nagy, Attila" , freebsd-fs@FreeBSD.org Subject: Re: Lot more swapping in stable/10 with ZFS References: <52E4DE17.3000206@fsn.hu> <52E7CEB8.7010906@gmail.com> In-Reply-To: <52E7CEB8.7010906@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:34:13 -0000 on 28/01/2014 17:37 Volodymyr Kostyrko said the following: > 26.01.2014 12:06, Nagy, Attila wrote: >> Hi, >> >> Running stable/10@r261157 (and earlier too), I've noticed that it swaps >> much more than previous (stable/9) versions. >> Current top output from such a machine: >> Mem: 251M Active, 21M Inact, 7491M Wired, 118M Cache, 17M Buf, 51M Free >> ARC: 5112M Total, 1455M MFU, 2155M MRU, 7761K Anon, 293M Header, 1223M >> Other >> Swap: 2045M Total, 757M Used, 1287M Free, 37% Inuse, 1280K Out > > Just a +1 from me: > > Mem: 1440M Active, 412M Inact, 5889M Wired, 82M Cache, 90M Free > ARC: 3990M Total, 1981M MFU, 1505M MRU, 533K Anon, 79M Header, 424M Other > Swap: 8192M Total, 1434M Used, 6758M Free, 17% Inuse > > This machine is up for 1+03:13:06 > Guys, could you please set sysctl vm.lowmem_period to zero (after a fresh reboot) and see if it makes any difference? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Jan 28 18:50:55 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACAA8D13 for ; Tue, 28 Jan 2014 18:50:55 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C1A41B12 for ; Tue, 28 Jan 2014 18:50:55 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id le5so495979vcb.2 for ; Tue, 28 Jan 2014 10:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=W9yfLQKBp4A85Qec//O+4q47zI/7D7NNEApUN4UlLng=; b=ew407oy0PyFTXbube7VVPJ2mPaL0QwAArRndQX/y1qG111y/f6bQ/xy724dmOgTmQN SyGQpdXqGxVmTsV3RMwWSJcjZBMjIonNmLg8vwFxmYh1fxOVKt8E6ilTkv/RM7WJSEC2 hWt9CJAERU1izq16gUldnYZuEolx9sP45rUZUXubLSOOMgqd332Qs8uXQtlGELfcmyxu 7qWJ0evNXBLGoL834c3QmafXLe+sP9Fkxo13EJ29exx5qOwCGCIkpl2ZBFlFMtTAI7cg CyUO4p8WZl+mYHn/zCuFs9SzHeGOj3JwdQqdHQgc0234m8/TIDJ86YktFWC6VReTPR7z +4Pw== X-Received: by 10.220.191.134 with SMTP id dm6mr2330673vcb.16.1390935054568; Tue, 28 Jan 2014 10:50:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.162.169 with HTTP; Tue, 28 Jan 2014 10:50:34 -0800 (PST) In-Reply-To: References: From: Anton Sayetsky Date: Tue, 28 Jan 2014 20:50:34 +0200 Message-ID: Subject: Re: ZFS and Wired memory, again To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:50:55 -0000 2013-11-22 Anton Sayetsky : > Hello, > > I'm planning to deploy a ~150 TiB ZFS pool and when playing with ZFS > noticed that amount of wired memory is MUCH bigger than ARC size (in > absence of other hungry memory consumers, of course). I'm afraid that > this strange behavior may become even worse on a machine with big pool > and some hundreds gibibytes of RAM. > > So let me explain what happened. > > Immediately after booting system top says the following: > ===== > Mem: 14M Active, 13M Inact, 117M Wired, 2947M Free > ARC: 24M Total, 5360K MFU, 18M MRU, 16K Anon, 328K Header, 1096K Other > ===== > Ok, wired mem - arc = 92 MiB > > Then I started to read pool (tar cpf /dev/null /). > Memory usage when ARC size is ~1GiB > ===== > Mem: 16M Active, 15M Inact, 1410M Wired, 1649M Free > ARC: 1114M Total, 29M MFU, 972M MRU, 21K Anon, 18M Header, 95M Other > ===== > 1410-1114=296 MiB > > Memory usage when ARC size reaches it's maximum of 2 GiB > ===== > Mem: 16M Active, 16M Inact, 2523M Wired, 536M Free > ARC: 2067M Total, 3255K MFU, 1821M MRU, 35K Anon, 38M Header, 204M Other > ===== > 2523-2067=456 MiB > > Memory usage a few minutes later > ===== > Mem: 10M Active, 27M Inact, 2721M Wired, 333M Free > ARC: 2002M Total, 22M MFU, 1655M MRU, 21K Anon, 36M Header, 289M Other > ===== > 2721-2002=719 MiB > > So why the wired ram on a machine with only minimal amount of services > has grown from 92 to 719 MiB? Sometimes I can even see about a gig! > I'm using 9.2-RELEASE-p1 amd64. Test machine has a T5450 C2D CPU and 4 > G RAM (actual available amount is 3 G). ZFS pool is configured on a > GPT partition of a single 1 TB HDD. > Disabling/enabling prefetch does't helps. Limiting ARC to 1 gig doesn't helps. > When reading a pool, evict skips can increment very fast and sometimes > arc metadata exceeds limit (2x-5x). > > I've attached logs with system configuration, outputs from top, ps, > zfs-stats and vmstat. > conf.log = system configuration, also uploaded to http://pastebin.com/NYBcJPeT > top_ps_zfs-stats_vmstat_afterboot = memory stats immediately after > booting system, http://pastebin.com/mudmEyG5 > top_ps_zfs-stats_vmstat_1g-arc = after ARC grown to 1 gig, > http://pastebin.com/4AC8dn5C > top_ps_zfs-stats_vmstat_fullmem = when ARC reached limit of 2 gigs, > http://pastebin.com/bx7svEP0 > top_ps_zfs-stats_vmstat_fullmem_2 = few minutes later, > http://pastebin.com/qYWFaNeA > > What should I do next? BUMP From owner-freebsd-fs@FreeBSD.ORG Tue Jan 28 22:36:52 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8317E81C; Tue, 28 Jan 2014 22:36:52 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 21057110B; Tue, 28 Jan 2014 22:36:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: X-IronPort-AV: E=Sophos;i="4.95,738,1384318800"; d="scan'208";a="91787121" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 28 Jan 2014 17:36:44 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3D523B3EEA; Tue, 28 Jan 2014 17:36:44 -0500 (EST) Date: Tue, 28 Jan 2014 17:36:44 -0500 (EST) From: Rick Macklem To: Roman Divacky Message-ID: <2013799744.17924450.1390948604241.JavaMail.root@uoguelph.ca> In-Reply-To: <20140128094045.GB16311@freebsd.org> Subject: Re: BUG: possible NULL pointer dereference in nfs server MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:36:52 -0000 Roman Divacky wrote: > > > Yea, so long as it includes a comment that states this is done to > > > work around a stupid compiler bug. > > > > Ugh. > > > > The above has the following bugs: > > - gross style bugs (lines longer than 80 characters) > > - large code to do nothing > > - would be even larger with a comment > > - cannot actually work around any compiler bug involving abort(), > > since it > > has no effect on production kernels where KASSERT() is null. > > > > >> It is present even in your setup :) Just "objdump -d kernel | > > >> grep > > >> ud2" on kernel compiled > > >> by clang. > > >> > > > I actually use gcc, but I believe you. I'll admit I still don't > > > understand > > > why having a trap instruction that never gets executed is a bad > > > thing? > > > > It isn't but trying to link to the noexistent function abort() on > > arches that don't have any trap instruction is a bad thing. > > According > > the above, this occurs on sparc64. It must be a gcc bug, since > > sparc64 > > doesn't have clang. However, I couldn't get gcc on sparc64 to > > generate > > an abort() for *NULL. Similarly on x86 (gcc is hard to test on > > x86, > > since it is broken (not installed) on FreeBSD cluster machines for > > I was testing clang compiled kernel on sparc64. > > The problem is that there's nothing making sure that the NULL pointer > dereference doesnt happen. So if someone happens to call the function > with > wrong flags it will crash. > > Thats why I want to add the KASSERT, to catch possible future cases > when this happens. > > Unfortunately our KASSERT is not an assert so to remove the actual > abort/trap/ud2 I have to remove the flag. > > > Ok? > If it makes clang for sparc64 happy, I suppose so. Another possible coding, which is maybe a little less ugly and might fix the problem is: change if (new_stp->ls_flags & NFSLCK_OPEN) { to if ((new_stp->ls_flags & NFSLCK_OPEN) != 0 && new_lfpp != NULL) { rick > > Roman > From owner-freebsd-fs@FreeBSD.ORG Wed Jan 29 07:16:37 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49785BF2; Wed, 29 Jan 2014 07:16:37 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F332188E; Wed, 29 Jan 2014 07:16:36 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 896151296176; Wed, 29 Jan 2014 08:16:26 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 9.7157] X-CRM114-CacheID: sfid-20140129_08162_030B1191 X-CRM114-Status: Good ( pR: 9.7157 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jan 29 08:16:26 2014 X-DSPAM-Confidence: 0.9954 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52e8aaca161916006519569 X-DSPAM-Factors: 27, and+>, 0.00155, wrote+>, 0.00186, >>+>, 0.00264, From*"Nagy, Attila" , 0.00264, >+>, 0.00319, >>>+>>>, 0.00330, References*gmail.com>, 0.00340, >>+>>, 0.00364, >>+>>, 0.00364, grep, 0.00406, wrote+>>>, 0.00439, noticed+that, 0.00439, Subject*ZFS, 0.00479, References*FreeBSD.org>, 0.00479, To*FreeBSD.org>, 0.00479, wrote, 0.00514, wrote, 0.00514, Cache, 0.00527, Cache, 0.00527, References*fsn.hu>, 0.00554, sysctl, 0.00585, sysctl, 0.00585, Nagy+Attila, 0.00585, Received*online.co.hu+[195.228.243.99]), 0.00657, >+on, 0.00657, Received*[195.228.243.99]), 0.00657, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 9B2831296165; Wed, 29 Jan 2014 08:16:23 +0100 (CET) Message-ID: <52E8AAC3.3040300@fsn.hu> Date: Wed, 29 Jan 2014 08:16:19 +0100 From: "Nagy, Attila" MIME-Version: 1.0 To: Andriy Gapon , Volodymyr Kostyrko , freebsd-fs@FreeBSD.org Subject: Re: Lot more swapping in stable/10 with ZFS References: <52E4DE17.3000206@fsn.hu> <52E7CEB8.7010906@gmail.com> <52E7DBC9.6000708@FreeBSD.org> In-Reply-To: <52E7DBC9.6000708@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 07:16:37 -0000 On 01/28/14 17:33, Andriy Gapon wrote: > on 28/01/2014 17:37 Volodymyr Kostyrko said the following: >> 26.01.2014 12:06, Nagy, Attila wrote: >>> Hi, >>> >>> Running stable/10@r261157 (and earlier too), I've noticed that it swaps >>> much more than previous (stable/9) versions. >>> Current top output from such a machine: >>> Mem: 251M Active, 21M Inact, 7491M Wired, 118M Cache, 17M Buf, 51M Free >>> ARC: 5112M Total, 1455M MFU, 2155M MRU, 7761K Anon, 293M Header, 1223M >>> Other >>> Swap: 2045M Total, 757M Used, 1287M Free, 37% Inuse, 1280K Out >> Just a +1 from me: >> >> Mem: 1440M Active, 412M Inact, 5889M Wired, 82M Cache, 90M Free >> ARC: 3990M Total, 1981M MFU, 1505M MRU, 533K Anon, 79M Header, 424M Other >> Swap: 8192M Total, 1434M Used, 6758M Free, 17% Inuse >> >> This machine is up for 1+03:13:06 >> > Guys, > > could you please set sysctl vm.lowmem_period to zero (after a fresh reboot) and > see if it makes any difference? > # sysctl -a | grep lowmem_period vm.lowmem_period: 0 (set from sysctl.conf) # uptime 8:15AM up 1:05, 1 user, load averages: 0.25, 0.29, 0.30 Mem: 468M Active, 127M Inact, 7168M Wired, 54M Cache, 16M Buf, 115M Free ARC: 5835M Total, 4364M MFU, 789M MRU, 16K Anon, 150M Header, 536M Other Swap: 2045M Total, 62M Used, 1983M Free, 3% Inuse, 1816K Out So not really. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 29 09:28:40 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92AC1A70 for ; Wed, 29 Jan 2014 09:28:40 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4020F1369 for ; Wed, 29 Jan 2014 09:28:40 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id id10so1018825vcb.27 for ; Wed, 29 Jan 2014 01:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j3tPSbzX3cwj4cZ7WL5dSZorz/RQBUmt/MhHDPMPXJM=; b=vDXOb8L8j3jewCJNyocLmRj7mvI5yY+27+l5/WiTxzBSqQHpyydaxTw0z+OWVJPt93 suAruzLPqaj3oeTZzX7wZkXLOaiUmxGdsbheA8n7CWJ0/wp3q3GrtyvbDkes9pGxio1l kn853y3zIxL797sjhmz5ZTjUsCRFamNKO2Ot8Kfq3jdW6zF5cpHfIjHoA30lW7fyb+vw 3qVoW+2LTtmPGuGnctLf+AZ7TITTciE+14Ld3m2arXjvcR5qAH2syPWSGMJvdRtwpiiQ 12ayMiNQnTG25Q8c94QhQjcyOBhEHUB8TgGSiSSbb6XDXOZbTg1DJdfAzQA7WrBzq7c3 2Sqw== X-Received: by 10.221.34.211 with SMTP id st19mr5732775vcb.5.1390987719243; Wed, 29 Jan 2014 01:28:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.59.0.68 with HTTP; Wed, 29 Jan 2014 01:28:09 -0800 (PST) In-Reply-To: References: From: Matthias Gamsjager Date: Wed, 29 Jan 2014 10:28:09 +0100 Message-ID: Subject: Re: ZFS and Wired memory, again To: Anton Sayetsky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 09:28:40 -0000 I remember reading something similar couple of days ago but can't find the thread. On Tue, Jan 28, 2014 at 7:50 PM, Anton Sayetsky wrote: > 2013-11-22 Anton Sayetsky : > > Hello, > > > > I'm planning to deploy a ~150 TiB ZFS pool and when playing with ZFS > > noticed that amount of wired memory is MUCH bigger than ARC size (in > > absence of other hungry memory consumers, of course). I'm afraid that > > this strange behavior may become even worse on a machine with big pool > > and some hundreds gibibytes of RAM. > > > > So let me explain what happened. > > > > Immediately after booting system top says the following: > > ===== > > Mem: 14M Active, 13M Inact, 117M Wired, 2947M Free > > ARC: 24M Total, 5360K MFU, 18M MRU, 16K Anon, 328K Header, 1096K Other > > ===== > > Ok, wired mem - arc = 92 MiB > > > > Then I started to read pool (tar cpf /dev/null /). > > Memory usage when ARC size is ~1GiB > > ===== > > Mem: 16M Active, 15M Inact, 1410M Wired, 1649M Free > > ARC: 1114M Total, 29M MFU, 972M MRU, 21K Anon, 18M Header, 95M Other > > ===== > > 1410-1114=296 MiB > > > > Memory usage when ARC size reaches it's maximum of 2 GiB > > ===== > > Mem: 16M Active, 16M Inact, 2523M Wired, 536M Free > > ARC: 2067M Total, 3255K MFU, 1821M MRU, 35K Anon, 38M Header, 204M Other > > ===== > > 2523-2067=456 MiB > > > > Memory usage a few minutes later > > ===== > > Mem: 10M Active, 27M Inact, 2721M Wired, 333M Free > > ARC: 2002M Total, 22M MFU, 1655M MRU, 21K Anon, 36M Header, 289M Other > > ===== > > 2721-2002=719 MiB > > > > So why the wired ram on a machine with only minimal amount of services > > has grown from 92 to 719 MiB? Sometimes I can even see about a gig! > > I'm using 9.2-RELEASE-p1 amd64. Test machine has a T5450 C2D CPU and 4 > > G RAM (actual available amount is 3 G). ZFS pool is configured on a > > GPT partition of a single 1 TB HDD. > > Disabling/enabling prefetch does't helps. Limiting ARC to 1 gig doesn't > helps. > > When reading a pool, evict skips can increment very fast and sometimes > > arc metadata exceeds limit (2x-5x). > > > > I've attached logs with system configuration, outputs from top, ps, > > zfs-stats and vmstat. > > conf.log = system configuration, also uploaded to > http://pastebin.com/NYBcJPeT > > top_ps_zfs-stats_vmstat_afterboot = memory stats immediately after > > booting system, http://pastebin.com/mudmEyG5 > > top_ps_zfs-stats_vmstat_1g-arc = after ARC grown to 1 gig, > > http://pastebin.com/4AC8dn5C > > top_ps_zfs-stats_vmstat_fullmem = when ARC reached limit of 2 gigs, > > http://pastebin.com/bx7svEP0 > > top_ps_zfs-stats_vmstat_fullmem_2 = few minutes later, > > http://pastebin.com/qYWFaNeA > > > > What should I do next? > BUMP > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Wed Jan 29 09:31:11 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0330BB61 for ; Wed, 29 Jan 2014 09:31:11 +0000 (UTC) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B16ED13E6 for ; Wed, 29 Jan 2014 09:31:10 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id x14so960029vbb.22 for ; Wed, 29 Jan 2014 01:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mV3UGSGKhowQwXry4Xsw83FRRFKKGHYPzXW21E9hajo=; b=0r/giFqIRzVJWeCwr6cDVp8zQDZD5UYZo+7Lp05uTvWUWK8RoufS5S3sKVArNbI4Jw BGJOwVIOMuFne++iYVnPMlVPjTNriEAj79pQc9ti1cfn/PqSsACOLc1elaWw81hSibJr TYOMAKBgpPI5H/Mfceu6MrEFxBTMQmBTpFPzOs4PbD78THQmnaI/bBB3rxQAKYljnpAt fZocBy2SgIp7mS6XjNmcKuaAIr1VJPpySkrwDZulKNe8RVpUWCFu67LBP2zV0P09q3ZA 3F98uXBtqpLd/VXanvNMBwPW33moW07OziJYPRWKwYG9aqLt0CeMhpRZKQ2REstipJk0 2MrQ== X-Received: by 10.52.164.39 with SMTP id yn7mr1328408vdb.25.1390987869798; Wed, 29 Jan 2014 01:31:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.59.0.68 with HTTP; Wed, 29 Jan 2014 01:30:39 -0800 (PST) In-Reply-To: References: From: Matthias Gamsjager Date: Wed, 29 Jan 2014 10:30:39 +0100 Message-ID: Subject: Re: ZFS and Wired memory, again To: Anton Sayetsky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 09:31:11 -0000 Found it. in the Freebsd Current list with subject ARC "pressured out", how to control/stabilize looks kinda alike On Wed, Jan 29, 2014 at 10:28 AM, Matthias Gamsjager wrote: > I remember reading something similar couple of days ago but can't find the > thread. > > > On Tue, Jan 28, 2014 at 7:50 PM, Anton Sayetsky wrote: > >> 2013-11-22 Anton Sayetsky : >> > Hello, >> > >> > I'm planning to deploy a ~150 TiB ZFS pool and when playing with ZFS >> > noticed that amount of wired memory is MUCH bigger than ARC size (in >> > absence of other hungry memory consumers, of course). I'm afraid that >> > this strange behavior may become even worse on a machine with big pool >> > and some hundreds gibibytes of RAM. >> > >> > So let me explain what happened. >> > >> > Immediately after booting system top says the following: >> > ===== >> > Mem: 14M Active, 13M Inact, 117M Wired, 2947M Free >> > ARC: 24M Total, 5360K MFU, 18M MRU, 16K Anon, 328K Header, 1096K Other >> > ===== >> > Ok, wired mem - arc = 92 MiB >> > >> > Then I started to read pool (tar cpf /dev/null /). >> > Memory usage when ARC size is ~1GiB >> > ===== >> > Mem: 16M Active, 15M Inact, 1410M Wired, 1649M Free >> > ARC: 1114M Total, 29M MFU, 972M MRU, 21K Anon, 18M Header, 95M Other >> > ===== >> > 1410-1114=296 MiB >> > >> > Memory usage when ARC size reaches it's maximum of 2 GiB >> > ===== >> > Mem: 16M Active, 16M Inact, 2523M Wired, 536M Free >> > ARC: 2067M Total, 3255K MFU, 1821M MRU, 35K Anon, 38M Header, 204M Other >> > ===== >> > 2523-2067=456 MiB >> > >> > Memory usage a few minutes later >> > ===== >> > Mem: 10M Active, 27M Inact, 2721M Wired, 333M Free >> > ARC: 2002M Total, 22M MFU, 1655M MRU, 21K Anon, 36M Header, 289M Other >> > ===== >> > 2721-2002=719 MiB >> > >> > So why the wired ram on a machine with only minimal amount of services >> > has grown from 92 to 719 MiB? Sometimes I can even see about a gig! >> > I'm using 9.2-RELEASE-p1 amd64. Test machine has a T5450 C2D CPU and 4 >> > G RAM (actual available amount is 3 G). ZFS pool is configured on a >> > GPT partition of a single 1 TB HDD. >> > Disabling/enabling prefetch does't helps. Limiting ARC to 1 gig doesn't >> helps. >> > When reading a pool, evict skips can increment very fast and sometimes >> > arc metadata exceeds limit (2x-5x). >> > >> > I've attached logs with system configuration, outputs from top, ps, >> > zfs-stats and vmstat. >> > conf.log = system configuration, also uploaded to >> http://pastebin.com/NYBcJPeT >> > top_ps_zfs-stats_vmstat_afterboot = memory stats immediately after >> > booting system, http://pastebin.com/mudmEyG5 >> > top_ps_zfs-stats_vmstat_1g-arc = after ARC grown to 1 gig, >> > http://pastebin.com/4AC8dn5C >> > top_ps_zfs-stats_vmstat_fullmem = when ARC reached limit of 2 gigs, >> > http://pastebin.com/bx7svEP0 >> > top_ps_zfs-stats_vmstat_fullmem_2 = few minutes later, >> > http://pastebin.com/qYWFaNeA >> > >> > What should I do next? >> BUMP >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > > From owner-freebsd-fs@FreeBSD.ORG Wed Jan 29 10:29:07 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F1299BA; Wed, 29 Jan 2014 10:29:07 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BAB381839; Wed, 29 Jan 2014 10:29:06 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id u14so1294509lbd.37 for ; Wed, 29 Jan 2014 02:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cS0ZswnjvnoV8W+7sFPqsDygJIva6DgtxRb1hm6V9A8=; b=X0LW1QVwud8XCmZKUfD3uAY0oNcq1rv1PRuFwA+K+lhS/TckuXKlp7qjkpE81KpEg/ Gog+h9krxuUfzwzCUbPOGki/8ey9Z2fTC5j6BRp79298XeY48xSgWQQyoNoBGht0/W9R 49U178CgeqKF54M9DeFZMje+Urw6QinvAXDq+CgM56VGUV/WB1R97G0dJyx5oqdYqkxR 0fTZV0yAcZokRvuJfhh6li4c5XMJFSH94V2S26zuG0nQzT0y2xcP45rEsOxfscixMzsC rv1krPDTTaPvoRLCfrVUhKxEfIR8WousLwAKgNFPYGcLpp4svZ8kh7UBkeCK3k85gZNb OxfA== X-Received: by 10.152.22.1 with SMTP id z1mr694604lae.39.1390991344744; Wed, 29 Jan 2014 02:29:04 -0800 (PST) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id g8sm2830951lae.1.2014.01.29.02.29.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 02:29:04 -0800 (PST) Message-ID: <52E8D7E3.9040200@gmail.com> Date: Wed, 29 Jan 2014 12:28:51 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Nagy, Attila" , Andriy Gapon , freebsd-fs@FreeBSD.org Subject: Re: Lot more swapping in stable/10 with ZFS References: <52E4DE17.3000206@fsn.hu> <52E7CEB8.7010906@gmail.com> <52E7DBC9.6000708@FreeBSD.org> <52E8AAC3.3040300@fsn.hu> In-Reply-To: <52E8AAC3.3040300@fsn.hu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 10:29:07 -0000 29.01.2014 09:16, Nagy, Attila написав(ла): > On 01/28/14 17:33, Andriy Gapon wrote: >> on 28/01/2014 17:37 Volodymyr Kostyrko said the following: >>> 26.01.2014 12:06, Nagy, Attila wrote: >>>> Hi, >>>> >>>> Running stable/10@r261157 (and earlier too), I've noticed that it swaps >>>> much more than previous (stable/9) versions. >>>> Current top output from such a machine: >>>> Mem: 251M Active, 21M Inact, 7491M Wired, 118M Cache, 17M Buf, 51M Free >>>> ARC: 5112M Total, 1455M MFU, 2155M MRU, 7761K Anon, 293M Header, 1223M >>>> Other >>>> Swap: 2045M Total, 757M Used, 1287M Free, 37% Inuse, 1280K Out >>> Just a +1 from me: >>> >>> Mem: 1440M Active, 412M Inact, 5889M Wired, 82M Cache, 90M Free >>> ARC: 3990M Total, 1981M MFU, 1505M MRU, 533K Anon, 79M Header, 424M >>> Other >>> Swap: 8192M Total, 1434M Used, 6758M Free, 17% Inuse >>> >>> This machine is up for 1+03:13:06 >>> >> Guys, >> >> could you please set sysctl vm.lowmem_period to zero (after a fresh >> reboot) and >> see if it makes any difference? >> > # sysctl -a | grep lowmem_period > vm.lowmem_period: 0 > (set from sysctl.conf) > # uptime > 8:15AM up 1:05, 1 user, load averages: 0.25, 0.29, 0.30 > Mem: 468M Active, 127M Inact, 7168M Wired, 54M Cache, 16M Buf, 115M Free > ARC: 5835M Total, 4364M MFU, 789M MRU, 16K Anon, 150M Header, 536M Other > Swap: 2045M Total, 62M Used, 1983M Free, 3% Inuse, 1816K Out > > So not really. I'll rather wait for a couple of days of run time as my load includes heavy disk usage at night and running a couple of VM's (VirtualBox) during a day. Probably VirtualBox is the root cause of high swap size because when starting/restoring a VM it allocates a lot of memory during a very short time period. -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 29 10:38:00 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BBE8C1F for ; Wed, 29 Jan 2014 10:38:00 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9736A18D9 for ; Wed, 29 Jan 2014 10:37:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA19176; Wed, 29 Jan 2014 12:37:55 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W8SWp-0003LV-Ef; Wed, 29 Jan 2014 12:37:55 +0200 Message-ID: <52E8D9C5.6020702@FreeBSD.org> Date: Wed, 29 Jan 2014 12:36:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Volodymyr Kostyrko , "Nagy, Attila" , freebsd-fs@FreeBSD.org Subject: Re: Lot more swapping in stable/10 with ZFS References: <52E4DE17.3000206@fsn.hu> <52E7CEB8.7010906@gmail.com> <52E7DBC9.6000708@FreeBSD.org> <52E8AAC3.3040300@fsn.hu> <52E8D7E3.9040200@gmail.com> In-Reply-To: <52E8D7E3.9040200@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 10:38:00 -0000 on 29/01/2014 12:28 Volodymyr Kostyrko said the following: > I'll rather wait for a couple of days of run time as my load includes heavy disk > usage at night and running a couple of VM's (VirtualBox) during a day. Probably > VirtualBox is the root cause of high swap size because when starting/restoring a > VM it allocates a lot of memory during a very short time period. [This is offtopic for this list...] VirtualBox could be a reason, but it is not to blame, IMO. VirtualBox needs to allocate some amount of contiguous physical memory. It's really not too much (2MB or 4MB), but if there is no suitable free chunk, then FreeBSD could end up cleaning _all_ inactive memory and much less likely all active memory. For file backed pages it means that file/page cache is purged, but all malloc-ed memory would go to swap. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 11:20:39 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64E87568 for ; Fri, 31 Jan 2014 11:20:39 +0000 (UTC) Received: from mail.crucible.gr (static.106.97.76.144.clients.your-server.de [144.76.97.106]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E219C1558 for ; Fri, 31 Jan 2014 11:20:37 +0000 (UTC) Received: from mail.crucible.gr (unknown [10.0.0.106]) by mail.crucible.gr (Postfix) with ESMTP id 2D70D3766 for ; Fri, 31 Jan 2014 13:11:51 +0200 (EET) Received: by mail.crucible.gr (Postfix, from userid 58) id 1212F3765; Fri, 31 Jan 2014 13:11:51 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.datalive.gr X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=ham version=3.3.2 Received: from Macintosh.local (unknown [2.84.133.157]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: anastasiadis@datalive.gr) by mail.crucible.gr (Postfix) with ESMTPSA id B0A26375E for ; Fri, 31 Jan 2014 13:11:47 +0200 (EET) Message-ID: <52EB84F3.50602@datalive.gr> Date: Fri, 31 Jan 2014 13:11:47 +0200 From: Antonis Anastasiadis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: ZFS - Uncompress raw LZ4 data X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 11:20:39 -0000 Hi everyone, I'm trying to recover a deleted file from a single disk LZ4 compressed dataset. The pool is in fine condition. I tried printing the uberblock history via zdb, but the file had been deleted before the oldest uberblock I could find. So I guess I can't roll back into that pool state. The file was very small (90-120 kb) so it should fit in a single ZFS block. I do not know the deleted block's DVA in order to restore it via zdb -R. But I have similar files on the disk, so I can get the file header. As a last resort, I'm thinking going brute force and somehow find all ZFS blocks (even deleted ones) from the raw partition, decompress the data and check the binary data for the file header. Is there a tool that decompresses raw LZ4 data out there? Max Bruning has written a utility called "zuncompress" but it doesn't support LZ4 (http://mbruning.blogspot.gr/2009/12/zfs-raidz-data-walk.html) I know 'm shooting in the dark here, but I would appreciate any other ideas from the ZFS gurus out there. Thanks, Antonis Anastasiadis From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 13:41:14 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9289C29; Fri, 31 Jan 2014 13:41:14 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79B701207; Fri, 31 Jan 2014 13:41:14 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id f11so6207016qae.7 for ; Fri, 31 Jan 2014 05:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=kkYTF1LJq2m9Gpb9EGlqyeWvYWaEcrWd2U4gEAilAHw=; b=ouFsnG5VKxam/YnmeKJRMukr4QwnB933MmQauvpBFQ7k6WfTM7IpAh3YZicrjdJf5Z SMcqTEIwpwrAnHvQEPvagUfAcUhorcAKLU9KSW2pBfOvU8/Fm69qCRu9Ko8osWt0pP65 NluR9FjQceG0j2fWW/VqNRgNYvNeIx5KA1uhvu+XlqJRmf8JWwDOdyuKmW75qOsXXvjV y3Zo/kI8F7VthoDu2LtD0euIB9QjDAz4q57MN6KCQwE4QSr5dm1ZUFGe7ffJFUZjiJEv TB6ToP18pKg2HszewZ0Jo5agogtsl/5E/W5ZwsjQDY6qjAnbJN3m7l8ombHa+rCxaNwK qvoA== MIME-Version: 1.0 X-Received: by 10.224.2.6 with SMTP id 6mr32086036qah.12.1391175673294; Fri, 31 Jan 2014 05:41:13 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.229.151.73 with HTTP; Fri, 31 Jan 2014 05:41:13 -0800 (PST) Date: Fri, 31 Jan 2014 14:41:13 +0100 X-Google-Sender-Auth: KHPwa0F4eSGqksUN_xxhu6qkiME Message-ID: Subject: UFS(2) portable driver for other OS From: CeDeROM To: FreeBSD Questions Mailing List , freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 13:41:14 -0000 Hello :-) Some time ago I have definitely moved from EXT2 to UFS2. This greatly improved my speed and stability on FreeBSD, but I somehow lost access and portability for other OS in "native" read-write mode. I am looking for an universal fs driver for other OS mainly Linux and Windows that would allow me to use UFS(2) natively (such as ext2fsd). I am sure there is already such solution, as fs standard is open and BSD licensed, so other OS would surely benefit from that support/driver :-) Please advise :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 14:07:05 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 792CD10F for ; Fri, 31 Jan 2014 14:07:05 +0000 (UTC) Received: from mailrelay4.qsc.de (mailrelay4.qsc.de [195.158.160.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB4FE139C for ; Fri, 31 Jan 2014 14:07:03 +0000 (UTC) Received: from mx01.qsc.de ([213.148.129.14]) by mailgate4.qsc.de; Fri, 31 Jan 2014 15:06:28 +0100 Received: from r56.edvax.de (port-92-195-45-52.dynamic.qsc.de [92.195.45.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id C5B353C0AC; Fri, 31 Jan 2014 15:06:26 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id s0VE61Lm002778; Fri, 31 Jan 2014 15:06:01 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Fri, 31 Jan 2014 15:06:01 +0100 From: Polytropon To: CeDeROM Subject: Re: UFS(2) portable driver for other OS Message-Id: <20140131150601.53ee40f4.freebsd@edvax.de> In-Reply-To: References: Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-cloud-security-sender: freebsd@edvax.de X-cloud-security-recipient: freebsd-fs@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mailgate4 with CA8EB1490004 X-cloud-security-connect: mx01.qsc.de[213.148.129.14], TLS=, IP=213.148.129.14 X-cloud-security: scantime:.1962 Cc: freebsd-fs@freebsd.org, FreeBSD Questions Mailing List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Polytropon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:07:05 -0000 On Fri, 31 Jan 2014 14:41:13 +0100, CeDeROM wrote: > Hello :-) > > Some time ago I have definitely moved from EXT2 to UFS2. This greatly > improved my speed and stability on FreeBSD, but I somehow lost access > and portability for other OS in "native" read-write mode. The lowest common denominator is msdosfs (DOS FAT) which is usable in r/w nearly everywhere. If you require long file names, you need the 16 bit version. This is commonly considered the "typical solution" for the problem you're describing, even though it doesn't really look any attractive because, as I said, it's the _lowest_ common denominator where "lowest" is determined by the inability of "Windows" products to be willing to accept anything that isn't made, approved, certified and sold by MICROS~1. :-) > I am looking > for an universal fs driver for other OS mainly Linux and Windows that > would allow me to use UFS(2) natively (such as ext2fsd). The _most universal_ file system isn't even a file system. Instead, it's tar. Yes, really: "tar-formatted" media can be read almost everywhere (DOS, IRIX, Solaris, BSD, Linux, AIX etc.). Everything you need is a tar implementation on the target system. It works with almost all media (floppy disks, CD, DVD, USB drives, SD cards, even hard disks). The major downside is that it isn't really a file system. It's good for transfer from A to B, but not for adding, changing or removing files... > I am sure > there is already such solution, as fs standard is open and BSD > licensed, so other OS would surely benefit from that support/driver > :-) No, something like that doesn't exist because nobody cares about interoperability of data. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 14:53:52 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 268C6AE5; Fri, 31 Jan 2014 14:53:52 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C89BE1767; Fri, 31 Jan 2014 14:53:51 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id o15so6445682qap.30 for ; Fri, 31 Jan 2014 06:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rxC3DQmVEF7cxdCZW90QDMbZXKy0QJcmy/PN70q9X/8=; b=xMpQxtir2VHhwl9dnUDD6Q2ga5vxii42SXDBhlDhSeyGQ16tYDH5VTGKx9lEwj1hqJ bUHx79/FzKI1/3QHctIWEAyKLvaKet4yrMoN63apYLJ4jNyZkwUaLdR+oFgeN4081bfX +Ja9J2XDDo1L2nDqXjI5vVVytLUIdCPOk+K0cjiJSV/Ydu8C5a/LC08A3AyPjWtKPxlr leOCsJJp9so0wQuxzKQhRjfewGsZhxK4+dkY9NEBqLlNV0/WRVyV/r/byHqIeeYHWSFU Apu13nwHDGwwvT15RJDkJMP2WTsl9ahFP6pomX1ohl3SWnyrArQtWj+zB1ERQ70GwVsz B/pw== MIME-Version: 1.0 X-Received: by 10.140.83.112 with SMTP id i103mr30634914qgd.100.1391180030865; Fri, 31 Jan 2014 06:53:50 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.229.151.73 with HTTP; Fri, 31 Jan 2014 06:53:50 -0800 (PST) In-Reply-To: <20140131150601.53ee40f4.freebsd@edvax.de> References: <20140131150601.53ee40f4.freebsd@edvax.de> Date: Fri, 31 Jan 2014 15:53:50 +0100 X-Google-Sender-Auth: VqWfuBzxEzQSK2LCMc2fq8KyGCo Message-ID: Subject: Re: UFS(2) portable driver for other OS From: CeDeROM To: Polytropon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, FreeBSD Questions Mailing List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:53:52 -0000 On Fri, Jan 31, 2014 at 3:06 PM, Polytropon wrote: > On Fri, 31 Jan 2014 14:41:13 +0100, CeDeROM wrote: >> Hello :-) >> >> Some time ago I have definitely moved from EXT2 to UFS2. This greatly >> improved my speed and stability on FreeBSD, but I somehow lost access >> and portability for other OS in "native" read-write mode. > > The lowest common denominator is msdosfs (DOS FAT) which is > usable in r/w nearly everywhere. If you require long file > names, you need the 16 bit version. Hey Polytropon :-) I need large files over 4GB and some existing access riight not to be modified so FAT does not apply, also extFAT is patented so I wont give it even a try... > The _most universal_ file system isn't even a file system. > Instead, it's tar. Yes, really: "tar-formatted" media can > (..) > It's good for transfer from A to B, but not for adding, > changing or removing files... For archives maybe yes, but I need it as live r/w filesystem, just like I used EXT2 - lets say three small OS partitions and one large data partition on the workstation :-) >> I am sure >> there is already such solution, as fs standard is open and BSD >> licensed, so other OS would surely benefit from that support/driver >> :-) > > No, something like that doesn't exist because nobody cares > about interoperability of data. :-) How about UFS2 driver for other OS? Is UFS2 endianness sensitive? Even if, on one machine that would not be the problem :-) Did anyone implement public UFS2 driver for other OS (Windows, Linux)? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 15:13:22 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30CF1463 for ; Fri, 31 Jan 2014 15:13:22 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2B781956 for ; Fri, 31 Jan 2014 15:13:21 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W9FmM-0003cC-33 for freebsd-fs@freebsd.org; Fri, 31 Jan 2014 16:13:14 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: UFS(2) portable driver for other OS References: <20140131150601.53ee40f4.freebsd@edvax.de> Date: Fri, 31 Jan 2014 16:13:08 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 X-Scan-Signature: 448baf4759cd3283a5930955cc61e1db X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 15:13:22 -0000 On Fri, 31 Jan 2014 15:53:50 +0100, CeDeROM wrote: > On Fri, Jan 31, 2014 at 3:06 PM, Polytropon wrote: >> On Fri, 31 Jan 2014 14:41:13 +0100, CeDeROM wrote: >>> Hello :-) >>> >>> Some time ago I have definitely moved from EXT2 to UFS2. This greatly >>> improved my speed and stability on FreeBSD, but I somehow lost access >>> and portability for other OS in "native" read-write mode. >> >> The lowest common denominator is msdosfs (DOS FAT) which is >> usable in r/w nearly everywhere. If you require long file >> names, you need the 16 bit version. > > Hey Polytropon :-) I need large files over 4GB and some existing > access riight not to be modified so FAT does not apply, also extFAT is > patented so I wont give it even a try... > > >> The _most universal_ file system isn't even a file system. >> Instead, it's tar. Yes, really: "tar-formatted" media can >> (..) >> It's good for transfer from A to B, but not for adding, >> changing or removing files... > > For archives maybe yes, but I need it as live r/w filesystem, just > like I used EXT2 - lets say three small OS partitions and one large > data partition on the workstation :-) > >>> I am sure >>> there is already such solution, as fs standard is open and BSD >>> licensed, so other OS would surely benefit from that support/driver >>> :-) >> >> No, something like that doesn't exist because nobody cares >> about interoperability of data. :-) > > How about UFS2 driver for other OS? Is UFS2 endianness sensitive? Even > if, on one machine that would not be the problem :-) > > Did anyone implement public UFS2 driver for other OS (Windows, Linux)? > > Best regards :-) > Tomek > https://www.google.nl/search?q=ufs2+windows There are: ufs2tools - UFS for Windows and talk about: FFS File System Driver for Windows Never used it myself. Maybe NTFS using FUSE is not so bad nowadays. But the most easy (compatible) and stable solution might be a fileserver sharing the data over Samba or NFS. Ronald. From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 17:20:39 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D6FD68A; Fri, 31 Jan 2014 17:20:39 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06437159C; Fri, 31 Jan 2014 17:20:38 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id i7so5465792oag.22 for ; Fri, 31 Jan 2014 09:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dduCv0WQQWnnDAIK0dAeq753ajmJE/SgCs/vIGSbrIw=; b=Gsn6LuH8GJ34BBJRY8+3LOEj0/MFFCi8gm6MMYPjo4uz38fPCmvbFnIjxA341GYa/C Mgi+NNGc5hKuwZ7s7lRzrlqGfpBnkEFEonrHfDUAbgnITcTluCS2+h1zV0Rb/TZWxvhK +leP+TgefybU6Z9JoGtPxrfJ9+OLx1NtQzEX+ZVD8j4zJoHDygumvk1O9MOycnaInUXH MxGG3oCsPN0KhjycmvTwXta+yhR1g+GLdlwLzmIrLNTylfhgruSP2v0avmRDAyZDbke7 mUlwqLch9UGJ3Ycc8FzcizthJ1ZJLG6Nt6qjhhxtrltbNjLmZwQKdKiUDLfvFHQMWbCr G0KA== MIME-Version: 1.0 X-Received: by 10.182.18.102 with SMTP id v6mr1557707obd.71.1391188838278; Fri, 31 Jan 2014 09:20:38 -0800 (PST) Received: by 10.76.132.9 with HTTP; Fri, 31 Jan 2014 09:20:38 -0800 (PST) In-Reply-To: <20140131150601.53ee40f4.freebsd@edvax.de> References: <20140131150601.53ee40f4.freebsd@edvax.de> Date: Fri, 31 Jan 2014 09:20:38 -0800 Message-ID: Subject: Re: UFS(2) portable driver for other OS From: Freddie Cash To: Polytropon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Filesystems , FreeBSD Questions Mailing List , CeDeROM X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:20:39 -0000 On Fri, Jan 31, 2014 at 6:06 AM, Polytropon wrote: > On Fri, 31 Jan 2014 14:41:13 +0100, CeDeROM wrote: > > Hello :-) > > > > Some time ago I have definitely moved from EXT2 to UFS2. This greatly > > improved my speed and stability on FreeBSD, but I somehow lost access > > and portability for other OS in "native" read-write mode. > > The lowest common denominator is msdosfs (DOS FAT) which is > usable in r/w nearly everywhere. If you require long file > names, you need the 16 bit version. This is commonly considered > the "typical solution" for the problem you're describing, even > though it doesn't really look any attractive because, as I > said, it's the _lowest_ common denominator where "lowest" is > determined by the inability of "Windows" products to be > willing to accept anything that isn't made, approved, certified > and sold by MICROS~1. :-) There's also UDF which doesn't suffer from a lot of the issues the FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX all support read/write to UDF, although it may depend on the OS version for Windows (I think XP needs a 3rd party driver).=E2=80=8B=E2=80=8B I've used UDF successfully on USB drives, although I don't think you can boot off it. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 17:33:18 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B09D702; Fri, 31 Jan 2014 17:33:18 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 267ED16F9; Fri, 31 Jan 2014 17:33:18 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id i8so7517048qcq.32 for ; Fri, 31 Jan 2014 09:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=m+2E3Vp2I6Sd0qKYOH7L8sY1S2Io1UyUGnA6YBFcsGM=; b=ndqxGRglMZvnDBdt5coUew5FniFJGdgEZtyb4IFe3rLn0Z7yNegr2CMtwtte1NRaV0 g6Fg4vow7Lt0ugNwcacn6oSbJ5iElu/79n7Pv5AFSaLY5U2DZhvUs5p1GveMA8wu6lY5 QlaqogD69jp8UUEzFRw9Vs065jqnwgfcdi1vlYSQi0PlCPnpRhz3oMHMxxBiOPZZYlI9 1hngfoRuLP0xhBBkVMY/sPbzJqYWamMzcQE07NzInemCXjU5NTlw0jTyAmHDYbqYkvyH PaUx0eQfyHo9e1qgnOGjHIQnY6hirajJq/GY4N2OyAb3NUYa8IDDD5kFhgsPzaZ04yph QMCw== MIME-Version: 1.0 X-Received: by 10.140.94.74 with SMTP id f68mr31975324qge.64.1391189597242; Fri, 31 Jan 2014 09:33:17 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.229.151.73 with HTTP; Fri, 31 Jan 2014 09:33:17 -0800 (PST) In-Reply-To: References: <20140131150601.53ee40f4.freebsd@edvax.de> Date: Fri, 31 Jan 2014 18:33:17 +0100 X-Google-Sender-Auth: Q5pAtOcLDCS5p_SOphYKTM5mWvk Message-ID: Subject: Re: UFS(2) portable driver for other OS From: CeDeROM To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Filesystems , Polytropon , FreeBSD Questions Mailing List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:33:18 -0000 On Fri, Jan 31, 2014 at 6:20 PM, Freddie Cash wrote: > There's also UDF which doesn't suffer from a lot of the issues the > FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX > all support read/write to UDF, although it may depend on the OS version for > Windows (I think XP needs a 3rd party driver). > I've used UDF successfully on USB drives, although I don't think you can > boot off it. Yess, thats what I need! Thank you Freddie, I will try it out!! :-) No need to boot of data partition anyway.. and I remember some UDF related issues on mkisofs port some time ago.. but this might be the best solution also for data storage on a HD and seems non -endian problematic :-) :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 17:39:43 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82D46A8F; Fri, 31 Jan 2014 17:39:43 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF6DD178A; Fri, 31 Jan 2014 17:39:42 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id l4so3617098lbv.5 for ; Fri, 31 Jan 2014 09:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tScIYLZSrL+W7eYp7Rxc9PfapDyGqD/H9MtTBKkXAXM=; b=LNeNpXpqTCxRp+otHpctjKbWggywMJAOzc2sXaoQjH+oG3YxHiFDD92cmUv+lCQeoT 7XrhXrZdHK8QpSk00hkqw0NE66E6Zdz5SHfTuCClv4NlrJrX3QMIIZIbjT9uj+ZmoQ4H INMC5z0mt+/O2NoHiI29RLTQiKBYp1aiM+z6pp4PR/pN44QxD+CP2UtWveTuv0IzxS0x e25C9EoO4c51m50eps4oeehfhCm6pnmy+kNGmpuhV7hf4Ekiz1JEvTA4pA4Jhma0BSrb kZAJyDZ4W8WofrRqddfhWoY+/43jv8yfH8F7N2tD+k5GEDaeUTXFR2nwOVqVF1w3NocM 1oaQ== X-Received: by 10.112.126.135 with SMTP id my7mr1612659lbb.56.1391189980760; Fri, 31 Jan 2014 09:39:40 -0800 (PST) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id mx3sm10941428lbc.14.2014.01.31.09.39.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 09:39:40 -0800 (PST) Message-ID: <52EBDFDA.6050708@gmail.com> Date: Fri, 31 Jan 2014 19:39:38 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andriy Gapon , "Nagy, Attila" , freebsd-fs@FreeBSD.org Subject: Re: Lot more swapping in stable/10 with ZFS References: <52E4DE17.3000206@fsn.hu> <52E7CEB8.7010906@gmail.com> <52E7DBC9.6000708@FreeBSD.org> In-Reply-To: <52E7DBC9.6000708@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:39:43 -0000 28.01.2014 18:33, Andriy Gapon wrote: > on 28/01/2014 17:37 Volodymyr Kostyrko said the following: >> 26.01.2014 12:06, Nagy, Attila wrote: >>> Hi, >>> >>> Running stable/10@r261157 (and earlier too), I've noticed that it swaps >>> much more than previous (stable/9) versions. >>> Current top output from such a machine: >>> Mem: 251M Active, 21M Inact, 7491M Wired, 118M Cache, 17M Buf, 51M Free >>> ARC: 5112M Total, 1455M MFU, 2155M MRU, 7761K Anon, 293M Header, 1223M >>> Other >>> Swap: 2045M Total, 757M Used, 1287M Free, 37% Inuse, 1280K Out >> >> Just a +1 from me: >> >> Mem: 1440M Active, 412M Inact, 5889M Wired, 82M Cache, 90M Free >> ARC: 3990M Total, 1981M MFU, 1505M MRU, 533K Anon, 79M Header, 424M Other >> Swap: 8192M Total, 1434M Used, 6758M Free, 17% Inuse >> >> This machine is up for 1+03:13:06 >> > > Guys, > > could you please set sysctl vm.lowmem_period to zero (after a fresh reboot) and > see if it makes any difference? Ok, there are some results: It starts with ARC at ~4G. Probably I should've taken some snapshots but I was waiting for at least one day of uptime. After that I started openoffice build in tmpfs. In something like an hour I got this: Mem: 1167M Active, 2453M Inact, 3483M Wired, 57M Cache, 752M Free ARC: 1060M Total, 199M MFU, 467M MRU, 6836K Anon, 31M Header, 356M Other Swap: 8192M Total, 7218M Used, 974M Free, 88% Inuse, 36K In As you can see ARC shrinked a lot and Inact is still big. So I cleared some space in tmpfs and ordered VirtualBox to unthaw some host. Kindda risky thing as It was pretty tight on memory. The host needs ~1150Mb of memory. Mem: 1806M Active, 1216M Inact, 2638M Wired, 1431M Cache, 820M Free ARC: 1231M Total, 255M MFU, 564M MRU, 34M Anon, 32M Header, 345M Other Swap: 8192M Total, 7065M Used, 1127M Free, 86% Inuse, 13M Out Hey, cheater! ARC grows! you can see Inact is been swapped out. Mem: 1871M Active, 676M Inact, 2649M Wired, 1946M Cache, 770M Free ARC: 1226M Total, 246M MFU, 599M MRU, 4112K Anon, 32M Header, 345M Other Swap: 8192M Total, 7623M Used, 569M Free, 93% Inuse, 14M Out 30 seconds passed - ARC is at the same level while Inact lost 600Mb. Mem: 1918M Active, 185M Inact, 3193M Wired, 1788M Cache, 828M Free ARC: 1405M Total, 390M MFU, 607M MRU, 30M Anon, 33M Header, 345M Other Swap: 8192M Total, 8150M Used, 42M Free, 99% Inuse, 16K In Restoration done. Openoffice is still building and VirtualBox host is running. That was close. Mem: 993M Active, 425M Inact, 4638M Wired, 11M Cache, 1845M Free ARC: 2081M Total, 749M MFU, 913M MRU, 797K Anon, 37M Header, 382M Other Swap: 8192M Total, 673M Used, 7519M Free, 8% Inuse tmpfs cleaned, host exited. ARC grows... -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 17:54:40 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78461EF3; Fri, 31 Jan 2014 17:54:40 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C208E1904; Fri, 31 Jan 2014 17:54:39 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id y1so3634085lam.8 for ; Fri, 31 Jan 2014 09:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uG2NfkPmBUU2dtXxlmOvMnN4rBJ8WI+suh+llDqSGe0=; b=brytn/v5zZrxDzOZiQ32FH609kyl6BlcdTjEuK+M/yE+UjJ5aH/065qOVKjOzMtMLk xGEJGRIvpZlJUvySxooyJ6DKuHOzRnsD9oSdttpDymPAZp4mPUjePyP4DTVgQ5FHYSAB xRc9c2/ljtcFS0cJhEsmlplKA7fe0uS/lBgi4pvLfB0ljKCho6tdpBtZFBrYmmsD2YC4 wk+h23xaADi2bE21v0hiydp3DN3n2qZqk27kY5KBPI6AwFBWvCKAu9hr01wPI5HjErY1 1VLS5zAqKHyH8kSUllHFFIR9fON6+7ZpXRuXDXt4xpLxFb8AgPqgIw+XMI8Zd/GXvXR9 jDqA== X-Received: by 10.152.236.72 with SMTP id us8mr14493299lac.11.1391190877881; Fri, 31 Jan 2014 09:54:37 -0800 (PST) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id bn5sm10993313lbc.10.2014.01.31.09.54.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 09:54:37 -0800 (PST) Message-ID: <52EBE35C.6090905@gmail.com> Date: Fri, 31 Jan 2014 19:54:36 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Freddie Cash , Polytropon Subject: Re: UFS(2) portable driver for other OS References: <20140131150601.53ee40f4.freebsd@edvax.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Filesystems , FreeBSD Questions Mailing List , CeDeROM X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:54:40 -0000 31.01.2014 19:20, Freddie Cash написав(ла): > On Fri, Jan 31, 2014 at 6:06 AM, Polytropon wrote: > >> On Fri, 31 Jan 2014 14:41:13 +0100, CeDeROM wrote: >>> Hello :-) >>> >>> Some time ago I have definitely moved from EXT2 to UFS2. This greatly >>> improved my speed and stability on FreeBSD, but I somehow lost access >>> and portability for other OS in "native" read-write mode. >> >> The lowest common denominator is msdosfs (DOS FAT) which is >> usable in r/w nearly everywhere. If you require long file >> names, you need the 16 bit version. This is commonly considered >> the "typical solution" for the problem you're describing, even >> though it doesn't really look any attractive because, as I >> said, it's the _lowest_ common denominator where "lowest" is >> determined by the inability of "Windows" products to be >> willing to accept anything that isn't made, approved, certified >> and sold by MICROS~1. :-) > > > There's also UDF which doesn't suffer from a lot of the issues the > FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX > all support read/write to UDF, although it may depend on the OS version for > Windows (I think XP needs a 3rd party driver).​​ Waaaaait. This doesn't mean FreeBSD can mount UDF for read/write, doesn't it? -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 17:56:40 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CAE26A; Fri, 31 Jan 2014 17:56:40 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7E14191F; Fri, 31 Jan 2014 17:56:39 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wm4so5422696obc.27 for ; Fri, 31 Jan 2014 09:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PCnfFVjaAObNwMlmwsWJ3RkVN5KXCsFA+figboFFWFg=; b=vbSqIGZhuYLWyt4S8RY/lrwWjflsQX0UEWBjkP9REFvO8XNAJhkl97qTvTPy/9l+O2 wuBrEGnkgdiKCIWO6lKu3SbzPVVrdTsB4kzTwjLr+Mdey2vGClECDoCdIK88LmE17HmV iqM5AJDOvC8I1wQz4tKcCVSDqc9XRbfFeTNKuJHSzfj2Vu04J2V54KkMX1u+CILhoo+a X4rJP2PzmwGgfcReaNxT8o1NB32pT5Id7JH/kmtKvG+afy0ySSucsoN9aFxqtGu/+iSY hI8oYraTct5J9amAaN5lfgkiPvlEGAEC3LwZc+NUdxyFJ+0fSd172cAh3meJjZ78D3eI y7qA== MIME-Version: 1.0 X-Received: by 10.182.19.132 with SMTP id f4mr17540990obe.14.1391190998948; Fri, 31 Jan 2014 09:56:38 -0800 (PST) Received: by 10.76.132.9 with HTTP; Fri, 31 Jan 2014 09:56:38 -0800 (PST) In-Reply-To: <52EBE35C.6090905@gmail.com> References: <20140131150601.53ee40f4.freebsd@edvax.de> <52EBE35C.6090905@gmail.com> Date: Fri, 31 Jan 2014 09:56:38 -0800 Message-ID: Subject: Re: UFS(2) portable driver for other OS From: Freddie Cash To: Volodymyr Kostyrko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Filesystems , Polytropon , FreeBSD Questions Mailing List , CeDeROM X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:56:40 -0000 On Fri, Jan 31, 2014 at 9:54 AM, Volodymyr Kostyrko wrot= e: > 31.01.2014 19:20, Freddie Cash =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2= (=D0=BB=D0=B0): > >> On Fri, Jan 31, 2014 at 6:06 AM, Polytropon wrote: >> >> On Fri, 31 Jan 2014 14:41:13 +0100, CeDeROM wrote: >>> >>>> Hello :-) >>>> >>>> Some time ago I have definitely moved from EXT2 to UFS2. This greatly >>>> improved my speed and stability on FreeBSD, but I somehow lost access >>>> and portability for other OS in "native" read-write mode. >>>> >>> >>> The lowest common denominator is msdosfs (DOS FAT) which is >>> usable in r/w nearly everywhere. If you require long file >>> names, you need the 16 bit version. This is commonly considered >>> the "typical solution" for the problem you're describing, even >>> though it doesn't really look any attractive because, as I >>> said, it's the _lowest_ common denominator where "lowest" is >>> determined by the inability of "Windows" products to be >>> willing to accept anything that isn't made, approved, certified >>> and sold by MICROS~1. :-) >>> >> >> >> There's also UDF which doesn't suffer from a lot of the issues the >> FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX >> all support read/write to UDF, although it may depend on the OS version >> for >> Windows (I think XP needs a 3rd party driver).=E2=80=8B=E2=80=8B >> > > Waaaaait. This doesn't mean FreeBSD can mount UDF for read/write, doesn't > it? I'd have to re-test it at home, but I'm pretty sure it worked on FreeBSD 9 as well. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 18:53:23 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFF6215F for ; Fri, 31 Jan 2014 18:53:23 +0000 (UTC) Received: from platinum.linux.pl (platinum.edu.pl [81.161.192.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2001EAE for ; Fri, 31 Jan 2014 18:53:22 +0000 (UTC) Received: by platinum.linux.pl (Postfix, from userid 87) id E217545218E; Fri, 31 Jan 2014 19:46:13 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on platinum.linux.pl X-Spam-Level: X-Spam-Status: No, score=-1.3 required=3.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.3.2 Received: from [10.255.0.2] (unknown [83.151.38.73]) by platinum.linux.pl (Postfix) with ESMTPA id D989245218C; Fri, 31 Jan 2014 19:46:07 +0100 (CET) Message-ID: <52EBEF5F.4060100@platinum.linux.pl> Date: Fri, 31 Jan 2014 19:45:51 +0100 From: Adam Nowacki User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Antonis Anastasiadis , freebsd-fs@freebsd.org Subject: Re: ZFS - Uncompress raw LZ4 data References: <52EB84F3.50602@datalive.gr> In-Reply-To: <52EB84F3.50602@datalive.gr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 18:53:23 -0000 On 2014-01-31 12:11, Antonis Anastasiadis wrote: > Hi everyone, > > I'm trying to recover a deleted file from a single disk LZ4 compressed > dataset. The pool is in fine condition. > > I tried printing the uberblock history via zdb, but the file had been > deleted before the oldest uberblock I could find. So I guess I can't > roll back into that pool state. > > The file was very small (90-120 kb) so it should fit in a single ZFS > block. I do not know the deleted block's DVA in order to restore it via > zdb -R. But I have similar files on the disk, so I can get the file header. > > As a last resort, I'm thinking going brute force and somehow find all > ZFS blocks (even deleted ones) from the raw partition, decompress the > data and check the binary data for the file header. Is there a tool that > decompresses raw LZ4 data out there? Max Bruning has written a utility > called "zuncompress" but it doesn't support LZ4 > (http://mbruning.blogspot.gr/2009/12/zfs-raidz-data-walk.html) You'll find the code to decompress in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lz4.c, LZ4_uncompress_unknownOutputSize. > > I know 'm shooting in the dark here, but I would appreciate any other > ideas from the ZFS gurus out there. > > Thanks, > > Antonis Anastasiadis > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 21:56:54 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 819E9D4B; Fri, 31 Jan 2014 21:56:54 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 533A01DBE; Fri, 31 Jan 2014 21:56:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C7488B979; Fri, 31 Jan 2014 16:56:52 -0500 (EST) From: John Baldwin To: freebsd-fs@freebsd.org Subject: Re: BUG: possible NULL pointer dereference in nfs server Date: Fri, 31 Jan 2014 16:42:28 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <410866336.17211125.1390863857778.JavaMail.root@uoguelph.ca> <20140128112731.S1362@besplex.bde.org> <20140128094045.GB16311@freebsd.org> In-Reply-To: <20140128094045.GB16311@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401311642.28821.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 31 Jan 2014 16:56:52 -0500 (EST) Cc: Roman Divacky , Dimitry Andric , fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 21:56:54 -0000 On Tuesday, January 28, 2014 4:40:45 am Roman Divacky wrote: > > > Yea, so long as it includes a comment that states this is done to > > > work around a stupid compiler bug. > > > > Ugh. > > > > The above has the following bugs: > > - gross style bugs (lines longer than 80 characters) > > - large code to do nothing > > - would be even larger with a comment > > - cannot actually work around any compiler bug involving abort(), since it > > has no effect on production kernels where KASSERT() is null. > > > > >> It is present even in your setup :) Just "objdump -d kernel | grep > > >> ud2" on kernel compiled > > >> by clang. > > >> > > > I actually use gcc, but I believe you. I'll admit I still don't understand > > > why having a trap instruction that never gets executed is a bad thing? > > > > It isn't but trying to link to the noexistent function abort() on > > arches that don't have any trap instruction is a bad thing. According > > the above, this occurs on sparc64. It must be a gcc bug, since sparc64 > > doesn't have clang. However, I couldn't get gcc on sparc64 to generate > > an abort() for *NULL. Similarly on x86 (gcc is hard to test on x86, > > since it is broken (not installed) on FreeBSD cluster machines for > > I was testing clang compiled kernel on sparc64. > > The problem is that there's nothing making sure that the NULL pointer > dereference doesnt happen. So if someone happens to call the function with > wrong flags it will crash. > > Thats why I want to add the KASSERT, to catch possible future cases > when this happens. > > Unfortunately our KASSERT is not an assert so to remove the actual > abort/trap/ud2 I have to remove the flag. Why not make a simple abort() that calls panic()? It seems clumsy to have to add hacks in the source code. OTOH, the new_lfpp thing just seems to be obfuscation. Seems you can remove one layer of pointer there. It doesn't help you with the compiler not being able to see the invariant that prevents the problem though. Index: nfs_nfsdstate.c =================================================================== --- nfs_nfsdstate.c (revision 261291) +++ nfs_nfsdstate.c (working copy) @@ -79,7 +79,7 @@ static int nfsrv_getstate(struct nfsclient *clp, n static void nfsrv_getowner(struct nfsstatehead *hp, struct nfsstate *new_stp, struct nfsstate **stpp); static int nfsrv_getlockfh(vnode_t vp, u_short flags, - struct nfslockfile **new_lfpp, fhandle_t *nfhp, NFSPROC_T *p); + struct nfslockfile *new_lfp, fhandle_t *nfhp, NFSPROC_T *p); static int nfsrv_getlockfile(u_short flags, struct nfslockfile **new_lfpp, struct nfslockfile **lfpp, fhandle_t *nfhp, int lockit); static void nfsrv_insertlock(struct nfslock *new_lop, @@ -1985,7 +1985,7 @@ tryagain: MALLOC(new_lfp, struct nfslockfile *, sizeof (struct nfslockfile), M_NFSDLOCKFILE, M_WAITOK); if (vp) - getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, &new_lfp, + getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, new_lfp, NULL, p); NFSLOCKSTATE(); /* @@ -2235,7 +2235,7 @@ tryagain: M_NFSDSTATE, M_WAITOK); MALLOC(new_deleg, struct nfsstate *, sizeof (struct nfsstate), M_NFSDSTATE, M_WAITOK); - getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, &new_lfp, + getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, new_lfp, NULL, p); NFSLOCKSTATE(); /* @@ -3143,10 +3143,9 @@ out: */ static int nfsrv_getlockfh(vnode_t vp, u_short flags, - struct nfslockfile **new_lfpp, fhandle_t *nfhp, NFSPROC_T *p) + struct nfslockfile *new_lfp, fhandle_t *nfhp, NFSPROC_T *p) { fhandle_t *fhp = NULL; - struct nfslockfile *new_lfp; int error; /* @@ -3154,7 +3153,6 @@ nfsrv_getlockfh(vnode_t vp, u_short flags, * a fhandle_t on the stack. */ if (flags & NFSLCK_OPEN) { - new_lfp = *new_lfpp; fhp = &new_lfp->lf_fh; } else if (nfhp) { fhp = nfhp; -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri Jan 31 23:52:05 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8F0DAC7; Fri, 31 Jan 2014 23:52:05 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 61E1B1679; Fri, 31 Jan 2014 23:52:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEANw27FKDaFve/2dsb2JhbABZg0RXgwG6CU+BInSCJQEBAQQBAQEgBCcgCxsOCgICDRkCKQEJJgYIBwQBHASHZA2sBqEvF4EpjQgBARsBMweCb4FJBIlJjA6EBZBvg0seMYEEOQ X-IronPort-AV: E=Sophos;i="4.95,760,1384318800"; d="scan'208";a="92180035" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 31 Jan 2014 18:52:04 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4DEF5B40F1; Fri, 31 Jan 2014 18:52:04 -0500 (EST) Date: Fri, 31 Jan 2014 18:52:04 -0500 (EST) From: Rick Macklem To: John Baldwin Message-ID: <346483760.1090608.1391212324309.JavaMail.root@uoguelph.ca> In-Reply-To: <201401311642.28821.jhb@freebsd.org> Subject: Re: BUG: possible NULL pointer dereference in nfs server MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-fs@freebsd.org, Roman Divacky , Dimitry Andric , fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 23:52:06 -0000 John Baldwin wrote: > On Tuesday, January 28, 2014 4:40:45 am Roman Divacky wrote: > > > > Yea, so long as it includes a comment that states this is done > > > > to > > > > work around a stupid compiler bug. > > > > > > Ugh. > > > > > > The above has the following bugs: > > > - gross style bugs (lines longer than 80 characters) > > > - large code to do nothing > > > - would be even larger with a comment > > > - cannot actually work around any compiler bug involving abort(), > > > since it > > > has no effect on production kernels where KASSERT() is null. > > > > > > >> It is present even in your setup :) Just "objdump -d kernel | > > > >> grep > > > >> ud2" on kernel compiled > > > >> by clang. > > > >> > > > > I actually use gcc, but I believe you. I'll admit I still don't > > > > understand > > > > why having a trap instruction that never gets executed is a bad > > > > thing? > > > > > > It isn't but trying to link to the noexistent function abort() on > > > arches that don't have any trap instruction is a bad thing. > > > According > > > the above, this occurs on sparc64. It must be a gcc bug, since > > > sparc64 > > > doesn't have clang. However, I couldn't get gcc on sparc64 to > > > generate > > > an abort() for *NULL. Similarly on x86 (gcc is hard to test on > > > x86, > > > since it is broken (not installed) on FreeBSD cluster machines > > > for > > > > I was testing clang compiled kernel on sparc64. > > > > The problem is that there's nothing making sure that the NULL > > pointer > > dereference doesnt happen. So if someone happens to call the > > function with > > wrong flags it will crash. > > > > Thats why I want to add the KASSERT, to catch possible future cases > > when this happens. > > > > Unfortunately our KASSERT is not an assert so to remove the actual > > abort/trap/ud2 I have to remove the flag. > > Why not make a simple abort() that calls panic()? It seems clumsy to > have to > add hacks in the source code. > > OTOH, the new_lfpp thing just seems to be obfuscation. Seems you can > remove > one layer of pointer there. It doesn't help you with the compiler > not being > able to see the invariant that prevents the problem though. > > Index: nfs_nfsdstate.c > =================================================================== > --- nfs_nfsdstate.c (revision 261291) > +++ nfs_nfsdstate.c (working copy) > @@ -79,7 +79,7 @@ static int nfsrv_getstate(struct nfsclient *clp, n > static void nfsrv_getowner(struct nfsstatehead *hp, struct nfsstate > *new_stp, > struct nfsstate **stpp); > static int nfsrv_getlockfh(vnode_t vp, u_short flags, > - struct nfslockfile **new_lfpp, fhandle_t *nfhp, NFSPROC_T *p); > + struct nfslockfile *new_lfp, fhandle_t *nfhp, NFSPROC_T *p); > static int nfsrv_getlockfile(u_short flags, struct nfslockfile > **new_lfpp, > struct nfslockfile **lfpp, fhandle_t *nfhp, int lockit); > static void nfsrv_insertlock(struct nfslock *new_lop, > @@ -1985,7 +1985,7 @@ tryagain: > MALLOC(new_lfp, struct nfslockfile *, sizeof (struct nfslockfile), > M_NFSDLOCKFILE, M_WAITOK); > if (vp) > - getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, &new_lfp, > + getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, new_lfp, > NULL, p); > NFSLOCKSTATE(); > /* > @@ -2235,7 +2235,7 @@ tryagain: > M_NFSDSTATE, M_WAITOK); > MALLOC(new_deleg, struct nfsstate *, sizeof (struct nfsstate), > M_NFSDSTATE, M_WAITOK); > - getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, &new_lfp, > + getfhret = nfsrv_getlockfh(vp, new_stp->ls_flags, new_lfp, > NULL, p); > NFSLOCKSTATE(); > /* > @@ -3143,10 +3143,9 @@ out: > */ > static int > nfsrv_getlockfh(vnode_t vp, u_short flags, > - struct nfslockfile **new_lfpp, fhandle_t *nfhp, NFSPROC_T *p) > + struct nfslockfile *new_lfp, fhandle_t *nfhp, NFSPROC_T *p) > { > fhandle_t *fhp = NULL; > - struct nfslockfile *new_lfp; > int error; > > /* > @@ -3154,7 +3153,6 @@ nfsrv_getlockfh(vnode_t vp, u_short flags, > * a fhandle_t on the stack. > */ > if (flags & NFSLCK_OPEN) { > - new_lfp = *new_lfpp; > fhp = &new_lfp->lf_fh; > } else if (nfhp) { > fhp = nfhp; > > Yep, this looks good to me, although I have no idea if it makes the compiler happy? I think the new_lfpp argument was a vestige created when nfsrv_getlockfh() became a separate function from nfsrv_getlockfile() during development. (The latter needs the "**", since it sets it to NULL to indicate the new structure is being used and shouldn't be free'd.) rick > -- > John Baldwin > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sat Feb 1 02:36:30 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AA3D438 for ; Sat, 1 Feb 2014 02:36:30 +0000 (UTC) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B3171122 for ; Sat, 1 Feb 2014 02:36:29 +0000 (UTC) Received: from [98.139.212.152] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 02:36:22 -0000 Received: from [68.142.230.65] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 02:36:22 -0000 Received: from [127.0.0.1] by smtp222.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 02:36:22 -0000 X-Yahoo-Newman-Id: 663151.94056.bm@smtp222.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ohysu6oVM1nmrKxdXEMjPX051njACjSTzU2Txs2rGHgfS_p YOxnRNziBZLbdECjspVpfcSaxjm6Ld1_6ZfGhA6bf9jJHp8jitT8KU2gRtfl wQxWy1jqpZWurG5MvMRxYbECwr6keROrHZe9c6gw16JrKY1peQyWyK28WL0y 1uElD.kmnEIN8tgFP_X3URkoOu3DHSqqoVijtbgDQCNjG8S18a8K8Th.H.Ja u0oHJjDWO2P1dOD.FTFL_zn5PsgX4rJW.h.dsAbjIR4JbZYcdIsXDD1wseKZ 47mpYlMTjUUTcO9q872fgXnGcaNkbN5Hpxe4ynfP9xLXhwR6Xklm5nyJw9xF 2DwSQItiBSW0MQAA83EXIuJe31up8HLt0RASnt_SpHnjUeRaRSmfL5FXrAuT XrCzrIYE_3VUduT3__ZNaqF9WT26FDeH.yDkFWzmZer4z5sT7jdO3gINiqbq LQV63ET5xSeH6jbs05QnjmBdJ1nvbZ92N_F9OdGgZ0178RGrdfu_ATt9RGo5 9rn.8mx5az.Upk11BdI.m2IE3m23_ABcJGOpvGe95uOTVQTCOHwa4bA-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [63.250.193.228]) by smtp222.mail.bf1.yahoo.com with SMTP; 01 Feb 2014 02:36:22 +0000 UTC Message-ID: <52EC5B93.9010709@FreeBSD.org> Date: Fri, 31 Jan 2014 21:27:31 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: CeDeROM Subject: Re: UFS(2) portable driver for other OS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 02:36:30 -0000 Hi Tomek; FWIW, we fixed yet more bugs in ext2fs lately but I think this time we finally got it right. Recent -stable (9 and 10) already has the fixes. Tricks: we support dirindex now so you can set it in e2tunefs. If you are not satisfied with performance, you can also try running it async as linux does. JIC you feel adventurous and want to give a try rebuilding your own kernel for fun. :). This said, I don't recommend ext2fs for anything serious. I have some interest in resurrecting the MacOS X UFS1 support and perhaps get it to a point where it supports softupdates, but I don't know yet sufficient about kexts. Pedro. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 1 14:17:42 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C5358B6 for ; Sat, 1 Feb 2014 14:17:42 +0000 (UTC) Received: from mail.crucible.gr (static.106.97.76.144.clients.your-server.de [144.76.97.106]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00A9A11B1 for ; Sat, 1 Feb 2014 14:17:40 +0000 (UTC) Received: from mail.crucible.gr (unknown [10.0.0.106]) by mail.crucible.gr (Postfix) with ESMTP id 3DCE33EEA for ; Sat, 1 Feb 2014 16:17:32 +0200 (EET) Received: by mail.crucible.gr (Postfix, from userid 58) id 222EB3EE9; Sat, 1 Feb 2014 16:17:32 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.datalive.gr X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=ham version=3.3.2 Received: from Macintosh.local (unknown [2.84.133.157]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: anastasiadis@datalive.gr) by mail.crucible.gr (Postfix) with ESMTPSA id CC9383EE4; Sat, 1 Feb 2014 16:17:31 +0200 (EET) Message-ID: <52ED01FB.2020203@datalive.gr> Date: Sat, 01 Feb 2014 16:17:31 +0200 From: Antonis Anastasiadis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adam Nowacki , freebsd-fs@freebsd.org Subject: Re: ZFS - Uncompress raw LZ4 data References: <52EB84F3.50602@datalive.gr> <52EBEF5F.4060100@platinum.linux.pl> In-Reply-To: <52EBEF5F.4060100@platinum.linux.pl> X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 14:17:42 -0000 ???? 1/31/14, 8:45 PM, ?/? Adam Nowacki ??????: > You'll find the code to decompress in > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lz4.c, > LZ4_uncompress_unknownOutputSize. Thanks! From owner-freebsd-fs@FreeBSD.ORG Sat Feb 1 15:32:26 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C1EB927; Sat, 1 Feb 2014 15:32:26 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 377101704; Sat, 1 Feb 2014 15:32:26 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id e16so8718110qcx.38 for ; Sat, 01 Feb 2014 07:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=D+6f3XG8+GJ42XfB2qlDcL68YAnIjZ2ZEXljuJKnHv4=; b=esr3byz6pdbsn9QqLP5x+MIwfRAdhwCMyKDHBv5aiRZ2B2coYlESHiIYX6vKfqZfdv Vnt/Ykp+FIzd2Y+Q/IkTTV8KmzR0/du4kpcy2rPnGMrr0WzUl/Q9AY0upxKQoKEaGSkZ TfgGjzTODOvhZrSHpi8dAzoepCdKeJZxGJNaQ4AZ94lgZLrLtIZ+fFnLy4FOTiXJJ+xC WnzgD0qs+OXnA14LzZojAo9pe2eOvCUGnDVwozNPHCjurdCWzgQD4Ao5Pqk0yqgupnBk rxnV3LuMseMsHsjq22h3qd3sjZ3WrcHjo/554VHvXlEzLwpKMQDqw4wkMj7Ryd6Jf45l tm4Q== MIME-Version: 1.0 X-Received: by 10.140.108.229 with SMTP id j92mr39125824qgf.7.1391268745455; Sat, 01 Feb 2014 07:32:25 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.229.151.73 with HTTP; Sat, 1 Feb 2014 07:32:25 -0800 (PST) Received: by 10.229.151.73 with HTTP; Sat, 1 Feb 2014 07:32:25 -0800 (PST) In-Reply-To: <52EC5B93.9010709@FreeBSD.org> References: <52EC5B93.9010709@FreeBSD.org> Date: Sat, 1 Feb 2014 16:32:25 +0100 X-Google-Sender-Auth: 5hHmkAk8aVC5fTOXcz_RoI1jrpo Message-ID: Subject: Re: UFS(2) portable driver for other OS From: CeDeROM To: Pedro Giffuni Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 15:32:26 -0000 Hello Pedro :-) I was thinking about making UFS multiplatform with a BSD licensed code, still wondering why it has not done yet.. :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On 1 Feb 2014 03:36, "Pedro Giffuni" wrote: > Hi Tomek; > > FWIW, we fixed yet more bugs in ext2fs lately but I think this time we > finally got it right. Recent -stable (9 and 10) already has the fixes. > > Tricks: we support dirindex now so you can set it in e2tunefs. If you are > not satisfied with performance, you can also try running it async as linux > does. > > JIC you feel adventurous and want to give a try rebuilding your own kernel > for fun. :). This said, I don't recommend ext2fs for anything serious. > > I have some interest in resurrecting the MacOS X UFS1 support and perhaps > get it to a point where it supports softupdates, but I don't know yet > sufficient about kexts. > > Pedro. > From owner-freebsd-fs@FreeBSD.ORG Sat Feb 1 17:43:13 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE253F58; Sat, 1 Feb 2014 17:43:13 +0000 (UTC) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D5741FF8; Sat, 1 Feb 2014 17:43:12 +0000 (UTC) X-AuditID: 12074423-f79726d000000cc9-3b-52ed30fc5b11 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.EB.03273.CF03DE25; Sat, 1 Feb 2014 12:38:04 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s11Hc30R011502; Sat, 1 Feb 2014 12:38:03 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s11Hc17i026252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Feb 2014 12:38:03 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s11Hc1Aq016244; Sat, 1 Feb 2014 12:38:01 -0500 (EST) Date: Sat, 1 Feb 2014 12:38:01 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Pedro Giffuni Subject: Re: UFS(2) portable driver for other OS In-Reply-To: <52EC5B93.9010709@FreeBSD.org> Message-ID: References: <52EC5B93.9010709@FreeBSD.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixG6novvH4G2Qwa1OHotjj3+yWTycsoTN gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZm68uZiloYK44+6aJtYFxHVMXIyeHhICJxOYDG9kh bDGJC/fWs3UxcnEICcxmkli74AwLhLOBUeLu5eWsIFVCAgeZJNq7wyHseonn/3eDdbMIaEnM O9/KAmKzCahJPN7bzAoxVVFi86lJzCC2iICyxI+TL8FqmAUMJD78agOzhYHshjtvwOZwCmhL zLk9DyzOK+Ao0dPwmQlil5bElyczwWxRAR2J1funQNUISpyc+QRqpqXEuT/X2SYwCs1CkpqF JLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrplebmaJXmpK6SZGcNi6KO9g/HNQ6RCjAAej Eg/vjVOvg4RYE8uKK3MPMUpyMCmJ8k4TexskxJeUn1KZkVicEV9UmpNafIhRgoNZSYTXTx0o x5uSWFmVWpQPk5LmYFES502c8SZISCA9sSQ1OzW1ILUIJivDwaEkwXtOH6hRsCg1PbUiLTOn BCHNxMEJMpwHaLilAcjw4oLE3OLMdIj8KUZFKXFeVZCEAEgiozQPrheWVl4xigO9IsybCbKC B5iS4LpfAQ1mAhrcc+A1yOCSRISUVAMjy4zuPrciv+sSVa0taxr3Krtv6WIrvnTkVFBO+qfb K6/eYtFLM9zyO6VgA/fO7YtXZ+WsYtG6qVGwa6fHRLZ/rfuzhTWXVO7Xau50YKt9EHtH//kc E87eRTr353G0vZzwxMAqdlKJovvBO1mlnJv+rAotzFsYaPF967utql96Ym5VOXiUsAgpsRRn JBpqMRcVJwIAIQxnrAYDAAA= Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 17:43:13 -0000 On Fri, 31 Jan 2014, Pedro Giffuni wrote: > I have some interest in resurrecting the MacOS X UFS1 support and perhaps get > it to a point where it supports softupdates, but I don't know yet sufficient > about kexts. I believe that OS X is moving towards requiring signed kexts; I don't know whether your interest extends to paying for a code-signing certificate. -Ben From owner-freebsd-fs@FreeBSD.ORG Sat Feb 1 18:01:53 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 392B2330 for ; Sat, 1 Feb 2014 18:01:53 +0000 (UTC) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDFC6115C for ; Sat, 1 Feb 2014 18:01:52 +0000 (UTC) Received: from [98.139.212.152] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 18:01:45 -0000 Received: from [68.142.230.72] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 18:01:45 -0000 Received: from [127.0.0.1] by smtp229.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 18:01:45 -0000 X-Yahoo-Newman-Id: 222100.82326.bm@smtp229.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nibYYnMVM1nXanKYPxHJm5TsxOYOY81kK3ZseOjF9dwv66a 2seHRYfl_eBef2RWpzpztmhE4Mn4Saj3oMDAY4pBeuR4gwERZFsyE1XDyD8d N3Q.u9qHaIdivEC8ZsqgyqtF0LUrZOmMO7f9Fo3NXa3jo9O3cPin3GqMnLbl PuOrjkLK0pe2Fuurmt2f7BrTMJfq85CYWqhLvkGxGbt3ih83VhFwmD3xvM6N POkJma8iu63UubPDUL7JVCsQYJ79Qj3urMSo0t1OTTELhvbqoBxju0ooKcNA HifzL_Wu2uoqVatEcp4G6hen5hChiXbHmQO6xK64lgbUTowJB1CGie0OYf6m iUAAKsrxINko4lQZLvJToZwXVUnOFrL4xm.2g4R5L3M7SgOP69NTeyKHdc2u pjHJRP9PBLQ.HdmfgZbVGriXhtrB0KUuA_.CcO2AMPqw6D_te_7AknOXwT7Z jb991hfZEMjdaIW309iPl_TFXJ4FnQAbNq8XvjkBY9Lyw5tEqxO3ffnC7KnY WnN1GARG5oaQXO.ozujiWRtxrFqluEdpsrHSgeDCGdP1QZyddHEiAo7A- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [63.250.193.228]) by smtp229.mail.bf1.yahoo.com with SMTP; 01 Feb 2014 18:01:45 +0000 UTC Message-ID: <52ED3688.8030604@FreeBSD.org> Date: Sat, 01 Feb 2014 13:01:44 -0500 From: Pedro Giffuni Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: CeDeROM Subject: Re: UFS(2) portable driver for other OS References: <52EC5B93.9010709@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 18:01:53 -0000 On 01/02/2014 10:32, CeDeROM wrote: > Hello Pedro :-) > > I was thinking about making UFS multiplatform with a BSD licensed code, > still wondering why it has not done yet.. :-) > I am pretty sure such effort has been started a couple of times in the past. Maintaining a portable filesystem is not really an easy task though, and most implementations end up severely limiting the feature set and/or proving to be incapable of keeping up to date with the upstream functionality. Beyond FAT it is difficult to find good multiplatform support for just about any filesystem. As someone already suggested for just exchanging files tar is an option. Pedro. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 1 19:00:00 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7874211; Sat, 1 Feb 2014 19:00:00 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63A651532; Sat, 1 Feb 2014 19:00:00 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id w7so9154961qcr.0 for ; Sat, 01 Feb 2014 10:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=z/cpAkk+GztKNrqujxbB5FtKPuzFdw7AkJEuHLbJXEE=; b=QW0Y4LuK0h1UU5CGgqU6TRaEgL1t4l2NqyziRoyGKsDiGMzAVW6MGWN7JltFAyP+M4 xNpFXlNjrpMLG22cFb6W6FTY11u0e55V9U5UycXdjL2ql/rTvjR91FllSWfjROD6XAv4 ke3M60xwQiXkl52e0PW+b6ahmRR55R9XBsKcNQY2496v5EzN5XKWS/SRKrFyK2MvGRQh uieEK8BlG/ZUgPe31qIi5sPqQkGnE66/yID74qic0MttR9zYEG8lToJIoibmYm9QRWCI ixVR8oLYjz9YxAeGRyQp4o6ImeV9kvbakcDfpxLq4cJ1IptzOZaAonoC1IM11GCFViTR PD8Q== MIME-Version: 1.0 X-Received: by 10.224.124.74 with SMTP id t10mr42660043qar.40.1391281199425; Sat, 01 Feb 2014 10:59:59 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.229.151.73 with HTTP; Sat, 1 Feb 2014 10:59:59 -0800 (PST) In-Reply-To: References: <20140131150601.53ee40f4.freebsd@edvax.de> Date: Sat, 1 Feb 2014 19:59:59 +0100 X-Google-Sender-Auth: 5RQZY3qwq_ws78ZDrA31mDGjaok Message-ID: Subject: Re: UFS(2) portable driver for other OS From: CeDeROM To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Filesystems , Polytropon , FreeBSD Questions Mailing List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 19:00:00 -0000 On Fri, Jan 31, 2014 at 6:33 PM, CeDeROM wrote: > On Fri, Jan 31, 2014 at 6:20 PM, Freddie Cash wrote: >> There's also UDF which doesn't suffer from a lot of the issues the >> FAT16/32/32x does on large-ish devices. FreeBSD, Windows, Linux, MacOSX >> all support read/write to UDF, although it may depend on the OS version for >> Windows (I think XP needs a 3rd party driver). >> I've used UDF successfully on USB drives, although I don't think you can >> boot off it. > > Yess, thats what I need! Thank you Freddie, I will try it out!! :-) UDF disk does not work on FreeBSD :-( I can create filesystem on a file, but not a memory disk (not supported on my operating system yet). Then I cannot mount both of them anyway. Dead end for UDF disk on FreeBSD? Is seems possible on Linux and Windows though: http://tanguy.ortolo.eu/blog/article93/usb-udf root@hexagon:~ # dd if=/dev/zero of=udf.bin bs=64k count=128k 131072+0 records in 131072+0 records out 8589934592 bytes transferred in 111.747670 secs (76869026 bytes/sec) root@hexagon:~ # newfs_udf -L UDFTEST udf.bin Opening device udf.bin UDF device udf.bin is a regular file bufcache thread initialising Disc info for disc in device udf.bin MMC profile : Unknown[0] profile sequential : no recordable : yes erasable : no blankable : no formattable : no rewritable : yes mount raineer : no packet writing : no strict overwrite : no blocking number : 1 disc state : random writable last session state : incomplete sectorsize : 512 Number of sessions 1 Session 0 start at 0 ends at 16777216 length for 16777216 next writable at 16777217 free blocks 0 packet size 64 Creating a filingsystem on a recordable rewritable CD-RW or DVD+RW/DVD-RW or fixed length file Free unallocated space on this volume 8587442688 Closing disc Dismounting disc syncing disc syncing `4dc9e13a`:`00001674`:`UDFTEST` syncing data syncing nodes used/freed space tables Closing logical volume `4dc9e13a`:`00001674`:`UDFTEST` wait for syncing disc to idle stopping bufcache thread bufcache thread joining signal disc its finished with writing wait for final disc idling close device Disc access statistics sector reads 1 (0 Kbyte) sector written 4267 (2133 Kbyte) switches 3 root@hexagon:~ # dd if=/dev/zero of=udf2.bin bs=64k count=8k 8192+0 records in 8192+0 records out 536870912 bytes transferred in 7.191754 secs (74650899 bytes/sec) root@hexagon:~ # mdconfig -a -f udf2.bin md0 root@hexagon:~ # newfs_udf -L UDFTEST2 /dev/md0 Opening device /dev/md0 Got error executing SCSI command, assuming IDE disc UDF: no explicit support for disc devices yet for this operating system. : No such file or directory Trying readonly access... : No such file or directory UDF: warning... reading/writing on 'disc' device bufcache thread initialising Disc info for disc in device /dev/md0 MMC profile : Unknown[0] profile sequential : no recordable : no erasable : no blankable : no formattable : no rewritable : no mount raineer : no packet writing : no strict overwrite : no blocking number : 1 disc state : random writable last session state : complete/closed disc sectorsize : 512 Number of sessions 1 Session 0 start at 0 ends at 0 length for 0 next writable at 0 free blocks 0 packet size 0 Can't create filingsystem on a non recordable disc Closing disc Dismounting disc dismounting readonly disc stopping bufcache thread bufcache thread joining Disc access statistics sector reads 0 (0 Kbyte) sector written 0 (0 Kbyte) switches 0 root@hexagon:~ # mount_udf -v /dev/md0 /mnt/tmp mount_udf: /dev/md0: Invalid argument root@hexagon:~ # mdconfig -d -u 0 root@hexagon:~ # mount_udf -v udf.bin /mnt/tmp mount_udf: udf.bin: Invalid argument root@hexagon:~ # mdconfig -a -f udf.bin root@hexagon:~ # mount_udf /dev/md0 /mnt/tmp mount_udf: /dev/md0: Invalid argument Did I miss anything? :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Sat Feb 1 19:13:44 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AED0B72D for ; Sat, 1 Feb 2014 19:13:44 +0000 (UTC) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E7441678 for ; Sat, 1 Feb 2014 19:13:44 +0000 (UTC) Received: from [98.139.212.150] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 19:13:35 -0000 Received: from [68.142.230.76] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 19:13:35 -0000 Received: from [127.0.0.1] by smtp233.mail.bf1.yahoo.com with NNFMP; 01 Feb 2014 19:13:35 -0000 X-Yahoo-Newman-Id: 944723.43309.bm@smtp233.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1CSpciQVM1kQZxztLYPxBowqT38dn3ySz8y7.FotdlVYsF1 haXNRakaDJmyQklg6Xym.Gs4bm8v4NtvujigAsp2pofQpWgtqbzOahn72Rnf .AFtpyX8zU22aqgd7LeDv48m47xP1hoUI8eexHdERFtR6TOmbsb1ogFReR2r pzb0718rQf_UqomGCm97GYONM0XIKS2mexw8_BDYUEq1sHXithnLaDTdIVh8 9huKyyicTc6bnZtkCqSwCZ.xc80hC1hEBj2cED6ZpK_QkHpih4OkuR_SAQb9 a1RX3vjRgeuRmap.vMVAqny3vbQdUlDmDjEWbNgvRGJrNUQOdistDIFPjkzI tKicI6NLCjn2ssyN218.PLUiIA5F04hRtgBye_sj3smvU9fT.4M6L5xeqdmh FRPJY4b11biiCW4kbf32l9fFjwbssd.B8QD.0tZMMsENfI9QMUz7jDW_z6Jf AE5Un3xC_FOEemz1WrextDdPa7r4YaHJdtA.PZwaU2vSrd5xv2HIkQgHWnUH EPxuh7VZelKQDbadFWPW1F.l2Upx4hjZWpK4S_8iLGuBlhYA3zPr4uk4- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [63.250.193.228]) by smtp233.mail.bf1.yahoo.com with SMTP; 01 Feb 2014 19:13:35 +0000 UTC Message-ID: <52ED475C.3050802@FreeBSD.org> Date: Sat, 01 Feb 2014 14:13:32 -0500 From: Pedro Giffuni Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: UFS(2) portable driver for other OS References: <52EC5B93.9010709@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 19:13:44 -0000 On 01/02/2014 12:38, Benjamin Kaduk wrote: > On Fri, 31 Jan 2014, Pedro Giffuni wrote: > >> I have some interest in resurrecting the MacOS X UFS1 support and >> perhaps get it to a point where it supports softupdates, but I don't >> know yet sufficient about kexts. > > I believe that OS X is moving towards requiring signed kexts; I don't > know whether your interest extends to paying for a code-signing > certificate. > I wouldn't but it would probably be something that the BSD community would crowdfund. It may even be a valid business: would BSD guys pay $2-5 through the Apple Store for a UFS driver? Of course if one wants to charge it would have to be pretty good and then the development model just becomes much more complex. Just a thought ... don't send money :-P, Pedro.