From owner-freebsd-fs@FreeBSD.ORG Sun Feb 13 02:16:53 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B56A0106564A; Sun, 13 Feb 2011 02:16:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3438FC0A; Sun, 13 Feb 2011 02:16:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1D2GrkO074991; Sun, 13 Feb 2011 02:16:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1D2Gri7074987; Sun, 13 Feb 2011 02:16:53 GMT (envelope-from linimon) Date: Sun, 13 Feb 2011 02:16:53 GMT Message-Id: <201102130216.p1D2Gri7074987@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154447: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 02:16:53 -0000 Old Synopsis: Occasional panics - solaris assert somewhere in ZFS code New Synopsis: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 13 02:16:32 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154447 From owner-freebsd-fs@FreeBSD.ORG Sun Feb 13 02:21:51 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF75A106566C; Sun, 13 Feb 2011 02:21:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B55BE8FC0C; Sun, 13 Feb 2011 02:21:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1D2LpYS084908; Sun, 13 Feb 2011 02:21:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1D2LpbG084904; Sun, 13 Feb 2011 02:21:51 GMT (envelope-from linimon) Date: Sun, 13 Feb 2011 02:21:51 GMT Message-Id: <201102130221.p1D2LpbG084904@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154681: [zfs] [panic] panic with FreeBSD-8 STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 02:21:52 -0000 Old Synopsis: panic with FreeBSD-8 STABLE New Synopsis: [zfs] [panic] panic with FreeBSD-8 STABLE Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 13 02:21:06 UTC 2011 Responsible-Changed-Why: Submitter suspects ZFS in this case. http://www.freebsd.org/cgi/query-pr.cgi?pr=154681 From owner-freebsd-fs@FreeBSD.ORG Sun Feb 13 21:07:16 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BDE2106566B for ; Sun, 13 Feb 2011 21:07:16 +0000 (UTC) (envelope-from pipatron@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF2058FC16 for ; Sun, 13 Feb 2011 21:07:15 +0000 (UTC) Received: by gyc15 with SMTP id 15so1848333gyc.13 for ; Sun, 13 Feb 2011 13:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=MPeJngEksFdC9Lt59qZewl8UxnXsqfmhOBr8q3A4cYI=; b=LB7jfzkW/SEtVG39n5RlsU4bF5ICJo4yKjIbtUraliOkRcaehq1HKrnOpsFVinoIuX qWfAUNq2bLf+N+B1XVk0QvWvr0XVGEinoT5VUkQBW2dwYny2G8i998jN1yZDNVnBPIm6 LO7oV3+q3/oiLNGNHQtkdHBbtEyQiv7VQ4ZRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u2zwtyLVZ6LV64e6QmdpmgqkdoIJ2oK3p7pw/0LHEgwt+NR7vCHpAAGUpB2tZUc0i0 forekTV0ElBJS7SQazosq9qgUxGaDMJKl/PHw0ZZj2Kfyt2lMRE1BSKOoSbiuyiEO6s7 3tGgb3JORjcVt4ZB7DkYoytUeYnmMEL5Iuc9A= MIME-Version: 1.0 Received: by 10.151.63.24 with SMTP id q24mr3347759ybk.385.1297629544042; Sun, 13 Feb 2011 12:39:04 -0800 (PST) Received: by 10.150.196.17 with HTTP; Sun, 13 Feb 2011 12:39:04 -0800 (PST) Date: Sun, 13 Feb 2011 21:39:04 +0100 Message-ID: From: Anders Andersson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Recover a ufs2 filesystem from a reformat with another ufs2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 21:07:16 -0000 Hi! I'm sorry if this has been brought up already but the search function in the archives seem to be broken (since 2007?) so I couldn't search for duplicates. A short summary of my problem: I am trying to recover files from a UFS2 file system that has been overwritten by a new UFS2 file system. A longer problem description: I'm trying to help a friend recover from a somewhat stupid mistake. He used a specialised distribution based on FreeBSD (FreeNAS), that among other things can manage harddrives and file systems. For reasons that he doesn't know, this tool formatted his old partition with a new UFS2 file system when he attached it, even though there was a perfectly fine one on the disk already. Now I'm trying to recover the files from the old one, but a problem is that the old one was also a UFS2 file system, so the tools I have tried only finds the new one. Now, being a linux guy with (unfortunately) very little experience of any of the BSDs, I am trying this out in linux with the tools I have, but it's not very easy. I don't know anything about UFS2 so I have some questions: 1) If an old file system is overwritten by a new file system with the same size, are there any traces of the old file system meta data left? I'm thinking randomized backup headers scattered throughout the file system, which would have a different location after each new format. 2) If there are no traces left of the old file system, would there be any UFS2-aware recovery programs that could scan the disk and try to regenerate the necessary meta data from, say, partition size, file offsets, some other magic...? 3) Are there any powerful tools availaible for tasks like this in FreeBSD that are not ported to Linux? In that case, I could easily install FreeBSD in a virtual machine and salvage the files there. 4) If everything else fails, can you recommend a good overview about UFS2, how and where the bits and pieces are stored on disk? Anything helps! // Anders From owner-freebsd-fs@FreeBSD.ORG Sun Feb 13 21:24:57 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 415F7106566C; Sun, 13 Feb 2011 21:24:57 +0000 (UTC) Date: Sun, 13 Feb 2011 21:24:57 +0000 From: Alexander Best To: Anders Andersson Message-ID: <20110213212457.GA26171@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-fs@freebsd.org Subject: Re: Recover a ufs2 filesystem from a reformat with another ufs2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 21:24:57 -0000 On Sun Feb 13 11, Anders Andersson wrote: > Hi! I'm sorry if this has been brought up already but the search > function in the archives seem to be broken (since 2007?) so I couldn't > search for duplicates. > > A short summary of my problem: I am trying to recover files from a > UFS2 file system that has been overwritten by a new UFS2 file system. > > A longer problem description: I'm trying to help a friend recover from > a somewhat stupid mistake. He used a specialised distribution based on > FreeBSD (FreeNAS), that among other things can manage harddrives and > file systems. For reasons that he doesn't know, this tool formatted > his old partition with a new UFS2 file system when he attached it, > even though there was a perfectly fine one on the disk already. Now > I'm trying to recover the files from the old one, but a problem is > that the old one was also a UFS2 file system, so the tools I have > tried only finds the new one. > > Now, being a linux guy with (unfortunately) very little experience of > any of the BSDs, I am trying this out in linux with the tools I have, > but it's not very easy. I don't know anything about UFS2 so I have > some questions: > > 1) If an old file system is overwritten by a new file system with the > same size, are there any traces of the old file system meta data left? > I'm thinking randomized backup headers scattered throughout the file > system, which would have a different location after each new format. > 2) If there are no traces left of the old file system, would there be > any UFS2-aware recovery programs that could scan the disk and try to > regenerate the necessary meta data from, say, partition size, file > offsets, some other magic...? > 3) Are there any powerful tools availaible for tasks like this in > FreeBSD that are not ported to Linux? In that case, I could easily > install FreeBSD in a virtual machine and salvage the files there. > 4) If everything else fails, can you recommend a good overview about > UFS2, how and where the bits and pieces are stored on disk? i'm no expert, but the very first thing your friend should do probably is 1) boot from a freebsd bootable dvd / memstick 2) dd if=/dev/overwritten_hdd of=/file/on_another_huge_hdd bs=1m 3) physically disconnect the overwritten hdd and do all further experiments via mdconfig(1). good luck. alex > > Anything helps! > > // Anders -- a13x From owner-freebsd-fs@FreeBSD.ORG Sun Feb 13 21:39:51 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBA69106566B for ; Sun, 13 Feb 2011 21:39:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5485F8FC15 for ; Sun, 13 Feb 2011 21:39:50 +0000 (UTC) Received: by wwf26 with SMTP id 26so4159852wwf.31 for ; Sun, 13 Feb 2011 13:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=mAL2nzV/hdT3a6Ji6RzRMGsmLNGl04fGQjN+tUW6nAY=; b=bnGOMr0xgOLwXXRHN+HYbcuWRw3HOqB9rkmpXcQekctEpMmKsPOtLX4GxwZ0kbv+g5 c+5zYJeNKQOR6k9CGaE2wPvJXtfoYbRQ0EdQw5R7t3n0T4qATkQMLCBxeeDHtgjxqbYo XHr9E6fGuv2p5SuE84ay41QyPshX54q1id+tU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XI0pT62B85XR+2FW5KoNUnbO7lLMiBOPz48WPJdefYX8NqQwhflSLNKY9iYinwcy5m /kId/tRAzqBJZfpiQJ6mxOG2qeplsOXhJhtqK35fxgVsxS0ulY7zrs/nTOTKjuY2dkGt EiYeVhCWV1eH5mTANsM4u6qvyX9XaXCnuUwto= MIME-Version: 1.0 Received: by 10.216.63.138 with SMTP id a10mr41286wed.27.1297633189995; Sun, 13 Feb 2011 13:39:49 -0800 (PST) Received: by 10.216.71.200 with HTTP; Sun, 13 Feb 2011 13:39:49 -0800 (PST) Date: Sun, 13 Feb 2011 13:39:49 -0800 Message-ID: From: Garrett Cooper To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: The history behind the undocumented NetBSD stat syscalls? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 21:39:51 -0000 Hi FS folks, I was poking through vfs_syscalls.c and I noticed that there was a syscall called nlstat, and nstat, and a kernel-public only helper function called cvtnstat: These aren't used anywhere in our source tree (I trimmed out the false positives -- i.e. connstat and instat), minus their declarations in kern/vfs_syscalls.c, etc: $ svngrep -Er 'nl?stat\(' /usr/src/ /usr/src/sys/kern/kern_descrip.c: cvtnstat(&ub, &nub); /usr/src/sys/kern/syscalls.master:278 AUE_STAT STD { int nstat(char *path, struct nstat *ub); } /usr/src/sys/kern/syscalls.master:280 AUE_LSTAT STD { int nlstat(char *path, struct nstat *ub); } /usr/src/sys/kern/vfs_syscalls.c:cvtnstat(sb, nsb) /usr/src/sys/kern/vfs_syscalls.c:nstat(td, uap) /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb); /usr/src/sys/kern/vfs_syscalls.c:nlstat(td, uap) /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb); /usr/src/sys/compat/freebsd32/syscalls.master:278 AUE_STAT NOPROTO{ int nstat(char *path, struct nstat *ub); } /usr/src/sys/compat/freebsd32/syscalls.master:280 AUE_LSTAT NOPROTO{ int nlstat(char *path, struct nstat *ub); } /usr/src/sys/sys/vnode.h:void cvtnstat(struct stat *sb, struct nstat *nsb); /usr/src/sys/sys/sysproto.h:int nstat(struct thread *, struct nstat_args *); /usr/src/sys/sys/sysproto.h:int nlstat(struct thread *, struct nlstat_args *); And seems like it should be superseded by lstat, et all, which were introduced a little earlier on [1]. Do they serve a real purpose of some kind today? It was introduced in the revision seen in SVN here [2], and looking back in time there isn't reference to a NetBSD compat layer in sys/conf/options [3], etc, so I was a bit curious why there are dangling undocumented (but publicly visible via sysproto.h) VFS-related syscalls entries hanging around (in particular because the syscalls aren't declared that way in NetBSD either). Thanks! -Garrett 1. http://svn.freebsd.org/viewvc/base/head/sys/kern/vfs_syscalls.c?revision=24438&view=markup 2. http://svn.freebsd.org/viewvc/base/head/sys/kern/vfs_syscalls.c?revision=35938&view=markup 3. http://svn.freebsd.org/viewvc/base/head/sys/conf/options?view=log From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 00:36:01 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48F4C106566B for ; Mon, 14 Feb 2011 00:36:01 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C70F68FC16 for ; Mon, 14 Feb 2011 00:36:00 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PomQ3-0000Xn-Ls for freebsd-fs@freebsd.org; Mon, 14 Feb 2011 01:35:59 +0100 Received: from cpe-188-129-78-62.dynamic.amis.hr ([188.129.78.62]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Feb 2011 01:35:59 +0100 Received: from ivoras by cpe-188-129-78-62.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Feb 2011 01:35:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Mon, 14 Feb 2011 01:35:44 +0100 Lines: 52 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-78-62.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: Subject: Re: Recover a ufs2 filesystem from a reformat with another ufs2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 00:36:01 -0000 On 13/02/2011 21:39, Anders Andersson wrote: > 1) If an old file system is overwritten by a new file system with the > same size, are there any traces of the old file system meta data left? > I'm thinking randomized backup headers scattered throughout the file > system, which would have a different location after each new format. No, not randomized at all, unfortunately for your purpose - there are copies of superblocks, but all important data is on precisely deterministic positions for somewhat the same reasons - to help recovery in case parts of it are missing. > 2) If there are no traces left of the old file system, would there be > any UFS2-aware recovery programs that could scan the disk and try to > regenerate the necessary meta data from, say, partition size, file > offsets, some other magic...? Yes, there are tools which scan the entire drive / partition and try to identify blocks which look like directories and files, but then you need to recover inodes. Fortunately, not all inodes are pre-initializes in UFS2, some may be salvagable. In any case, I don't predict much success. The process would use some of the same tools like "undeleting" files, see * http://www.google.com/search?q=freebsd+undelete * http://www.google.com/search?q=freebsd+recover+filesystem (it's been a long time I tried something similar, I don't know which tools I used). > 3) Are there any powerful tools availaible for tasks like this in > FreeBSD that are not ported to Linux? In that case, I could easily > install FreeBSD in a virtual machine and salvage the files there. Not likely. > 4) If everything else fails, can you recommend a good overview about > UFS2, how and where the bits and pieces are stored on disk? That would be a very complicated but also very interesting way to learn in extreme details about a file system :) I don't know of any online description of UFS2 (note: "UFS" systems are slightly different in all BSDs and very different in Solaris) except the sources but if you can find this book it will probably help you get started quickly: http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0201702452 In any case, as others said, DO NOT WORK ON THE "LIVE" HARD DRIVE. Make a copy image of it. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 01:33:38 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08B3106566C for ; Mon, 14 Feb 2011 01:33:38 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc4-s23.bay0.hotmail.com (bay0-omc4-s23.bay0.hotmail.com [65.54.190.225]) by mx1.freebsd.org (Postfix) with ESMTP id DAD9F8FC08 for ; Mon, 14 Feb 2011 01:33:38 +0000 (UTC) Received: from BAY147-W28 ([65.54.190.199]) by bay0-omc4-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Feb 2011 17:21:38 -0800 Message-ID: X-Originating-IP: [66.189.65.82] From: Roger Hammerstein To: Date: Sun, 13 Feb 2011 20:21:39 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2011 01:21:38.0945 (UTC) FILETIME=[87616F10:01CBCBE5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ext2fs can't read symlinks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 01:33:39 -0000 Hello. I have a 2tb Seagate ST32000542AS (4k sectors) with ext2fs that can't seem to read symlinks from a linux-created ext2fs. =20 I was rsync migrating files from a linux machine to this freebsd=2C and boo= ted an Ubuntu livecd to partition the disk and make the filesystem. I partitio= ned it into a 1.5tb partition and a 500 gig partition. I am getting read errors on some symlinks on an ext2 filesystem=2C but they read fine when I boot an Ubuntu live cd. Smartctl shows no errors for the = disk. The filesystem also checks fine with fsck.ext2fs on both freebsd and Ubuntu= live cd. I rebuilt the kernel earlier this week. FreeBSD butter 9.0-CURRENT FreeBSD 9.0-CURRENT #10: Wed Feb 9 12:14:02 EST=20 2011 root@butter:/usr/obj/usr/src/sys/GENERIC amd64 Here's the error: Feb 10 13:08:23 butter kernel: g_vfs_done():ada2s1[READ(offset=3D-963020587= 008=2C length=3D4096)]error =3D 5 The negative offset looks wrong=2C and the length is always 4k multiples. ada2 at siisch2 bus 0 scbus2 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: Serial Number XXXXXXXXX ada2: 300.000MB/s transfers (SATA 2.x=2C UDMA6=2C PIO 8192bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) mount: /dev/ada2s1 on /a (ext2fs=2C local) ls -la in the problem directory shows: drwxrwxrwx 2 2006 113 4096 May 18 2008 ABC drwxrwxrwx 2 2006 113 4096 May 18 2008 DEF drwxrwxrwx 4 2006 113 4096 May 18 2008 GHI ls: ./JKL: Input/output error lrwxrwxrwx 1 2006 2006 83 Jul 13 2005 JKL drwxrwxrwx 4 2006 113 4096 May 18 2008 JKL [123456] drwxrwxrwx 2 2006 113 4096 May 18 2008 MNO There's a symlink named JKL pointing into the 'JKL [123456]' directory. a 'stat *' in the directory shows the link:: 100 75431952 lrwxrwxrwx 1 (1008) (1008) 301758464 83 "Feb 10 12:35:36 2011" "Jul 13 22:35:44 2005" "Feb 7 18:49:02 2011" "Dec 31 18:59:59 1969"=20 4096 8 0 JKL 100 62201925 drwxrwxrwx 4 (1008) (503) 248838206 4096=20 "Feb 10 13:10:22 2011" "May 18 04:06:20 2008" "Feb 7 18:58:26 2011"=20 "Dec 31 18:59:59 1969" 4096 8 0 JKL [123456] You can see that the symlink doesn't display the usual "-> " and the target= of the symlink in the ls or stat output. What other commands could I run to provide more information on this? Other symlinks on this filesystem also generate the g_vfs_done errors. Thanks. = From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 04:04:51 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80059106564A for ; Mon, 14 Feb 2011 04:04:51 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from web113513.mail.gq1.yahoo.com (web113513.mail.gq1.yahoo.com [98.136.167.53]) by mx1.freebsd.org (Postfix) with SMTP id 2F7618FC08 for ; Mon, 14 Feb 2011 04:04:50 +0000 (UTC) Received: (qmail 13184 invoked by uid 60001); 14 Feb 2011 03:38:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297654689; bh=8uKY+/uJcrgCo5zOFyGZy7VsFq7S8eYKvX9KbsFEoxk=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=xwG9N92uFc8+nSUrfIY3yTUoc+GO2/W6OC4lRDw6UPPKBBke67U78UeZp6kBeyAyeB2lyEZ7bTYMoBj6BDIw4qLADY9bToWCik+X7e/CA3914gyn+WE20Ptmn0D9RuFdCPfWXexDZ2WfzAxwauKYtxJ5MZGQjnUzh7yJroQ8M+g= Message-ID: <116952.12062.qm@web113513.mail.gq1.yahoo.com> X-YMail-OSG: i6_nu9YVM1lhr4fDyx8chRZfo_8k8BKd3btRuHSiaYia9hb sCtdigmZ0PrhzT0sEdDg8JUtSTlVM.GAa7MGZ_f6TCrn2JnOPNPYVtT93.Nv 0ZmRBQ5Ag2nxdW1pFcCkl_5SDtkuGPAWX2_wPUBvMppmxS6_wEiFoUEiK2iF wGVCTYQIFGcXZo7dmw7yaj7Acqf1bLkvQW8FqnXDMPSGD3fvdhdl1.6boyPR 7AisHN4xL5kk.tRl3hR8Dy0MCKkieDgewEQZ7uS3sw_Gd6rXtsZLxtDk8R1g Zk6_2i2skKOdK_Vr0.2TjdRTR8MujlgMrcCd66yC5xW.Wua4sM.sMfydInBr zKdDYswgkrNqnGTiPDRGAt3wsFkMM6QHUJHBXQxDWAdvNcuBKM488XwM7iMu 4Vc.quvvc8buwydzsxw-- Received: from [190.157.140.248] by web113513.mail.gq1.yahoo.com via HTTP; Sun, 13 Feb 2011 19:38:09 PST X-RocketYMMF: giffunip X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 Date: Sun, 13 Feb 2011 19:38:09 -0800 (PST) From: "Pedro F. Giffuni" To: Roger Hammerstein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org Subject: Re: ext2fs can't read symlinks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 04:04:51 -0000 Thanks for the report Roger, Can you try creating a symlink in the same fs using FreeBSD to see if it's valid? cheers, Pedro. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 04:55:21 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 231FF1065679 for ; Mon, 14 Feb 2011 04:55:21 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc1-s26.bay0.hotmail.com (bay0-omc1-s26.bay0.hotmail.com [65.54.190.37]) by mx1.freebsd.org (Postfix) with ESMTP id 0E1A78FC55 for ; Mon, 14 Feb 2011 04:55:20 +0000 (UTC) Received: from BAY147-W59 ([65.54.190.61]) by bay0-omc1-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Feb 2011 20:55:20 -0800 Message-ID: X-Originating-IP: [66.189.65.82] From: Roger Hammerstein To: Date: Sun, 13 Feb 2011 23:55:20 -0500 Importance: Normal In-Reply-To: <116952.12062.qm@web113513.mail.gq1.yahoo.com> References: <116952.12062.qm@web113513.mail.gq1.yahoo.com> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2011 04:55:20.0727 (UTC) FILETIME=[61C21A70:01CBCC03] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: RE: ext2fs can't read symlinks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 04:55:21 -0000 > Can you try creating a symlink in the same fs using > FreeBSD to see if it's valid? If i create a symlink booted into FreeBSD it works just fine=2C without any errors. =20 Thanks! = From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 05:31:21 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82AF5106564A for ; Mon, 14 Feb 2011 05:31:21 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm22.bullet.mail.sp2.yahoo.com (nm22.bullet.mail.sp2.yahoo.com [98.139.91.92]) by mx1.freebsd.org (Postfix) with SMTP id 5CC1C8FC22 for ; Mon, 14 Feb 2011 05:31:21 +0000 (UTC) Received: from [98.139.91.69] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 14 Feb 2011 05:17:49 -0000 Received: from [98.139.91.8] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 14 Feb 2011 05:17:49 -0000 Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 14 Feb 2011 05:17:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 745533.37418.bm@omp1008.mail.sp2.yahoo.com Received: (qmail 48230 invoked by uid 60001); 14 Feb 2011 05:17:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297660669; bh=rfKdRwnbIbUbrcAFehGeURCnBNNypgG+vzLrrBLI8Ic=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W/JTfvmk1jJYv1Rek8TTrQAQCTKCjTRhnwiKWFEchyv54qZESbTO+W8f21MBnUuZA/Gn/VusKTkwDDYU+jjIORXN7KKchvMi/VdWkE7GAQbmh/lbpgUpqqBKPw2Jv9yp8+Mlb1OYtl9ImBg7R7ZNfRgzCViV8ncVaxX3WVZflQc= Message-ID: <237278.48223.qm@web113517.mail.gq1.yahoo.com> X-YMail-OSG: 91o5tgwVM1k7gdUVQqRMW6ZDbU4NSa9hcUv4oG14PlCAvfN t5hYiLWn_YC_E1eUUoL8vuaGXQtx5LxwrFg4397wZFJOvg4A6htbSo3tfK8d ry09xR7mlwoXWj71nNo5C904gfFt3cxna6yPIV7RvxQHPOQDs6rOt07FsmHr H506OG5sEN0cZgmmTN3czlbHrj_5IsfMBA3uaJYhWK3V3y3ssMwHW.OlXtfb Ln0y1K24U6lcCVPBcrqRON1pWFknIfCpfYXbbl_ASGobVaD199.uGPzFa.FV d9Atgwj4HJ5CDyT1gyOHPyBmk.NQYNScIrTMACfTkSkFcFOKpFXx7RWMU56B qM8F23wiTRKfUzY38belCAe45iSLnTkLMZPAUfAL6NL8sLBeJ6YbwFeHpg21 mPtWEUcrVuI.z7A-- Received: from [190.157.140.248] by web113517.mail.gq1.yahoo.com via HTTP; Sun, 13 Feb 2011 21:17:48 PST X-RocketYMMF: giffunip X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 References: <116952.12062.qm@web113513.mail.gq1.yahoo.com> Date: Sun, 13 Feb 2011 21:17:48 -0800 (PST) From: "Pedro F. Giffuni" To: Roger Hammerstein In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs can't read symlinks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 05:31:21 -0000 Thanks!=0A=0A>=0A>From: Roger Hammerstein=0A...=0A>=0A>> Can you try creati= ng a symlink in the same fs using=0A>> FreeBSD to see if it's valid?=0A>=0A= >If i create a symlink booted into FreeBSD it works just fine,=0A>without a= ny errors.=A0 =0A>=0A=0AI think linux is using an ext2 extension called "fa= st" symlinks.=0ANo easy solution, unless you have patience to redo all your= =0Ashort links on FreeBSD but please submit a PR so the people=0Acurrently = working on ext2fs remember to implement it.=0A=0Acheers,=0A=0APedro.=0A=0A= =0A=0A From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 06:34:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4F2F106566C for ; Mon, 14 Feb 2011 06:34:12 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7384D8FC17 for ; Mon, 14 Feb 2011 06:34:12 +0000 (UTC) Received: by eyf6 with SMTP id 6so2158174eyf.13 for ; Sun, 13 Feb 2011 22:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=XIWDj3zNPnTyYTpRYLnU+79caLL9OEk8++Wlp5kXwsc=; b=aJPFN+tmkkYM477aFeVsF0CS1GMBmeYST4JYq3iy9Wy0Uac8J04tIkjLzlBGnu92vb DxgaSMPZJEhxD8vUEKpg3iXMNCKZrXH9PtDlf0EKZ+ebMqzVKCB+QFMXVAgSuVjdIKJW cVWfzy+CAZ+xZsBCzvw3LVhGaLatYC1pRaTbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=owNymmUy0pvEnQK+e3RC6v1RmqGrk6Dx2KI/hta0/eT38cArQpXZRtUdi1j1E+fOxQ DRj1XtG/+L+HOZOFX9RY+pIEDHuWl9FSm+gxHHN7sfe8Xuzjte1ZNZVi15fSBmg8EDxr AWcYb2vlBghdBxsNtoQaHR+RvmsqAqGBFjBJ4= Received: by 10.213.7.67 with SMTP id c3mr3446821ebc.68.1297665250859; Sun, 13 Feb 2011 22:34:10 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id x54sm2162884eeh.17.2011.02.13.22.34.09 (version=SSLv3 cipher=OTHER); Sun, 13 Feb 2011 22:34:10 -0800 (PST) Date: Mon, 14 Feb 2011 08:33:37 +0200 From: Gleb Kurtsou To: Garrett Cooper Message-ID: <20110214063337.GB4241@tops> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: The history behind the undocumented NetBSD stat syscalls? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 06:34:13 -0000 On (13/02/2011 13:39), Garrett Cooper wrote: > Hi FS folks, > I was poking through vfs_syscalls.c and I noticed that there was a > syscall called nlstat, and nstat, and a kernel-public only helper > function called cvtnstat: > These aren't used anywhere in our source tree (I trimmed out the > false positives -- i.e. connstat and instat), minus their declarations > in kern/vfs_syscalls.c, etc: > > $ svngrep -Er 'nl?stat\(' /usr/src/ > /usr/src/sys/kern/kern_descrip.c: cvtnstat(&ub, &nub); > /usr/src/sys/kern/syscalls.master:278 AUE_STAT STD { int nstat(char > *path, struct nstat *ub); } > /usr/src/sys/kern/syscalls.master:280 AUE_LSTAT STD { int nlstat(char > *path, struct nstat *ub); } > /usr/src/sys/kern/vfs_syscalls.c:cvtnstat(sb, nsb) > /usr/src/sys/kern/vfs_syscalls.c:nstat(td, uap) > /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb); > /usr/src/sys/kern/vfs_syscalls.c:nlstat(td, uap) > /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb); > /usr/src/sys/compat/freebsd32/syscalls.master:278 AUE_STAT NOPROTO{ > int nstat(char *path, struct nstat *ub); } > /usr/src/sys/compat/freebsd32/syscalls.master:280 AUE_LSTAT NOPROTO{ > int nlstat(char *path, struct nstat *ub); } > /usr/src/sys/sys/vnode.h:void cvtnstat(struct stat *sb, struct nstat *nsb); > /usr/src/sys/sys/sysproto.h:int nstat(struct thread *, struct nstat_args *); > /usr/src/sys/sys/sysproto.h:int nlstat(struct thread *, struct nlstat_args *); > > And seems like it should be superseded by lstat, et all, which > were introduced a little earlier on [1]. > Do they serve a real purpose of some kind today? It was introduced > in the revision seen in SVN here [2], and looking back in time there > isn't reference to a NetBSD compat layer in sys/conf/options [3], etc, > so I was a bit curious why there are dangling undocumented (but > publicly visible via sysproto.h) VFS-related syscalls entries hanging > around (in particular because the syscalls aren't declared that way in > NetBSD either). These were dropped by Dragonfly as not being used. NetBSD is no longer compatible with them, afair. freebsd32 compatibility shims are incorrect, which means that nobody ever used them. If you are interested, I have a patch marking them COMPAT8 and OBSOL for freebsd32, it's part of larger set of changes to make ino_t 64 bit: https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch-2011-01-20.tgz > Thanks! > -Garrett > > 1. http://svn.freebsd.org/viewvc/base/head/sys/kern/vfs_syscalls.c?revision=24438&view=markup > 2. http://svn.freebsd.org/viewvc/base/head/sys/kern/vfs_syscalls.c?revision=35938&view=markup > 3. http://svn.freebsd.org/viewvc/base/head/sys/conf/options?view=log > _______________________________________________ > 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 Mon Feb 14 07:45:02 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AFF5106566B for ; Mon, 14 Feb 2011 07:45:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id B69FA8FC08 for ; Mon, 14 Feb 2011 07:45:01 +0000 (UTC) Received: from c122-107-114-89.carlnfd1.nsw.optusnet.com.au (c122-107-114-89.carlnfd1.nsw.optusnet.com.au [122.107.114.89]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1E7itkF028900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Feb 2011 18:44:57 +1100 Date: Mon, 14 Feb 2011 18:44:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Cooper In-Reply-To: Message-ID: <20110214182441.X1003@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org Subject: Re: The history behind the undocumented NetBSD stat syscalls? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 07:45:02 -0000 On Sun, 13 Feb 2011, Garrett Cooper wrote: > I was poking through vfs_syscalls.c and I noticed that there was a > syscall called nlstat, and nstat, and a kernel-public only helper > function called cvtnstat: > These aren't used anywhere in our source tree (I trimmed out the > false positives -- i.e. connstat and instat), minus their declarations > in kern/vfs_syscalls.c, etc: I think these are the "new" stat() syscalls in 4.4BSD. Ones using struct ostat are normal "old" stat calls. But normality is reversed in FreeBSD. FreeBSD was forced to make a clean break with FreeBSD-1, and from FreeBSD-2 on it didn't have the the "old" stat calls. Until someone made a mess by importing anachronous bits from NetBSD. Both nstat() and ostat() might be useful for binary compatibilty with NetBSD, but I think there are too many other differences for actual usefulness. NetBSD in 2005 has even more "old" stat structs and corresponding syscalls. They are named a little differently: o struct stat43, for 4.3BSD (Net/2, 386BSD, FreeBSD-1?). This is under a _KERNEL ifdef as it should be. This lets the kernel support it but prevents current sources from using it. The corresponding ifdef in FreeBSD is wrong -- it is __BSD_VISIBLE. So we have the silly situation that FreeBSD makes visible old NetBSD interfaces that NetBSD doesn't make visible. FreeBSD does better with its own "old" structs, e.g., struct ostatfs. struct stat43 seems to be compatible with struct ostat. These are really old. They have 16-bit uids and gids, which are correctly implemented by spelling their types as __uint16_t (except in NetBSD there is namespace pollution by spelling this as u_int16_t). Some of the other fields are not so carefully handled (using non-fixed-width typedefs which are not binary compatible with the future), so it is hard to see if their types are actually the same: - st_ino has type ino_t in both - FreeBSD uses non-fixed-width types for st_mode, st_nlink and st_flags. o struct stat12, for NetBSD-1.2. This is under __LIBC12 || _KERNEL. It uses non-fixed-width types more. It seems to be compatible with FreeBSD struct stat and struct nstat, except FreeBSD has st_birthtime and the end where NetBSD has 2 int64_t spares, and none of these struct is careful enough about padding to ensure binary compatibility on all possible arches. o struct stat, for NetBSD (2005). This uses more non-fixed-width type but is otherwise more careful about padding, using methods that I don't like (it restores the old timespec ifdefs, which have longs which cause padding problems...). This now has st_birthtime, so FreeBSD struct stat might be fully compatible with it, but the wide use of non-fixed-width types and different padding methods make this unclear. This size of struct timespec is arch-dependent, so no one has binary compatibility across arches despite most of the typedefs reducing to the same fixed-width types (time_t and long within struct timespec are the main or only exceptions; `long' there is a historical mistake that was unfortunately standardized). > $ svngrep -Er 'nl?stat\(' /usr/src/ > /usr/src/sys/kern/kern_descrip.c: cvtnstat(&ub, &nub); > /usr/src/sys/kern/syscalls.master:278 AUE_STAT STD { int nstat(char > *path, struct nstat *ub); } > /usr/src/sys/kern/syscalls.master:280 AUE_LSTAT STD { int nlstat(char > *path, struct nstat *ub); } Since they are in syscalls.master... > /usr/src/sys/kern/vfs_syscalls.c:cvtnstat(sb, nsb) > /usr/src/sys/kern/vfs_syscalls.c:nstat(td, uap) > /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb); > /usr/src/sys/kern/vfs_syscalls.c:nlstat(td, uap) > /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb); ...and not under any COMPAT* ifdef in vfs_syscalls.c (?), they can be used by any binary that wants to use them. > And seems like it should be superseded by lstat, et all, which > were introduced a little earlier on [1]. > Do they serve a real purpose of some kind today? It was introduced > in the revision seen in SVN here [2], and looking back in time there > isn't reference to a NetBSD compat layer in sys/conf/options [3], etc, > so I was a bit curious why there are dangling undocumented (but > publicly visible via sysproto.h) VFS-related syscalls entries hanging > around (in particular because the syscalls aren't declared that way in > NetBSD either). sysproto.h isn't public (it is kernel-only). The only publication errors seem to be the declarations in sys/stat.h discussed above, and the SYS_* entries in sys/syscall.h (old syscalls are supposed to by marked up in syscalls.master so that they don't escape). SYS_nstat is 278, which is for __stat13 in NetBSD, so it has a chance of working. SYS_ostat is 38 (except it is intentionally not defined in syscall.h, which is for compat_43_stat43 in NetBSD, so it too has a chance of working. Ordinary SYS_stat is 188 in FreeBSD, but in NetBSD #188 is compat_12_stat12. These seem to differe mainly in support for st_birthtime. FreeBSD didn't change the syscall for st_birthtime, but this shouldn't cause problems since stat() is read-only so there is no problem with callers passing garbage in st_birthtime. Bruce From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 11:07:04 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22215106571D for ; Mon, 14 Feb 2011 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E7DC28FC1C for ; Mon, 14 Feb 2011 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1EB73Zd077171 for ; Mon, 14 Feb 2011 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1EB73u0077169 for freebsd-fs@FreeBSD.org; Mon, 14 Feb 2011 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Feb 2011 11:07:03 GMT Message-Id: <201102141107.p1EB73u0077169@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 Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 11:07:04 -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/154681 fs [zfs] [panic] panic with FreeBSD-8 STABLE o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew f 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/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf 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/153552 fs [zfs] zfsboot from 8.2-RC1 freeze at boot time o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable 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 kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152079 fs [msdosfs] [patch] Small cleanups from the other NetBSD 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 kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un 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/151111 fs [zfs] vnodes leakage during zfs unmount 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/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state 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 bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload 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/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take 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/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs 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 o 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 o kern/144458 fs [nfs] [patch] nfsd fails as a kld 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/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real 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/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD 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/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( 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/140134 fs [msdosfs] write and fsck destroy filesystem integrity 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/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high 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/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic 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 o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int 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/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 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 bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat 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 bin/118249 fs [ufs] mv(1): moving a directory changes its mtime 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/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o 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 kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes 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 bin/94635 fs snapinfo(8)/libufs only works for disk-backed filesyst 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 kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash 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 221 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 15:43:38 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4747A1065672 for ; Mon, 14 Feb 2011 15:43:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id B9DA58FC1B for ; Mon, 14 Feb 2011 15:43:37 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p1EFhKY3087341; Mon, 14 Feb 2011 16:43:35 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p1EFhKwi087340; Mon, 14 Feb 2011 16:43:20 +0100 (CET) (envelope-from olli) Date: Mon, 14 Feb 2011 16:43:20 +0100 (CET) Message-Id: <201102141543.p1EFhKwi087340@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Mon, 14 Feb 2011 16:43:36 +0100 (CET) Cc: Subject: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:43:38 -0000 Hi! I've bought a small external disk (2.5", 1 TB) to use for my media player in the living room. My plan is to connect it to my FreeBSD 8 workstation in order to fill and update it. The media player is Linux-based, so I can't use UFS. Even worse, it refuses to mount ext2, while ext3 seems to work fine. So my only choice is to format the disk with ext3, because FAT has a 4 GB limit and NTFS is unsupported on FreeBSD for practical purposes. Now here's my question: Are there any problems to be expected when mounting an ext3fs partition alternately on a Linux machine and a FreeBSD machine? Both will mount it read+write (the media player writes some index or cache files to it). As far as I know, FreeBSD supports ext2 only, and even though ext3 is supposed to be backwards compatible, FreeBSD doesn't know how to handle the ext3 journal. Can this cause any problems in the long run? Would it help to run fsck.ext3 from the sysutils/e2fsprogs port every time after I have updated the file system on my FreeBSD machine? (The media player has fsck, too, but it seems to run out of memory on the 1 TB disk.) Any advice would be highly appreciated. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." -- Dick Brandon From owner-freebsd-fs@FreeBSD.ORG Mon Feb 14 16:36:11 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD7B9106564A for ; Mon, 14 Feb 2011 16:36:11 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6B58FC16 for ; Mon, 14 Feb 2011 16:36:11 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p1EGZsFQ089157; Mon, 14 Feb 2011 17:36:09 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p1EGZsDI089156; Mon, 14 Feb 2011 17:35:54 +0100 (CET) (envelope-from olli) Date: Mon, 14 Feb 2011 17:35:54 +0100 (CET) Message-Id: <201102141635.p1EGZsDI089156@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, pipatron@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Mon, 14 Feb 2011 17:36:10 +0100 (CET) Cc: Subject: Re: Recover a ufs2 filesystem from a reformat with another ufs2 ?filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, pipatron@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:36:11 -0000 Anders Andersson wrote: > A short summary of my problem: I am trying to recover files from a > UFS2 file system that has been overwritten by a new UFS2 file system. Maybe the following post might be helpful: http://lists.freebsd.org/pipermail/freebsd-fs/2007-November/003981.html Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 09:08:00 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61A59106564A for ; Tue, 15 Feb 2011 09:08:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC838FC08 for ; Tue, 15 Feb 2011 09:07:59 +0000 (UTC) Received: from outgoing.leidinger.net (p5B32E668.dip.t-dialin.net [91.50.230.104]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 57796844012; Tue, 15 Feb 2011 09:48:51 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 4727B2441; Tue, 15 Feb 2011 09:48:48 +0100 (CET) Date: Tue, 15 Feb 2011 09:48:46 +0100 From: Alexander Leidinger To: Oliver Fromme Message-ID: <20110215094846.000014ba@unknown> In-Reply-To: <201102141543.p1EFhKwi087340@lurza.secnetix.de> References: <201102141543.p1EFhKwi087340@lurza.secnetix.de> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 57796844012.A4EEA X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.2, required 6, autolearn=disabled, ALL_TRUSTED -1.00, J_CHICKENPOX_32 0.60, J_CHICKENPOX_45 0.60) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1298364533.56564@RCJhoaP07FA82LjHuGGQEg X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 09:08:00 -0000 On Mon, 14 Feb 2011 16:43:20 +0100 (CET) Oliver Fromme wrote: > The media player is Linux-based, so I can't use UFS. Even > worse, it refuses to mount ext2, while ext3 seems to work > fine. So my only choice is to format the disk with ext3, > because FAT has a 4 GB limit and NTFS is unsupported on > FreeBSD for practical purposes. The sysutils/fusefs-ntfs port does not work for you? > Now here's my question: Are there any problems to be > expected when mounting an ext3fs partition alternately on > a Linux machine and a FreeBSD machine? Both will mount it > read+write (the media player writes some index or cache > files to it). > > As far as I know, FreeBSD supports ext2 only, and even > though ext3 is supposed to be backwards compatible, FreeBSD > doesn't know how to handle the ext3 journal. Can this > cause any problems in the long run? There is some GSoC code in P4 which made some extensions regarding ext3/ext4 (see http://wiki.freebsd.org/SOC2010ZhengLiu). The author is probably able to tell you more what you can expect from the code in 8.x and his extensions. Bye, Alexander. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 09:20:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 557181065673 for ; Tue, 15 Feb 2011 09:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2B20B8FC1D for ; Tue, 15 Feb 2011 09:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1F9KBjf040015 for ; Tue, 15 Feb 2011 09:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1F9KBbs040012; Tue, 15 Feb 2011 09:20:11 GMT (envelope-from gnats) Date: Tue, 15 Feb 2011 09:20:11 GMT Message-Id: <201102150920.p1F9KBbs040012@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Robert Schulze Cc: Subject: Re: kern/154681: [zfs] [panic] panic with FreeBSD-8 STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Schulze List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 09:20:12 -0000 The following reply was made to PR kern/154681; it has been noted by GNATS. From: Robert Schulze To: bug-followup@freebsd.org Cc: Subject: Re: kern/154681: [zfs] [panic] panic with FreeBSD-8 STABLE Date: Tue, 15 Feb 2011 10:12:56 +0100 Hi, today once again a panic - the same situation. Today I viewed the whole output of "ps" and I can confirm that the panic is in the process "zfskern". with kind regards, Robert Schulze From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 11:51:16 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54615106566B for ; Tue, 15 Feb 2011 11:51:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BE77A8FC1F for ; Tue, 15 Feb 2011 11:51:15 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p1FBoxSl033905; Tue, 15 Feb 2011 12:51:14 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p1FBoxwe033904; Tue, 15 Feb 2011 12:50:59 +0100 (CET) (envelope-from olli) Date: Tue, 15 Feb 2011 12:50:59 +0100 (CET) Message-Id: <201102151150.p1FBoxwe033904@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, Alexander@leidinger.net In-Reply-To: X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Tue, 15 Feb 2011 12:51:14 +0100 (CET) Cc: Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 11:51:16 -0000 Alexander Leidinger wrote: > Oliver Fromme wrote: > > The media player is Linux-based, so I can't use UFS. Even > > worse, it refuses to mount ext2, while ext3 seems to work > > fine. So my only choice is to format the disk with ext3, > > because FAT has a 4 GB limit and NTFS is unsupported on > > FreeBSD for practical purposes. > > The sysutils/fusefs-ntfs port does not work for you? It is slow. I mean *REALLY* slow, it's basically unusable. Remember I'm trying to fill and update a 1 TB disk here with video files that are typically several GB in size. The disk will have reached the end of its warranty before the data transfer is completed. I have specifically bought an external enclosure that also has eSATA (beside USB2) so I have the full head-to-platter bandwidth of the disk. But the FUSE NTFS driver is not much faster than USB1 (this is not the fault of FUSE, in fact the ntfscp tool from the sysutils/ntfsprogs port is just as slow). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 12:15:13 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF241065670 for ; Tue, 15 Feb 2011 12:15:13 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward14.mail.yandex.net (forward14.mail.yandex.net [95.108.130.92]) by mx1.freebsd.org (Postfix) with ESMTP id C023A8FC1C for ; Tue, 15 Feb 2011 12:15:12 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward14.mail.yandex.net (Yandex) with ESMTP id 6BE625D9806B; Tue, 15 Feb 2011 14:59:53 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1297771193; bh=MRaPPHUW1c7eKqkJrpeESU+Sdxc3b7S3tjZhMpUo5cw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=J6mNY3rwdGQJY5khSjjPvi1aFFrvlyY0pa4TOWzYNfKs9Mu7vOgB2Ij0NaHbRJ/+y I0nv2dmAB5QnVfvdM01Wtf6RkrUpLNcgyzjIq7JtRj7UdZUpe1eESA7x8fE0jZyHq6 /afBjWJMJ/MgICcQZOi0wBO+hX+5Cpxjz6XehRIU= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp13.mail.yandex.net (Yandex) with ESMTPSA id 22FA238980A9; Tue, 15 Feb 2011 14:59:53 +0300 (MSK) Message-ID: <4D5A6AB8.5000107@yandex.ru> Date: Tue, 15 Feb 2011 14:59:52 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Oliver Fromme References: <201102151150.p1FBoxwe033904@lurza.secnetix.de> In-Reply-To: <201102151150.p1FBoxwe033904@lurza.secnetix.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG, Alexander@leidinger.net Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 12:15:13 -0000 On 15.02.2011 14:50, Oliver Fromme wrote: > I have specifically bought an external enclosure that also > has eSATA (beside USB2) so I have the full head-to-platter > bandwidth of the disk. But the FUSE NTFS driver is not > much faster than USB1 (this is not the fault of FUSE, > in fact the ntfscp tool from the sysutils/ntfsprogs port > is just as slow). Some time ago i did a copy of 80G of data from my computer to external USB2 disk. The average speed was around 25-35 MB/s. It seems not so bad as you told. -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 12:19:28 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F231D106566B for ; Tue, 15 Feb 2011 12:19:28 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id A86988FC19 for ; Tue, 15 Feb 2011 12:19:28 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id BA882A765 for ; Tue, 15 Feb 2011 13:19:25 +0100 (CET) Date: Tue, 15 Feb 2011 13:19:17 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20110215121917.GA12068@roberto-al.eurocontrol.fr> References: <201102141543.p1EFhKwi087340@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102141543.p1EFhKwi087340@lurza.secnetix.de> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Tue, 15 Feb 2011 13:19:25 +0100 (CET) Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 12:19:29 -0000 According to Oliver Fromme: > because FAT has a 4 GB limit and NTFS is unsupported on > FreeBSD for practical purposes. FAT32 ought to be able to get over that 4 GB limit, does it? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 12:23:37 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF77106566B for ; Tue, 15 Feb 2011 12:23:37 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward8.mail.yandex.net (forward8.mail.yandex.net [77.88.61.38]) by mx1.freebsd.org (Postfix) with ESMTP id EFFE88FC08 for ; Tue, 15 Feb 2011 12:23:36 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward8.mail.yandex.net (Yandex) with ESMTP id 5FE922200452; Tue, 15 Feb 2011 15:23:21 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1297772601; bh=bUmRc5Tr5Bkbdk72xvPpCXpRPA97ERHYPxNxV8HCuv8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=c3j7FSpc+ClbS4nXJhN78p5sYoVgPREAHm+hVaRtrQXMifALB5555+F7lC5p9Gipe Sf/jMFBJb7CQXOB63B3bQWtg8suByldqRuAzXDK2xvn7GOjgSU+VqbTeK+cHqUBBto jdbJvGsMmFjAp9mP+vOGs4Tnk6yNO4vCGN7kA4pU= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp8.mail.yandex.net (Yandex) with ESMTPSA id 065C041900B1; Tue, 15 Feb 2011 15:23:20 +0300 (MSK) Message-ID: <4D5A7036.2040603@yandex.ru> Date: Tue, 15 Feb 2011 15:23:18 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Oliver Fromme References: <201102151150.p1FBoxwe033904@lurza.secnetix.de> <4D5A6AB8.5000107@yandex.ru> In-Reply-To: <4D5A6AB8.5000107@yandex.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG, Alexander@leidinger.net Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 12:23:37 -0000 On 15.02.2011 14:59, Andrey V. Elsukov wrote: > On 15.02.2011 14:50, Oliver Fromme wrote: >> I have specifically bought an external enclosure that also >> has eSATA (beside USB2) so I have the full head-to-platter >> bandwidth of the disk. But the FUSE NTFS driver is not >> much faster than USB1 (this is not the fault of FUSE, >> in fact the ntfscp tool from the sysutils/ntfsprogs port >> is just as slow). > > Some time ago i did a copy of 80G of data from my computer to > external USB2 disk. The average speed was around 25-35 MB/s. > It seems not so bad as you told. Forgot to mention that this speed was between ZFS and fuse-ntfs. -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 12:30:57 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46CFE106566B for ; Tue, 15 Feb 2011 12:30:57 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE508FC0C for ; Tue, 15 Feb 2011 12:30:56 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 37E34E8399; Tue, 15 Feb 2011 12:30:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=ku9xISRkDgmr 4qppve+7rXKWIhs=; b=LnN7PKM74KSUbSvWfSub/A43+zf6m5fXkE4KI9kfvfPv mf9AP26NcHVLYvx2nzQQXL09o8gGXJo1SVu7PTnDVeJRa4pVIKC+4sSHBgaBS/bC pgyfKKNH64KkA8kfG1x/CHyV/Qi7w6/aihaviL0UP0a/we8etPe+Qfrrr/l9iwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=d9vRd5 9ZH6Ph4MfBIIwVLD+0WIXKgRrcxMzbeul2hog2+JUTCQtnvegdiObIW95qoFz2YT JBQXk42vjbMLeHVBbJzROd4ZFbpG4TDxPmDMnqD6IYj8vcB85B0g2X/gKOP5q0bj /F2mGUcdySbjJX6IbdSm6W8whcF724Qh0hifQ= Received: from unknown (client-86-31-199-149.oxfd.adsl.virginmedia.com [86.31.199.149]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id E19D2E8395; Tue, 15 Feb 2011 12:30:50 +0000 (GMT) Date: Tue, 15 Feb 2011 12:30:42 +0000 From: Bruce Cran To: Ollivier Robert Message-ID: <20110215123042.00005182@unknown> In-Reply-To: <20110215121917.GA12068@roberto-al.eurocontrol.fr> References: <201102141543.p1EFhKwi087340@lurza.secnetix.de> <20110215121917.GA12068@roberto-al.eurocontrol.fr> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 12:30:57 -0000 On Tue, 15 Feb 2011 13:19:17 +0100 Ollivier Robert wrote: > According to Oliver Fromme: > > because FAT has a 4 GB limit and NTFS is unsupported on > > FreeBSD for practical purposes. > > FAT32 ought to be able to get over that 4 GB limit, does it? FAT32 has a file size limit of 4 GB and can support large volumes but I think Windows (XP at least) refuses to format volumes over 32 GB. The Microsoft KB article about FAT32 limits: http://support.microsoft.com/kb/314463 How to format a drive > 32 GB: http://www.makeuseof.com/tag/format-large-hard-drive-fat-fat32/ -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 12:31:41 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1A2B106566B for ; Tue, 15 Feb 2011 12:31:41 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA2A8FC1B for ; Tue, 15 Feb 2011 12:31:40 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p1FCVO4W035605; Tue, 15 Feb 2011 13:31:39 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p1FCVOLn035604; Tue, 15 Feb 2011 13:31:24 +0100 (CET) (envelope-from olli) Date: Tue, 15 Feb 2011 13:31:24 +0100 (CET) Message-Id: <201102151231.p1FCVOLn035604@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG In-Reply-To: <20110215121917.GA12068@roberto-al.eurocontrol.fr> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Tue, 15 Feb 2011 13:31:39 +0100 (CET) Cc: Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 12:31:41 -0000 Ollivier Robert wrote: > According to Oliver Fromme: > > because FAT has a 4 GB limit [...] > > FAT32 ought to be able to get over that 4 GB limit, does it? No, it doesn't, unfortunately. The newer exFAT gets over the 4 GB limit, but exFAT is not supported by FreeBSD. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 12:55:14 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D51F0106566B for ; Tue, 15 Feb 2011 12:55:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5628FC19 for ; Tue, 15 Feb 2011 12:55:14 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p1FCsvcJ036721; Tue, 15 Feb 2011 13:55:12 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p1FCsvkm036720; Tue, 15 Feb 2011 13:54:57 +0100 (CET) (envelope-from olli) Date: Tue, 15 Feb 2011 13:54:57 +0100 (CET) Message-Id: <201102151254.p1FCsvkm036720@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, bu7cher@yandex.ru In-Reply-To: <4D5A7036.2040603@yandex.ru> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Tue, 15 Feb 2011 13:55:13 +0100 (CET) Cc: Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 12:55:14 -0000 Andrey V. Elsukov wrote: > On 15.02.2011 14:59, Andrey V. Elsukov wrote: > > On 15.02.2011 14:50, Oliver Fromme wrote: > > > I have specifically bought an external enclosure that also > > > has eSATA (beside USB2) so I have the full head-to-platter > > > bandwidth of the disk. But the FUSE NTFS driver is not > > > much faster than USB1 (this is not the fault of FUSE, > > > in fact the ntfscp tool from the sysutils/ntfsprogs port > > > is just as slow). > > > > Some time ago i did a copy of 80G of data from my computer to > > external USB2 disk. The average speed was around 25-35 MB/s. > > It seems not so bad as you told. > > Forgot to mention that this speed was between ZFS and fuse-ntfs. Are you sure? I'm not at all able to reproduce it. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-fs@FreeBSD.ORG Tue Feb 15 13:30:54 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB830106566C for ; Tue, 15 Feb 2011 13:30:54 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 343AB8FC19 for ; Tue, 15 Feb 2011 13:30:53 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p1FDUbWP037861; Tue, 15 Feb 2011 14:30:52 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p1FDUbCF037860; Tue, 15 Feb 2011 14:30:37 +0100 (CET) (envelope-from olli) Date: Tue, 15 Feb 2011 14:30:37 +0100 (CET) Message-Id: <201102151330.p1FDUbCF037860@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG In-Reply-To: <201102151231.p1FCVOLn035604@lurza.secnetix.de> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Tue, 15 Feb 2011 14:30:53 +0100 (CET) Cc: Subject: Re: ext2fs: ext2 vs. ext3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 13:30:54 -0000 Oliver Fromme wrote: > Ollivier Robert wrote: > > According to Oliver Fromme: > > > because FAT has a 4 GB limit [...] > > > > FAT32 ought to be able to get over that 4 GB limit, does it? > > No, it doesn't, unfortunately. The newer exFAT gets over > the 4 GB limit, but exFAT is not supported by FreeBSD. Just to be clear: I'm talking about file size limit, not volume size limit. All FAT versions up to (and including) FAT32 store the file size in an unsigned 32 bit integer, so the maximum is 4 GB - 1 byte. However, a single HDTV recording can easily exceed 4 GB, so FAT is unsuitable for that purpose. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 09:58:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A2301065697 for ; Wed, 16 Feb 2011 09:58:39 +0000 (UTC) (envelope-from gabbawp@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 200168FC13 for ; Wed, 16 Feb 2011 09:58:38 +0000 (UTC) Received: by wwi17 with SMTP id 17so4095967wwi.1 for ; Wed, 16 Feb 2011 01:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=J7czG1mT74Vdmzk/7Q5SuH1/N5eJi6Wxp+1ehp8lnsg=; b=cxIRGhspebeN9DfzvnR4raGu48EYc9qhcXX8jhTHzaitWDy4sILmnjLjCfs82mnNmi wteS+nrMPO9L1dtOTIS9KG1p/4p6BZtgD1Lt9TBgaJ65IOkSk3b+OjS/rmcYE5sffaT7 TRYE8yLDqXl/KQlg1CZCZMkHwryoBxDsMgSSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JvWqrFzNOUvAYlDnza288ACmxAJ1l/P/9mISNrmUepxyEIOGA7wygNkr1tjX9FK2zz mEO2mEjBs1aCMq+YKzLr1BUCT0IswOUp7712RZnMY8qnt4Ik15V2PMCb6w7zwIS/BxGl gde1l+YxJivaQJ+bd5pPEAAlQ7wNO//dfcHiY= MIME-Version: 1.0 Received: by 10.216.177.210 with SMTP id d60mr282498wem.85.1297848803523; Wed, 16 Feb 2011 01:33:23 -0800 (PST) Received: by 10.216.177.74 with HTTP; Wed, 16 Feb 2011 01:33:23 -0800 (PST) Date: Wed, 16 Feb 2011 11:33:23 +0200 Message-ID: From: Gareth Hopkins To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Snapshot on different sized partitions show different file types X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 09:58:39 -0000 Hi, I'm creating snapshots on a couple of partitions ranging from 10GB to 31GB running file on the snapshots show different filetypes for the snapshots on the larger than 10GB partitions. [root@ ~]# df -h / Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 9.7G 322M 8.6G 4% / [root@ ~]# file /.snap/daily.0 /.snap/daily.0: Unix Fast File system [v2] (little-endian) last mounted on /, last written at Wed Feb 16 00:34:01 2011, clean flag 1, readonly flag 1, number of blocks 5242880, number of data blocks 5077079, number of cylinder groups 56, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization [root@ ~]# df -h /usr Filesystem Size Used Avail Capacity Mounted on /dev/da0s1d 31G 2.7G 26G 9% /usr [root@ ~]# file /usr/.snap/daily.0 /usr/.snap/daily.0: DOS executable (device driver) [root@ ~]# df -h /usr/local Filesystem Size Used Avail Capacity Mounted on /dev/da0s1e 15G 134M 14G 1% /usr/local [root@ ~]# file /usr/local/.snap/daily.0 /usr/local/.snap/daily.0: DOS executable (device driver) Is there some sort of limit on the snapshot size being reported to the file system ? Cheers, Gareth From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 12:22:21 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11286106566B for ; Wed, 16 Feb 2011 12:22:21 +0000 (UTC) (envelope-from canevet@embl.fr) Received: from emblmta1.embl.fr (emblmta1.embl.fr [193.49.43.176]) by mx1.freebsd.org (Postfix) with ESMTP id A43068FC0A for ; Wed, 16 Feb 2011 12:22:19 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.60,479,1291590000"; d="asc'?scan'208";a="1102249" Received: from unknown (HELO [172.26.15.11]) ([172.26.15.11]) by emblmta1.embl.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Feb 2011 13:22:18 +0100 From: =?ISO-8859-1?Q?Micka=EBl_Can=E9vet?= To: freebsd-fs@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Ihf+Xa7QZkZaBsomEMUt" Date: Wed, 16 Feb 2011 13:22:24 +0100 Message-ID: <1297858944.3097.20.camel@pc286.embl.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Subject: showmount sometimes slow with carp X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 12:22:21 -0000 --=-Ihf+Xa7QZkZaBsomEMUt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I installed a redundant NAS with FreeBSD 8.2RC3 + Hast + ZFS + Carp. Each machine has its own IP address, and share a virtual IP with carp. When I launch 'showmount -e ' from a linux client or a freebsd client, I got my answer immediately (about 5ms). But when I try with carp virtual IP or FQDN, it sometimes takes around 20 seconds, or even 1 minute, but not everytime. It is really annoying because automount, at least the linux version, seams to use showmount to get server exports. So it sometimes does not work through the carp virtual IP. Can anybody help me ? Thanks a lot, Micka=C3=ABl --=-Ihf+Xa7QZkZaBsomEMUt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1bwYAACgkQZjBmN5Hi/YYrXwCeOIIfNviDVp6b1t40ZDXU9D6J EcQAoJ7NajDicE0ejIQ+1hxUTM1BkGVj =zlmo -----END PGP SIGNATURE----- --=-Ihf+Xa7QZkZaBsomEMUt-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 13:36:19 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30DD51065673 for ; Wed, 16 Feb 2011 13:36:19 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 751AD8FC1C for ; Wed, 16 Feb 2011 13:36:18 +0000 (UTC) Received: (qmail 40241 invoked by uid 89); 16 Feb 2011 14:36:17 +0100 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with CAMELLIA256-SHA encrypted SMTP; 16 Feb 2011 14:36:17 +0100 Message-ID: <4D5BD2D1.2080900@bytecamp.net> Date: Wed, 16 Feb 2011 14:36:17 +0100 From: Robert Schulze Organization: bytecamp GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: LOR in zfs/syncer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 13:36:19 -0000 Hi, during zfs destroy, the following LOR appeared: lock order reversal: 1st 0xffffff007c26fa58 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1204 2nd 0xffffff0126175a58 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2232 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7d3 __lockmgr_args() at __lockmgr_args+0xd0b vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x5d vputx() at vputx+0x2f5 dounmount() at dounmount+0x26d unmount() at unmount+0x27f syscallenter() at syscallenter+0xe5 syscall() at syscall+0x55 Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (22, FreeBSD ELF64, unmount), rip = 0x800f444dc, rsp = 0x7fffffffe1e8, rbp = 0x801204300 --- uname -a: FreeBSD xxxxx 8.2-RC3 FreeBSD 8.2-RC3 #3: Mon Jan 31 12:57:26 CET 2011 root@xxxxx:/usr/obj/usr/src/sys/BAK amd64 with kind regards, Robert Schulze From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 15:29:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D7E7106567A for ; Wed, 16 Feb 2011 15:29:06 +0000 (UTC) (envelope-from canevet@embl.fr) Received: from emblmta1.embl.fr (emblmta1.embl.fr [193.49.43.176]) by mx1.freebsd.org (Postfix) with ESMTP id 3308C8FC19 for ; Wed, 16 Feb 2011 15:29:05 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.60,480,1291590000"; d="asc'?scan'208";a="1106336" Received: from unknown (HELO [172.26.15.11]) ([172.26.15.11]) by emblmta1.embl.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Feb 2011 16:29:04 +0100 From: =?ISO-8859-1?Q?Micka=EBl_Can=E9vet?= To: freebsd-fs@freebsd.org In-Reply-To: <1297858944.3097.20.camel@pc286.embl.fr> References: <1297858944.3097.20.camel@pc286.embl.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-RsWQwdMtceoboNcgqBCz" Date: Wed, 16 Feb 2011 16:29:10 +0100 Message-ID: <1297870150.3097.30.camel@pc286.embl.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Subject: Re: showmount sometimes slow with carp X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 15:29:06 -0000 --=-RsWQwdMtceoboNcgqBCz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi again, I also have a problem when I mount an exported filesystem through the carp VIP. When I do that: mount :/data/user /mnt while true; do time df -H /mnt > /dev/null; sleep 5; done 2>&1 | grep ^real real 0m0.004s real 0m0.004s real 0m0.004s real 0m0.004s real 0m0.004s ... But when I do that: mount :/data/user /mnt while true; do time df -H /mnt > /dev/null; sleep 5; done 2>&1 | grep ^real real 0m0.005s real 0m0.207s real 0m0.206s real 0m52.150s real 0m0.004s real 0m0.004s real 0m0.002s real 0m0.204s real 0m0.206s real 0m0.614s real 0m0.004s real 0m0.207s real 0m0.205s real 0m0.206s real 0m0.206s real 0m0.613s real 0m0.003s Every now and then I have a long delay with the vip that I don't have with the real IP or an alias... On Wed, 2011-02-16 at 13:22 +0100, Micka=C3=ABl Can=C3=A9vet wrote: > Hi, >=20 > I installed a redundant NAS with FreeBSD 8.2RC3 + Hast + ZFS + Carp. >=20 > Each machine has its own IP address, and share a virtual IP with carp. >=20 > When I launch 'showmount -e ' from a linux client > or a freebsd client, I got my answer immediately (about 5ms). But when I > try with carp virtual IP or FQDN, it sometimes takes around 20 seconds, > or even 1 minute, but not everytime. >=20 > It is really annoying because automount, at least the linux version, > seams to use showmount to get server exports. So it sometimes does not > work through the carp virtual IP. >=20 > Can anybody help me ? >=20 > Thanks a lot, >=20 > Micka=C3=ABl --=-RsWQwdMtceoboNcgqBCz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1b7UYACgkQZjBmN5Hi/Yay+gCgo/Xy3P2Ta9frlkjVeXxoqvzg j6sAn3tJwxru3dg32b6EOd15UbPnrV+m =ke8t -----END PGP SIGNATURE----- --=-RsWQwdMtceoboNcgqBCz-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 15:45:15 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876D710656A7 for ; Wed, 16 Feb 2011 15:45:15 +0000 (UTC) (envelope-from canevet@embl.fr) Received: from emblmta1.embl.fr (emblmta1.embl.fr [193.49.43.176]) by mx1.freebsd.org (Postfix) with ESMTP id E0A778FC08 for ; Wed, 16 Feb 2011 15:45:14 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.60,480,1291590000"; d="asc'?scan'208";a="1106606" Received: from unknown (HELO [172.26.15.11]) ([172.26.15.11]) by emblmta1.embl.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Feb 2011 16:45:13 +0100 From: =?ISO-8859-1?Q?Micka=EBl_Can=E9vet?= To: freebsd-fs@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <1297870150.3097.30.camel@pc286.embl.fr> References: <1297858944.3097.20.camel@pc286.embl.fr> <1297870150.3097.30.camel@pc286.embl.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-lPyBYh3OoVl54tUoAhA2" Date: Wed, 16 Feb 2011 16:45:19 +0100 Message-ID: <1297871119.3097.36.camel@pc286.embl.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Cc: Subject: Re: showmount sometimes slow with carp X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 15:45:15 -0000 --=-lPyBYh3OoVl54tUoAhA2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi again, again, The problem seams to be even more general (so I put freebsd-net in copy). When I ping carp interface, I lost some pings... ping data-test PING data-test.embl.fr (172.26.9.236) 56(84) bytes of data. 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D7 ttl=3D64 time=3D0.183 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D8 ttl=3D64 time=3D0.217 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D23 ttl=3D64 time=3D0.273 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D24 ttl=3D64 time=3D0.217 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D25 ttl=3D64 time=3D0.219 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D26 ttl=3D64 time=3D0.132 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D27 ttl=3D64 time=3D0.203 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D28 ttl=3D64 time=3D0.157 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D29 ttl=3D64 time=3D0.191 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D30 ttl=3D64 time=3D0.238 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D31 ttl=3D64 time=3D0.226 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D32 ttl=3D64 time=3D0.272 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D33 ttl=3D64 time=3D0.215 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D36 ttl=3D64 time=3D0.180 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D37 ttl=3D64 time=3D0.314 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D38 ttl=3D64 time=3D0.169 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D39 ttl=3D64 time=3D0.206 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D40 ttl=3D64 time=3D0.170 ms 64 bytes from data-test.embl.fr (172.26.9.236): icmp_req=3D41 ttl=3D64 time=3D0.158 ms ^C --- data-test.embl.fr ping statistics --- 41 packets transmitted, 19 received, 53% packet loss, time 40184ms rtt min/avg/max/mdev =3D 0.132/0.207/0.314/0.045 ms Is it a bug, or am I doing something wrong ? Here is my network configuration: defaultrouter=3D"172.26.9.254" hostname=3D"pc234.embl.fr" cloned_interfaces=3D"lagg0 carp0" ifconfig_bge0=3D"up" ifconfig_em0=3D"up" ifconfig_em1=3D"172.26.14.234/24" ifconfig_lagg0=3D"laggproto failover laggport bge0 laggport em0" ipv4_addrs_lagg0=3D"172.26.9.234/24" ifconfig_carp0=3D"vhid 1 pass 497500fd0f6c3988d1f advskew 10 172.26.9.236/24" Tomorrow I'll try with a carp interface that is not over a network bonding to see if the problem comes from that. Micka=C3=ABl On Wed, 2011-02-16 at 16:29 +0100, Micka=C3=ABl Can=C3=A9vet wrote: > Hi again, >=20 > I also have a problem when I mount an exported filesystem through the > carp VIP. >=20 > When I do that: >=20 > mount :/data/user /mnt > while true; do time df -H /mnt > /dev/null; sleep 5; done 2>&1 | grep > ^real >=20 > real 0m0.004s > real 0m0.004s > real 0m0.004s > real 0m0.004s > real 0m0.004s > ... >=20 > But when I do that: >=20 > mount :/data/user /mnt > while true; do time df -H /mnt > /dev/null; sleep 5; done 2>&1 | grep > ^real > real 0m0.005s > real 0m0.207s > real 0m0.206s > real 0m52.150s > real 0m0.004s > real 0m0.004s > real 0m0.002s > real 0m0.204s > real 0m0.206s > real 0m0.614s > real 0m0.004s > real 0m0.207s > real 0m0.205s > real 0m0.206s > real 0m0.206s > real 0m0.613s > real 0m0.003s >=20 > Every now and then I have a long delay with the vip that I don't have > with the real IP or an alias... >=20 > On Wed, 2011-02-16 at 13:22 +0100, Micka=C3=ABl Can=C3=A9vet wrote: > > Hi, > >=20 > > I installed a redundant NAS with FreeBSD 8.2RC3 + Hast + ZFS + Carp. > >=20 > > Each machine has its own IP address, and share a virtual IP with carp. > >=20 > > When I launch 'showmount -e ' from a linux client > > or a freebsd client, I got my answer immediately (about 5ms). But when = I > > try with carp virtual IP or FQDN, it sometimes takes around 20 seconds, > > or even 1 minute, but not everytime. > >=20 > > It is really annoying because automount, at least the linux version, > > seams to use showmount to get server exports. So it sometimes does not > > work through the carp virtual IP. > >=20 > > Can anybody help me ? > >=20 > > Thanks a lot, > >=20 > > Micka=C3=ABl >=20 --=-lPyBYh3OoVl54tUoAhA2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1b8Q8ACgkQZjBmN5Hi/YZtJQCgjAybI68s9DyqnQIkm4SaXPI7 GvUAn2q+wv2XqgeXVNGsoOJ1CxODYc5B =c3hP -----END PGP SIGNATURE----- --=-lPyBYh3OoVl54tUoAhA2-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 15:50:01 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D4FE106567A for ; Wed, 16 Feb 2011 15:50:01 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC3F28FC1C for ; Wed, 16 Feb 2011 15:50:00 +0000 (UTC) Received: by bwz12 with SMTP id 12so1581747bwz.13 for ; Wed, 16 Feb 2011 07:49:59 -0800 (PST) Received: by 10.204.66.130 with SMTP id n2mr619336bki.175.1297871399545; Wed, 16 Feb 2011 07:49:59 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id f20sm233859bkf.4.2011.02.16.07.49.58 (version=SSLv3 cipher=OTHER); Wed, 16 Feb 2011 07:49:59 -0800 (PST) Message-ID: <4D5BF225.4060500@my.gd> Date: Wed, 16 Feb 2011 16:49:57 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, canevet@embl.fr References: <1297858944.3097.20.camel@pc286.embl.fr> <1297870150.3097.30.camel@pc286.embl.fr> <1297871119.3097.36.camel@pc286.embl.fr> In-Reply-To: <1297871119.3097.36.camel@pc286.embl.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: showmount sometimes slow with carp X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 15:50:01 -0000 You're using POLLING on your physical interfaces. Sometimes they go down and you lose your CARP interface. OR For whatever reason you lose your CARP interface. Get the output from `dmesg` , see if you get logs saying your carp interface went down then back up, there are high chances it did. Post your dmesg Post your ifconfig Post your rc.conf Cheers ;) On 2/16/11 4:45 PM, Mickaël Canévet wrote: >> Every now and then I have a long delay with the vip that I don't have >> with the real IP or an alias... >> >> On Wed, 2011-02-16 at 13:22 +0100, Mickaël Canévet wrote: >>> Hi, >>> >>> I installed a redundant NAS with FreeBSD 8.2RC3 + Hast + ZFS + Carp. >>> >>> Each machine has its own IP address, and share a virtual IP with carp. >>> >>> When I launch 'showmount -e ' from a linux client >>> or a freebsd client, I got my answer immediately (about 5ms). But when I >>> try with carp virtual IP or FQDN, it sometimes takes around 20 seconds, >>> or even 1 minute, but not everytime. >>> >>> It is really annoying because automount, at least the linux version, >>> seams to use showmount to get server exports. So it sometimes does not >>> work through the carp virtual IP. >>> >>> Can anybody help me ? >>> >>> Thanks a lot, >>> >>> Mickaël >> > From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 18:52:17 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 738AE1065673 for ; Wed, 16 Feb 2011 18:52:17 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id 077BC8FC13 for ; Wed, 16 Feb 2011 18:52:16 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out3.tiscali.nl with esmtp (Exim) (envelope-from ) id 1PpmHy-0005JK-E1 for freebsd-fs@freebsd.org; Wed, 16 Feb 2011 19:39:46 +0100 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 4D4E9F05A for ; Wed, 16 Feb 2011 19:39:42 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: Date: Wed, 16 Feb 2011 19:39:41 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.01 (FreeBSD) Content-Transfer-Encoding: quoted-printable Subject: Re: Snapshot on different sized partitions show different file types X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:52:17 -0000 On Wed, 16 Feb 2011 10:33:23 +0100, Gareth Hopkins =20 wrote: > Hi, > > I'm creating snapshots on a couple of partitions ranging from 10GB to =20 > 31GB > > running file on the snapshots show different filetypes for the snapshot= s =20 > on > the larger than 10GB partitions. > > [root@ ~]# df -h / > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 9.7G 322M 8.6G 4% / > [root@ ~]# file /.snap/daily.0 > /.snap/daily.0: Unix Fast File system [v2] (little-endian) last mounted= =20 > on > /, last written at Wed Feb 16 00:34:01 2011, clean flag 1, readonly fla= g =20 > 1, > number of blocks 5242880, number of data blocks 5077079, number of =20 > cylinder > groups 56, block size 16384, fragment size 2048, average file size 1638= 4, > average number of files in dir 64, pending blocks to free 0, pending =20 > inodes > to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIM= E > optimization > > [root@ ~]# df -h /usr > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1d 31G 2.7G 26G 9% /usr > [root@ ~]# file /usr/.snap/daily.0 > /usr/.snap/daily.0: DOS executable (device driver) > > [root@ ~]# df -h /usr/local > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1e 15G 134M 14G 1% /usr/local > [root@ ~]# file /usr/local/.snap/daily.0 > /usr/local/.snap/daily.0: DOS executable (device driver) > > Is there some sort of limit on the snapshot size being reported to the = =20 > file > system ? > > Cheers, > > Gareth Hi, I am not authoritative in the ffs-snapshot stuff, but why would a =20 snapshot always start with the same data? Maybe it is just sort of random= . =20 The 'file' utility just guesses the type by looking at the first N bytes = =20 of the file. I don't know if it has special knowledge about snapshot file= s. Ronald. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 23:23:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AC6106564A for ; Wed, 16 Feb 2011 23:23:35 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F63E8FC16 for ; Wed, 16 Feb 2011 23:23:34 +0000 (UTC) Received: by wyf19 with SMTP id 19so1915990wyf.13 for ; Wed, 16 Feb 2011 15:23:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.156.15 with SMTP id u15mr994962wbw.220.1297896724748; Wed, 16 Feb 2011 14:52:04 -0800 (PST) Received: by 10.227.154.15 with HTTP; Wed, 16 Feb 2011 14:52:04 -0800 (PST) Date: Thu, 17 Feb 2011 11:52:04 +1300 Message-ID: From: Andrew Thompson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: zfs directory listing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 23:23:35 -0000 Hi, I have a zfs file system on 8.1-RELEASE amd64 which as a large number of files in /var/spool/mqueue. loader.conf has vfs.zfs.arc_max=2G for an 8G box. NAME USED AVAIL REFER MOUNTPOINT tank/jails/xena 46.0G 779G 41.8G /jails/xena Here is the listing of /jails/xena/var/spool, drwxrwx--- 2 smmsp smmsp 34 Feb 17 11:25 clientmqueue drwxrwxr-x 2 uucp dialer 3 Feb 17 11:18 lock drwxr-xr-x 2 root daemon 2 May 1 2009 lpd drwx------ 2 mailnull daemon 2 Dec 28 2004 milter-regex drwxr-xr-x 2 root daemon 522824 Feb 17 11:10 mqueue drwx------ 2 root daemon 2 May 1 2009 opielocks drwxr-xr-x 3 root daemon 3 May 1 2009 output drwxr-xr-x 2 spamd spamd 2 Jun 29 2005 spamd mqueue has a link count of 522824. I can not list the contents of this directory, when I do the number of read IOPS sits > 100 and it will never complete # zpool iostat 1 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- tank 127G 793G 340 326 1.23M 1.83M tank 127G 793G 146 0 937K 0 tank 127G 793G 135 0 870K 0 tank 127G 793G 136 0 875K 0 tank 127G 793G 125 0 812K 0 tank 127G 793G 135 0 869K 0 ... if I ^C the ls then the read ops drops back to zero. If I leave a `ls` or `find /var/spool/mqueue` running then they will churn the disks indefinitely without producing output. Andrew From owner-freebsd-fs@FreeBSD.ORG Wed Feb 16 23:31:54 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A12E106566C for ; Wed, 16 Feb 2011 23:31:54 +0000 (UTC) (envelope-from pipatron@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD92B8FC16 for ; Wed, 16 Feb 2011 23:31:53 +0000 (UTC) Received: by yie19 with SMTP id 19so888577yie.13 for ; Wed, 16 Feb 2011 15:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PqYBPhwVBvT1pQhUhOUpjxS0Advth8jtrg49EGUpXmU=; b=Vewai8htBV57VJpDHkiTkAcR1rcreKohV02R6vlFVlV9u6opYrAw/Zt8+0CO8yrbER lRXYop9CwZND9I5z6KzW920OV5Lx0cPCQGVt9dOiPyvQjZb6oL5zN84Tp7ZeAtDUlVnq SxH2UBU9SFHnF3lZv3FD1ok30mNH+q/RHUmmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l6m9/CB6wqi3/c+7Rxc6567La54uEgCF3+LM0gPVcOZxsjgKg9dL50evdygy8yF1Fc zGdHwst+8TLUTEg0aZb5Gx8o7h2PgyPbOckN+yAGquUv/bhuRWV2fFNFSDdhQJK7HKmU U/GW62XE620yMyozp+u2FHjOlld322O+p8OjM= MIME-Version: 1.0 Received: by 10.150.185.5 with SMTP id i5mr1503219ybf.271.1297899112939; Wed, 16 Feb 2011 15:31:52 -0800 (PST) Received: by 10.150.196.17 with HTTP; Wed, 16 Feb 2011 15:31:52 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Feb 2011 00:31:52 +0100 Message-ID: From: Anders Andersson To: Andrew Thompson Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: zfs directory listing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 23:31:54 -0000 > mqueue has a link count of 522824. I can not list the contents of this > directory, when I do the number of read IOPS sits > 100 and it will > never complete > if I ^C the ls then the read ops drops back to zero. If I leave a `ls` > or `find /var/spool/mqueue` running then they will churn the disks > indefinitely without producing output. Now, I just joined to get help from UFS2-people, but when I am doing things like this in linux, I use "ls -lU" or "ls -lf". "ls -U" means that it doesn't try to sort the entries at all, but outputs them in the order they are found. This means that there is no longer a delay from collecting them in memory and sorting, but it outputs each entry as soon as they are found. This may help you unless there is something else wrong, or unless such a flag does not exist in your version of ls. You also have the utility "find", which might work better in this case. Forgive me if these seem trivial and obvious. :) // pipe From owner-freebsd-fs@FreeBSD.ORG Thu Feb 17 00:56:02 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99A071065673 for ; Thu, 17 Feb 2011 00:56:02 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 51A1E8FC0A for ; Thu, 17 Feb 2011 00:56:02 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PpsA4-00060M-Ra for freebsd-fs@freebsd.org; Thu, 17 Feb 2011 01:56:00 +0100 Received: from cpe-188-129-78-195.dynamic.amis.hr ([188.129.78.195]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Feb 2011 01:56:00 +0100 Received: from ivoras by cpe-188-129-78-195.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Feb 2011 01:56:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Thu, 17 Feb 2011 01:55:46 +0100 Lines: 27 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-78-195.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: Subject: Re: zfs directory listing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 00:56:02 -0000 On 16/02/2011 23:52, Andrew Thompson wrote: > Hi, > > > I have a zfs file system on 8.1-RELEASE amd64 which as a large number > of files in /var/spool/mqueue. loader.conf has vfs.zfs.arc_max=2G for > an 8G box. > mqueue has a link count of 522824. I can not list the contents of this > directory, when I do the number of read IOPS sits> 100 and it will > never complete Your problem is probably not FreeBSD-specific and possibly not even ZFS-specific. That is a fairly large number of files in a directory for any file system; The rule of thumb is usually to start sharding as soon as the number of files gets even two orders of magnitude lower than what you have there. As others said, try "cd /var/spool/mqueue && find ." - the find utility just reads the directory, it doesn't try to gather other metadata which "ls" uses and is usually one of the rare utilities which can work with gigantic directories (usually in the form "find . -delete" :) ). The reason for this is that filenames and file metadata are separate objects on the drives and the drives need to seek between them to get both if they are not cached. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 17 01:10:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AA21065673 for ; Thu, 17 Feb 2011 01:10:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 00C0E8FC1A for ; Thu, 17 Feb 2011 01:10:35 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id 8p5S1g0040cZkys59pAcgo; Thu, 17 Feb 2011 01:10:36 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta10.westchester.pa.mail.comcast.net with comcast id 8pAZ1g0140PUQVN3WpAamX; Thu, 17 Feb 2011 01:10:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4F6059B422; Wed, 16 Feb 2011 17:10:32 -0800 (PST) Date: Wed, 16 Feb 2011 17:10:32 -0800 From: Jeremy Chadwick To: Ivan Voras Message-ID: <20110217011032.GA15027@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: zfs directory listing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:10:40 -0000 On Thu, Feb 17, 2011 at 01:55:46AM +0100, Ivan Voras wrote: > On 16/02/2011 23:52, Andrew Thompson wrote: > >Hi, > > > > > >I have a zfs file system on 8.1-RELEASE amd64 which as a large number > >of files in /var/spool/mqueue. loader.conf has vfs.zfs.arc_max=2G for > >an 8G box. > > >mqueue has a link count of 522824. I can not list the contents of this > >directory, when I do the number of read IOPS sits> 100 and it will > >never complete > > Your problem is probably not FreeBSD-specific and possibly not even > ZFS-specific. That is a fairly large number of files in a directory > for any file system; The rule of thumb is usually to start sharding > as soon as the number of files gets even two orders of magnitude > lower than what you have there. > > As others said, try "cd /var/spool/mqueue && find ." - the find > utility just reads the directory, it doesn't try to gather other > metadata which "ls" uses and is usually one of the rare utilities > which can work with gigantic directories (usually in the form "find > . -delete" :) ). > > The reason for this is that filenames and file metadata are separate > objects on the drives and the drives need to seek between them to > get both if they are not cached. Simple version, to the OP: your mail server has an immense number of queued mails in it. You need to find out why and put an end to it. I also recommend you stop sendmail, "rm -r mqueue ; chown root:daemon mqueue ; chmod 755 mqueue", then start sendmail again. I'll also point out that things like ls -l and related methods take a significantly longer amount of time than doing something like "echo *" given the number of stat() calls that have to be made. Regarding the focus on ZFS with regards to this situation: you may want to look at vfs.numvnodes (sysctl) and if it's reaching kern.maxvnodes, increase kern.maxvnodes (via sysctl.conf). Be aware more vnodes means more memory usage, and this is separate/unrelated to/from ARC memory. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Feb 17 09:55:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8197106567A for ; Thu, 17 Feb 2011 09:55:52 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 534048FC15 for ; Thu, 17 Feb 2011 09:55:51 +0000 (UTC) Received: by wwf26 with SMTP id 26so2318294wwf.31 for ; Thu, 17 Feb 2011 01:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=xtPm4zxCQPNy+LKiLS4gXjdJUprW6zN71/aWzt2QUlo=; b=B2mbnyxij9S0hPuRxwC8qCYQ/yhyk4F7lc5Kp+II7oGrkqe9PDY3+4Bskp8g1EEbp2 +mDL+JMQWxgDJtYH3Dvb1y+7PGHVlLqrd0seqWsV0Cj6cmgS2JRvW2SIOC+HUWCV3i2X WDQb9KFS5r/BAfJBjgIDpeFgKTnD2ICGraTys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xoKp7xF47657REc0xtskaDFEp1XM66B9BwXY3ToXdC/YBI2YEKTmXue93ZTnbdmlw9 g6k0PXl8RZrrDB/ztHrDYq1mMDjr0A/7qbQRoKxxMVKNsB8cJvbR16eeh37QYf5qXziH MX1feJffGjzNPh9KVs+4YwGfPXlL7oX6Z+ul8= MIME-Version: 1.0 Received: by 10.216.19.133 with SMTP id n5mr95203wen.83.1297935017405; Thu, 17 Feb 2011 01:30:17 -0800 (PST) Received: by 10.216.80.147 with HTTP; Thu, 17 Feb 2011 01:30:17 -0800 (PST) Date: Thu, 17 Feb 2011 09:30:17 +0000 Message-ID: From: krad To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: zfs boot on 4k drives in -STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 09:55:52 -0000 Hi, What is the current state of zfs booting of a 4k aligned drive (ashift=12)? I have tried the patch in pr153695 but it wont apply cleanly to stable as I think it is meant for current. Is one going to be made available for STABLE at any point? http://www.freebsd.org/cgi/query-pr.cgi?pr=153695 From owner-freebsd-fs@FreeBSD.ORG Thu Feb 17 13:32:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29B95106564A for ; Thu, 17 Feb 2011 13:32:25 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED2E88FC14 for ; Thu, 17 Feb 2011 13:32:24 +0000 (UTC) Received: by iyb26 with SMTP id 26so2421243iyb.13 for ; Thu, 17 Feb 2011 05:32:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.220.138 with SMTP id hy10mr2670496icb.271.1297949543672; Thu, 17 Feb 2011 05:32:23 -0800 (PST) Received: by 10.231.145.198 with HTTP; Thu, 17 Feb 2011 05:32:23 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Feb 2011 14:32:23 +0100 Message-ID: From: Olivier Smedts To: krad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zfs boot on 4k drives in -STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 13:32:25 -0000 2011/2/17 krad : > Hi, > > What is the current state of zfs booting of a 4k aligned drive > (ashift=3D12)? I have tried the patch in pr153695 but it wont apply > cleanly to stable as I think it is meant for current. Is one going to > be made available for STABLE at any point? Didn't pjd@ fixed this in ZFS v28 ? Maybe you can look at the mm@ patches for 8-stable in http://people.freebsd.org/~mm/patches/zfs/v28/ I think it should work even if you keep your pool at version 15. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D153695 > _______________________________________________ > 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" > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-fs@FreeBSD.ORG Thu Feb 17 21:06:16 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FC18106566B; Thu, 17 Feb 2011 21:06:16 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 767228FC20; Thu, 17 Feb 2011 21:06:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1HL6GBp008106; Thu, 17 Feb 2011 21:06:16 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1HL6Evt008102; Thu, 17 Feb 2011 21:06:14 GMT (envelope-from brucec) Date: Thu, 17 Feb 2011 21:06:14 GMT Message-Id: <201102172106.p1HL6Evt008102@freefall.freebsd.org> To: vk@dss.kbb.ru, brucec@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/149022: [hang] File system operations hangs with suspfs state X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 21:06:16 -0000 Synopsis: [hang] File system operations hangs with suspfs state State-Changed-From-To: open->feedback State-Changed-By: brucec State-Changed-When: Thu Feb 17 21:04:42 UTC 2011 State-Changed-Why: Lots of people were seeing this issue and Jeff committed a potential fix in May. Could you confirm whether you're still having the problem? http://www.freebsd.org/cgi/query-pr.cgi?pr=149022 From owner-freebsd-fs@FreeBSD.ORG Fri Feb 18 01:28:42 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E8D106566B for ; Fri, 18 Feb 2011 01:28:42 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4D3038FC17 for ; Fri, 18 Feb 2011 01:28:41 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 7CFE17E84A; Fri, 18 Feb 2011 12:12:16 +1100 (EST) Message-ID: <4D5DC770.2090308@freebsd.org> Date: Fri, 18 Feb 2011 12:12:16 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.13) Gecko/20101214 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-fs@freebsd.org Subject: Mounting NFSv4 as root fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 01:28:42 -0000 Hi Rick, I've set up a NFS server to pxeboot a set of testbed clients from. The server filesystem tree the client needs to use as its root has nullfs mounted directories in it. Therefore, NFSv4 is the only useful way to mount it on the client because of the cross mount point traversing capabilities built into v4. I've verified that I can "mount_nfs -o nfsv4 ..." on the command line and see all the files in the tree so I have things working fine on the server side. I was aware our pxeboot only supports NFSv3, but hoped that by specifying "newfs" and "nfsv4" in the fstype and options fields respectively in fstab that things might just work when the mount root step after the kernel boot happens. It doesn't as I found out, because of two issues: 1. I believe there is a bug in the newnfs code. nfs_diskless.c wasn't copied from the old nfsclient and suitably modified for use with newnfs. As a result during boot, the ncl_mountroot() function in nfs_clvfsops.c calls nfs_setup_diskless() which calls into the old nfs code and badness happens from there on in. I have a patch which fixes this issue, though it may be completely the wrong way to do things as I'm very new (as in 24 hours new) to the NFS code. 2. pxeboot stores the filehandle and filehandle length it used to grab the kernel via NFS in the kernel's env and after the kernel has booted, it looks for these variables and reuses them i.e. at no point in the process does the code attempt to upgrade to NFSv4 if the bootstrap uses NFSv3 to grab the kernel. For my particular use case, I'm quite happy for the kernel to be pulled via NFSv3, but can't boot the client without somehow getting the client to switch to NFSv4 at the point where it mount's root after the kernel has finished booting. I tried a very hacky test in mountnfs() in nfs_clvfsops.c to see if I could set the NFSV4 flag, unset the V3 flag and tell the code to forget about the cached file handle set by the loader just to see if the code would try to renegotiate using v4... it crashed and burned. So, before I spend any more time on this, I hope to get your (or anyone else reading for that matter) thoughts on how best to proceed. Some questions: - Could you guesstimate how much work is involved to get v4 support into libstand so that pxeboot can talk v4 natively? I spent quite some time poking at libstand's code last night but don't understand the NFSv4 RPC mechanism enough to attempt writing the basic code to do it yet. The RFC explains the ordering of OPs needed quit well but I don't quite grok how the data structures for interpreting responses work. - Can you think of a hacky simple way to force my client to renegotiate the mount as v4 at the time mount root happens? Cheers, Lawrence From owner-freebsd-fs@FreeBSD.ORG Fri Feb 18 02:12:18 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4681106566B for ; Fri, 18 Feb 2011 02:12:18 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 756C48FC0C for ; Fri, 18 Feb 2011 02:12:18 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 9D8DF7E8D6; Fri, 18 Feb 2011 13:12:16 +1100 (EST) Message-ID: <4D5DD580.9040701@freebsd.org> Date: Fri, 18 Feb 2011 13:12:16 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.13) Gecko/20101214 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: krad References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-fs@freebsd.org Subject: Re: zfs boot on 4k drives in -STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 02:12:18 -0000 On 02/17/11 20:30, krad wrote: > Hi, > > What is the current state of zfs booting of a 4k aligned drive > (ashift=12)? I have tried the patch in pr153695 but it wont apply > cleanly to stable as I think it is meant for current. Is one going to > be made available for STABLE at any point? It works fine. Use the gptzfsboot and zfsloader from here and you're good to go - no patches or anything else required: http://people.freebsd.org/~pjd/zfsboot/ Cheers, Lawrence From owner-freebsd-fs@FreeBSD.ORG Fri Feb 18 08:36:11 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075F7106566C for ; Fri, 18 Feb 2011 08:36:11 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6E98FC15 for ; Fri, 18 Feb 2011 08:36:10 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1I8a7jT003519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Feb 2011 19:36:08 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p1I8a6HX026473 for ; Fri, 18 Feb 2011 19:36:06 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p1I8a6pe026472 for freebsd-fs@freebsd.org; Fri, 18 Feb 2011 19:36:06 +1100 (EST) (envelope-from peter) Date: Fri, 18 Feb 2011 19:36:06 +1100 From: Peter Jeremy To: freebsd-fs@freebsd.org Message-ID: <20110218083606.GA26316@server.vk2pj.dyndns.org> References: <20110217011032.GA15027@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <20110217011032.GA15027@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: zfs directory listing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 08:36:11 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Feb-16 17:10:32 -0800, Jeremy Chadwick w= rote: >Simple version, to the OP: your mail server has an immense number of >queued mails in it. You need to find out why and put an end to it. I >also recommend you stop sendmail, "rm -r mqueue ; chown root:daemon >mqueue ; chmod 755 mqueue", then start sendmail again. Note that mqueue contains accepted/acknowledged but undelivered mails. Depending on the host's purpose, deleting them may or may not be acceptable. My suggestion would be to stop sendmail, rename mqueue, create a new mqueue and restart sendmail - which will restore mail processing. You can then either delete the old (renamed) mqueue or gradually move groups of df/qf/xf files from there to the new mqueue for processing. --=20 Peter Jeremy --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk1eL3YACgkQ/opHv/APuIfhLQCgmJ+GzLn7n6C9Wf0XXJcVwTM9 HZsAn2zBZpql4u45om8f0WTIU1p7ffKl =3V8S -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 18 21:34:27 2011 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CA461065670 for ; Fri, 18 Feb 2011 21:34:27 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id D0D2A8FC15 for ; Fri, 18 Feb 2011 21:34:26 +0000 (UTC) Received: from [192.168.4.138] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.4/8.14.4) with ESMTP id p1ILYPbd044408 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 18 Feb 2011 14:34:25 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-ID: <4D5EE5DF.8050003@scsiguy.com> Date: Fri, 18 Feb 2011 14:34:23 -0700 From: "Justin T. Gibbs" Organization: SCSIGuy.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14) Gecko/20110207 Thunderbird/3.1.8 MIME-Version: 1.0 To: fs@FreeBSD.org Content-Type: multipart/mixed; boundary="------------020902030300090400070909" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (aslan.scsiguy.com [70.89.174.89]); Fri, 18 Feb 2011 14:34:25 -0700 (MST) Cc: Subject: [ZFS][PATCH] Read-only root file system prevents SPA event processing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gibbs@scsiguy.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 21:34:27 -0000 This is a multi-part message in MIME format. --------------020902030300090400070909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ZFS blocks certain types of asynchronous event processing when the root file system is mounted read-only. This can prevent ZFS from closing leaf vdev devices when they go away, from re-probing vdevs when they experience an error, and from performing certain re-silver actions. See the lengthy change comments in the attached patch (against a fairly recent -current) for a full description of the bug and how I fixed it. Review and comments welcome. -- Justin --------------020902030300090400070909 Content-Type: text/plain; name="zfs_cache.diffs" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfs_cache.diffs" Change 478953 by justing@justing-ns1 on 2011/02/18 09:54:56 Allow ZFS asynchronous event handling to proceed even if the root file system is mounted read-only. This restriction appears to have been put in place to avoid errors with updating the configuration cache file. However: o The majority of asynchronous event handling does not involve configuration cache file updates. o The configuration cache file need not be on the root file system, so the check was not complete. o Other classes of errors (e.g. file system full) can also prevent a successful update yet do not prevent asynchronous event processing. o Configurations such as NanoBSD never have a read-write root, so ZFS event processing is permanently disabled in these systems. o Failure to handle asynchronous events promptly can extend the window of time that a pool is in a critical state. At worst, a missed configuration cache update will force the operator to perform a manual "zfs import" (note -f is not required) to inform the system about a newly created pool. To minimize the likelihood of this rare occurrence, configuration cache write failures now emit FMA events (via devctl) so the operator can take corrective action, and the write is retried every 5 minutes. The retry interval, in seconds, is tunable via the sysctl "vfs.zfs.ccw_retry_interval". As a side effect of reporting configuration cache events, other sysevents, such as re-silver start/stop, are now also reported via devctl. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: o As is done in zfs_fm.c, provide a manual declaration for devctl_notify(). Both declarations could be combined into spa_impl.h, but the declaration is fault management related, not spa specific. sys/fm/fs/zfs.h would be ideal if it weren't so public and reserved for FMA string definitions. I'm open to suggestions on how to improve this nit while minimizing our divergence from Solaris. o Use devctl_notify() to implement sysevent support in spa_event_notify(). The subsystem is EC_ZFS so that these events can never collide with those emitted in zfs_fm.c. o Add the sysctl "vfs.zfs.ccw_retry_interval". The value defaults to 5 minutes and is used to rate limit, on a per-pool basis, configuration cache file write attempts. o Modify spa_async_dispatch to honor configuration cache write limiting. If other events are pending, a configuration cache write will be attempted at the same time, so the rate limiting only applies when the asynchronous dispatch system is otherwise idle. Async events should be rare (e.g. device arrival/departure) and configuration cache writes rarer, so a more complicated system to strictly honor the retry limit seems unwarranted. o Remove check in spa_async_dispatch() for the root file system being read-write. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c: Instead of silently ignoring configuration cache write failures, report them via a new FMA event as well as to the console. The current zfs_ereport_post() doesn't allow arbitrary name=value pairs to be appended to the report, so the configuration cache file name is only available on the console output. This limitation should be addressed in a future update. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h: Add a uint64_t to the spa data structure to track the time (via LBOLT) of the last configuration cache file write failure. This is referenced in spa_async_dispatch() to effect the rate limiting. sys/cddl/contrib/opensolaris/uts/common/sys/fm/fs/zfs.h: Add FM_EREPORT_ZFS_CONFIG_CACHE_WRITE as an ereport class. Affected files ... ... //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c#5 edit ... //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c#3 edit ... //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h#5 edit ... //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/sys/fm/fs/zfs.h#3 edit Differences ... ==== //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c#5 (text) ==== @@ -62,13 +62,29 @@ #include "zfs_prop.h" #include "zfs_comutil.h" +#ifdef _KERNEL +/* Including sys/bus.h is just too hard, so I declare what I need here. */ +extern void devctl_notify(const char *__system, const char *__subsystem, + const char *__type, const char *__data); +#endif + /* Check hostid on import? */ static int check_hostid = 1; +/* + * The interval at which failed configuration cache file writes + * should be retried. + */ +static int zfs_ccw_retry_interval = 300; + SYSCTL_DECL(_vfs_zfs); TUNABLE_INT("vfs.zfs.check_hostid", &check_hostid); SYSCTL_INT(_vfs_zfs, OID_AUTO, check_hostid, CTLFLAG_RW, &check_hostid, 0, "Check hostid on import?"); +TUNABLE_INT("vfs.zfs.ccw_retry_interval", &zfs_ccw_retry_interval); +SYSCTL_INT(_vfs_zfs, OID_AUTO, ccw_retry_interval, CTLFLAG_RW, + &zfs_ccw_retry_interval, 0, + "Configuration cache file write, retry after failure, interval (seconds)"); enum zti_modes { zti_mode_fixed, /* value is # of threads (min 1) */ @@ -3819,13 +3835,33 @@ mutex_exit(&spa->spa_async_lock); } +static int +spa_async_tasks_pending(spa_t *spa) +{ + u_int non_config_tasks; + u_int config_task; + uint64_t time_since_ccw_failure; + boolean_t config_task_suspended; + + non_config_tasks = spa->spa_async_tasks & ~SPA_ASYNC_CONFIG_UPDATE; + config_task = spa->spa_async_tasks & SPA_ASYNC_CONFIG_UPDATE; + if (time_since_ccw_failure == 0) + config_task_suspended = B_FALSE; + else + config_task_suspended = (LBOLT - spa->spa_ccw_fail_time) + < (zfs_ccw_retry_interval * hz); + + return (non_config_tasks || (config_task && !config_task_suspended)); +} + static void spa_async_dispatch(spa_t *spa) { mutex_enter(&spa->spa_async_lock); - if (spa->spa_async_tasks && !spa->spa_async_suspended && + if (spa_async_tasks_pending(spa) && + !spa->spa_async_suspended && spa->spa_async_thread == NULL && - rootdir != NULL && !vn_is_readonly(rootdir)) + rootdir != NULL) spa->spa_async_thread = thread_create(NULL, 0, spa_async_thread, spa, 0, &p0, TS_RUN, maxclsyspri); mutex_exit(&spa->spa_async_lock); @@ -4479,52 +4515,40 @@ void spa_event_notify(spa_t *spa, vdev_t *vd, const char *name) { -#if 0 #ifdef _KERNEL - sysevent_t *ev; - sysevent_attr_list_t *attr = NULL; - sysevent_value_t value; - sysevent_id_t eid; + char buf[1024]; + struct sbuf sb; + struct timespec ts; + int error; + + nanotime(&ts); - ev = sysevent_alloc(EC_ZFS, (char *)name, SUNW_KERN_PUB "zfs", - SE_SLEEP); + sbuf_new(&sb, buf, sizeof(buf), SBUF_FIXEDLEN); + sbuf_printf(&sb, "time=%ju.%ld", (uintmax_t)ts.tv_sec, ts.tv_nsec); - value.value_type = SE_DATA_TYPE_STRING; - value.value.sv_string = spa_name(spa); - if (sysevent_add_attr(&attr, ZFS_EV_POOL_NAME, &value, SE_SLEEP) != 0) - goto done; + /* + * Serialize sysevent and ereport generation. + */ + mutex_enter(&spa->spa_errlist_lock); - value.value_type = SE_DATA_TYPE_UINT64; - value.value.sv_uint64 = spa_guid(spa); - if (sysevent_add_attr(&attr, ZFS_EV_POOL_GUID, &value, SE_SLEEP) != 0) - goto done; + sbuf_printf(&sb, " %s=%s", ZFS_EV_POOL_NAME, spa_name(spa)); + sbuf_printf(&sb, " %s=%ju", ZFS_EV_POOL_GUID, spa_guid(spa)); if (vd) { - value.value_type = SE_DATA_TYPE_UINT64; - value.value.sv_uint64 = vd->vdev_guid; - if (sysevent_add_attr(&attr, ZFS_EV_VDEV_GUID, &value, - SE_SLEEP) != 0) - goto done; + sbuf_printf(&sb, " %s=%ju", ZFS_EV_VDEV_GUID, vd->vdev_guid); if (vd->vdev_path) { - value.value_type = SE_DATA_TYPE_STRING; - value.value.sv_string = vd->vdev_path; - if (sysevent_add_attr(&attr, ZFS_EV_VDEV_PATH, - &value, SE_SLEEP) != 0) - goto done; + sbuf_printf(&sb, " %s=%s", ZFS_EV_VDEV_PATH, + vd->vdev_path); } } - if (sysevent_attach_attributes(ev, attr) != 0) - goto done; - attr = NULL; + mutex_exit(&spa->spa_errlist_lock); - (void) log_sysevent(ev, SE_SLEEP, &eid); - -done: - if (attr) - sysevent_free_attr(attr); - sysevent_free(ev); -#endif + error = sbuf_finish(&sb); + devctl_notify("ZFS", EC_ZFS, name, sbuf_data(&sb)); + if (error != 0) + printf("ZFS WARNING: sysevent sbuf overflowed.\n"); + sbuf_delete(&sb); #endif } ==== //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c#3 (text) ==== @@ -25,6 +25,7 @@ */ #include +#include #include #include #include @@ -151,20 +152,21 @@ kobj_close_file(file); } -static void +static int spa_config_write(spa_config_dirent_t *dp, nvlist_t *nvl) { int oflags = FWRITE | FTRUNC | FCREAT | FOFFMAX; char *buf, *temp; size_t buflen; vnode_t *vp; + int err; /* * If the nvlist is empty (NULL), then remove the old cachefile. */ if (nvl == NULL) { - (void) vn_remove(dp->scd_path, UIO_SYSSPACE, RMFILE); - return; + err = vn_remove(dp->scd_path, UIO_SYSSPACE, RMFILE); + return (err); } /* @@ -185,11 +187,12 @@ */ (void) snprintf(temp, MAXPATHLEN, "%s.tmp", dp->scd_path); - if (vn_open(temp, UIO_SYSSPACE, oflags, 0644, &vp, CRCREAT, 0) == 0) { - if (vn_rdwr(UIO_WRITE, vp, buf, buflen, 0, UIO_SYSSPACE, - 0, RLIM64_INFINITY, kcred, NULL) == 0 && - VOP_FSYNC(vp, FSYNC, kcred, NULL) == 0) { - (void) vn_rename(temp, dp->scd_path, UIO_SYSSPACE); + err = vn_open(temp, UIO_SYSSPACE, oflags, 0644, &vp, CRCREAT, 0); + if (err == 0) { + if ((err = vn_rdwr(UIO_WRITE, vp, buf, buflen, 0, UIO_SYSSPACE, + 0, RLIM64_INFINITY, kcred, NULL)) == 0 && + (err = VOP_FSYNC(vp, FSYNC, kcred, NULL)) == 0) { + err = vn_rename(temp, dp->scd_path, UIO_SYSSPACE); } (void) VOP_CLOSE(vp, oflags, 1, 0, kcred, NULL); } @@ -198,6 +201,7 @@ kmem_free(buf, buflen); kmem_free(temp, MAXPATHLEN); + return (err); } /* @@ -209,6 +213,8 @@ { spa_config_dirent_t *dp, *tdp; nvlist_t *nvl; + boolean_t ccw_failure; + int error; ASSERT(MUTEX_HELD(&spa_namespace_lock)); @@ -220,6 +226,7 @@ * cachefile is changed, the new one is pushed onto this list, allowing * us to update previous cachefiles that no longer contain this pool. */ + ccw_failure = B_FALSE; for (dp = list_head(&target->spa_config_list); dp != NULL; dp = list_next(&target->spa_config_list, dp)) { spa_t *spa = NULL; @@ -252,10 +259,35 @@ mutex_exit(&spa->spa_props_lock); } - spa_config_write(dp, nvl); + error = spa_config_write(dp, nvl); + if (error != 0) { + + printf("ZFS ERROR: Update of cache file %s failed: " + "Errno %d\n", dp->scd_path, error); + ccw_failure = B_TRUE; + } + nvlist_free(nvl); } + if (ccw_failure) { + /* + * Keep trying so that configuration data is + * written if/when any temporary filesystem + * resource issues are resolved. + */ + target->spa_ccw_fail_time = LBOLT; + spa_async_request(target, SPA_ASYNC_CONFIG_UPDATE); + zfs_ereport_post(FM_EREPORT_ZFS_CONFIG_CACHE_WRITE, + target, NULL, NULL, 0, 0); + } else { + /* + * Do not rate limit future attempts to update + * the config cache. + */ + target->spa_ccw_fail_time = 0; + } + /* * Remove any config entries older than the current one. */ ==== //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h#5 (text) ==== @@ -172,6 +172,7 @@ int spa_minref; /* num refs when first opened */ int spa_mode; /* FREAD | FWRITE */ spa_log_state_t spa_log_state; /* log state */ + uint64_t spa_ccw_fail_time; /* Conf cache write fail time */ /* * spa_refcnt & spa_config_lock must be the last elements * because refcount_t changes size based on compilation options. ==== //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/sys/fm/fs/zfs.h#3 (text) ==== @@ -46,6 +46,7 @@ #define FM_EREPORT_ZFS_IO_FAILURE "io_failure" #define FM_EREPORT_ZFS_PROBE_FAILURE "probe_failure" #define FM_EREPORT_ZFS_LOG_REPLAY "log_replay" +#define FM_EREPORT_ZFS_CONFIG_CACHE_WRITE "config_cache_write" #define FM_EREPORT_PAYLOAD_ZFS_POOL "pool" #define FM_EREPORT_PAYLOAD_ZFS_POOL_FAILMODE "pool_failmode" --------------020902030300090400070909-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 18 21:38:10 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7A11065670 for ; Fri, 18 Feb 2011 21:38:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE8E8FC13 for ; Fri, 18 Feb 2011 21:38:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAO10Xk2DaFvO/2dsb2JhbACEIKJ8qlyQPoEng0F2BIULhwY X-IronPort-AV: E=Sophos;i="4.62,189,1297054800"; d="scan'208";a="110338324" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 18 Feb 2011 16:38:09 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 40D27B3F3D; Fri, 18 Feb 2011 16:38:09 -0500 (EST) Date: Fri, 18 Feb 2011 16:38:09 -0500 (EST) From: Rick Macklem To: Lawrence Stewart Message-ID: <996838892.118259.1298065089198.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4D5DC770.2090308@freebsd.org> 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 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: Mounting NFSv4 as root fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 21:38:10 -0000 > Hi Rick, > > I've set up a NFS server to pxeboot a set of testbed clients from. The > server filesystem tree the client needs to use as its root has nullfs > mounted directories in it. Therefore, NFSv4 is the only useful way to > mount it on the client because of the cross mount point traversing > capabilities built into v4. I've verified that I can "mount_nfs -o > nfsv4 > ..." on the command line and see all the files in the tree so I have > things working fine on the server side. > > I was aware our pxeboot only supports NFSv3, but hoped that by > specifying "newfs" and "nfsv4" in the fstype and options fields > respectively in fstab that things might just work when the mount root > step after the kernel boot happens. It doesn't as I found out, because > of two issues: > > 1. I believe there is a bug in the newnfs code. nfs_diskless.c wasn't > copied from the old nfsclient and suitably modified for use with > newnfs. > As a result during boot, the ncl_mountroot() function in > nfs_clvfsops.c > calls nfs_setup_diskless() which calls into the old nfs code and > badness > happens from there on in. I have a patch which fixes this issue, > though > it may be completely the wrong way to do things as I'm very new (as in > 24 hours new) to the NFS code. > Yep. I didn't see an easy way to set up the diskless root so that it would work for both clients concurrently, so I was planning on switching it if/when "newnfs" becomes the default client. (You can switch fairly easily. Just crib the code across, as it sounds like you have and then make sure the xxx_mountroot() in "newnfs" gets called instead of nfs_mountroot() in the other one. However, that will just get a "newnfs" NFSv3 root mount to work. > 2. pxeboot stores the filehandle and filehandle length it used to grab > the kernel via NFS in the kernel's env and after the kernel has > booted, > it looks for these variables and reuses them i.e. at no point in the > process does the code attempt to upgrade to NFSv4 if the bootstrap > uses > NFSv3 to grab the kernel. > > For my particular use case, I'm quite happy for the kernel to be > pulled > via NFSv3, but can't boot the client without somehow getting the > client > to switch to NFSv4 at the point where it mount's root after the kernel > has finished booting. > > I tried a very hacky test in mountnfs() in nfs_clvfsops.c to see if I > could set the NFSV4 flag, unset the V3 flag and tell the code to > forget > about the cached file handle set by the loader just to see if the code > would try to renegotiate using v4... it crashed and burned. > The same file handle should work for NFSv4 (at least a FReeBSD server generates the same FH for a v3 vs v4 mount). > So, before I spend any more time on this, I hope to get your (or > anyone > else reading for that matter) thoughts on how best to proceed. Some > questions: > > - Could you guesstimate how much work is involved to get v4 support > into > libstand so that pxeboot can talk v4 natively? I spent quite some time > poking at libstand's code last night but don't understand the NFSv4 > RPC > mechanism enough to attempt writing the basic code to do it yet. The > RFC > explains the ordering of OPs needed quit well but I don't quite grok > how > the data structures for interpreting responses work. > Lots. It will be easier to get the kernel to use v4 after pxeboot has loaded it via v3. > - Can you think of a hacky simple way to force my client to > renegotiate > the mount as v4 at the time mount root happens? > If you are will to spend man weeks on this, you can probably get something to work for your lab (useless for others, because you'll have to hard wire a bunch of stuff into the kernel like your DNS domain name...). I have never intended to try and make an NFSv4 root mount work. (Someone said NFSv4 is NFS in name only:-) One of the most difficult parts will be the uid/gid<->name mapping. You would have to hack this enough so that it worked without nfsuserd. Something like hard wiring mappings into the kernel cache for enough entries that the root works. (Note that names look like root@cis.uoguelph.ca, so it needs to know the DNS domain as well as "root" == uid 0.) Then hopefully you don't need other mappings to work, because it would have to work without nfsuserd running and with nfsuserd running (in the root fs). Short answer. A severely hacked kernel might work for your lab, but a generic solution for FreeBSD would be very difficult. If you could move the "nullfs" mounts down a level, so the NFSv4 mount was below an NFSv3 root fs, that would be much easier. rick From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 00:00:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7431065670 for ; Sat, 19 Feb 2011 00:00:40 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 239028FC0A for ; Sat, 19 Feb 2011 00:00:39 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id B532D7E8D5; Sat, 19 Feb 2011 11:00:37 +1100 (EST) Message-ID: <4D5F0825.9010607@freebsd.org> Date: Sat, 19 Feb 2011 11:00:37 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.13) Gecko/20101214 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Rick Macklem References: <996838892.118259.1298065089198.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <996838892.118259.1298065089198.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-fs@freebsd.org Subject: Re: Mounting NFSv4 as root fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 00:00:40 -0000 On 02/19/11 08:38, Rick Macklem wrote: >> Hi Rick, >> >> I've set up a NFS server to pxeboot a set of testbed clients from. The >> server filesystem tree the client needs to use as its root has nullfs >> mounted directories in it. Therefore, NFSv4 is the only useful way to >> mount it on the client because of the cross mount point traversing >> capabilities built into v4. I've verified that I can "mount_nfs -o >> nfsv4 >> ..." on the command line and see all the files in the tree so I have >> things working fine on the server side. >> >> I was aware our pxeboot only supports NFSv3, but hoped that by >> specifying "newfs" and "nfsv4" in the fstype and options fields >> respectively in fstab that things might just work when the mount root >> step after the kernel boot happens. It doesn't as I found out, because >> of two issues: >> >> 1. I believe there is a bug in the newnfs code. nfs_diskless.c wasn't >> copied from the old nfsclient and suitably modified for use with >> newnfs. >> As a result during boot, the ncl_mountroot() function in >> nfs_clvfsops.c >> calls nfs_setup_diskless() which calls into the old nfs code and >> badness >> happens from there on in. I have a patch which fixes this issue, >> though >> it may be completely the wrong way to do things as I'm very new (as in >> 24 hours new) to the NFS code. >> > Yep. I didn't see an easy way to set up the diskless root so that it would > work for both clients concurrently, so I was planning on switching it if/when > "newnfs" becomes the default client. (You can switch fairly easily. Just > crib the code across, as it sounds like you have and then make sure the > xxx_mountroot() in "newnfs" gets called instead of nfs_mountroot() in the > other one. Yes that's exactly what I did. > However, that will just get a "newnfs" NFSv3 root mount to work. Yup, confirmed working as expected (mount output shows "newnfs" for / whereas before it would fall back to "nfs" after the newnfs code crapped out. >> 2. pxeboot stores the filehandle and filehandle length it used to grab >> the kernel via NFS in the kernel's env and after the kernel has >> booted, >> it looks for these variables and reuses them i.e. at no point in the >> process does the code attempt to upgrade to NFSv4 if the bootstrap >> uses >> NFSv3 to grab the kernel. >> >> For my particular use case, I'm quite happy for the kernel to be >> pulled >> via NFSv3, but can't boot the client without somehow getting the >> client >> to switch to NFSv4 at the point where it mount's root after the kernel >> has finished booting. >> >> I tried a very hacky test in mountnfs() in nfs_clvfsops.c to see if I >> could set the NFSV4 flag, unset the V3 flag and tell the code to >> forget >> about the cached file handle set by the loader just to see if the code >> would try to renegotiate using v4... it crashed and burned. >> > The same file handle should work for NFSv4 (at least a FReeBSD server > generates the same FH for a v3 vs v4 mount). Ah, interesting and good to know, thanks. So assuming the server is v4 capable, you can just start issuing v4 RPCs to the handle established by pxeboot and things should keep working? >> So, before I spend any more time on this, I hope to get your (or >> anyone >> else reading for that matter) thoughts on how best to proceed. Some >> questions: >> >> - Could you guesstimate how much work is involved to get v4 support >> into >> libstand so that pxeboot can talk v4 natively? I spent quite some time >> poking at libstand's code last night but don't understand the NFSv4 >> RPC >> mechanism enough to attempt writing the basic code to do it yet. The >> RFC >> explains the ordering of OPs needed quit well but I don't quite grok >> how >> the data structures for interpreting responses work. >> > Lots. It will be easier to get the kernel to use v4 after pxeboot has > loaded it via v3. ACK. >> - Can you think of a hacky simple way to force my client to >> renegotiate >> the mount as v4 at the time mount root happens? >> > If you are will to spend man weeks on this, you can probably get > something to work for your lab (useless for others, because you'll > have to hard wire a bunch of stuff into the kernel like your DNS > domain name...). > > I have never intended to try and make an NFSv4 root mount work. > (Someone said NFSv4 is NFS in name only:-) > > One of the most difficult parts will be the uid/gid<->name mapping. > You would have to hack this enough so that it worked without nfsuserd. > Something like hard wiring mappings into the kernel cache for enough > entries that the root works. (Note that names look like root@cis.uoguelph.ca, > so it needs to know the DNS domain as well as "root" == uid 0.) > Then hopefully you don't need other mappings to work, because it would > have to work without nfsuserd running and with nfsuserd running (in the > root fs). > > Short answer. A severely hacked kernel might work for your lab, but a > generic solution for FreeBSD would be very difficult. Thanks heaps for the brain dump, it really helps put things in perspective. It's sounding like a much bigger job than I thought it would be, even for a hacked up lab-only solution. > If you could move the "nullfs" mounts down a level, so the NFSv4 mount > was below an NFSv3 root fs, that would be much easier. Agreed. The issue is we're using the ezjail management script from ports to manage the bootable client filesystems on the server, and it uses nullfs mounts between a base filesystem and the client filesystems to avoid duplicating all the utilities/libs in /bin, /sbin, /lib and /libexec multiple times. Works well but not for this use case... oh well. I guess it will be significantly easier to hack ezjail to just copy the dirs from the basejail into each client rather than try get the all singing all dancing NFSv4 option going. Thanks again for your insights. Cheers, Lawrence From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 05:11:43 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82A95106566B for ; Sat, 19 Feb 2011 05:11:43 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1FD8FC0C for ; Sat, 19 Feb 2011 05:11:43 +0000 (UTC) Received: by iwn39 with SMTP id 39so4399689iwn.13 for ; Fri, 18 Feb 2011 21:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=d5FaSk/UJYKPxlSbZkjBMhBM/xr0jf84xZp+PFhYXwQ=; b=SBnky/2wvVrdJbCtPXJkt4wgI+DW+NZdvseoGBWo1tzXJv5Q2QqhwoGBbt9FnRCSnX I0X25TVOCPh+ag4AJt0lo9CWruhxaXO3QV0q6l8cnohy8vJma1M90GYi2/5aOAQ1uZJW bGvRzRykcx3rsCA6f9TJQP9ogXCuBCWS697+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=moMeDKiXLOqOWV88GX50PL89PbqTcmQXHzUAG81SWkSgbarnr38ltqQckTc55HWBSt tsLcF2AtgBr6GLlLxYH30zjipSOWmkrfKS15pKh444WhL2zsTyzi1RezDoGPNN67XgVK cj752eFhhFDKoR1O+zm38ZG9gr451kNrLGSYg= MIME-Version: 1.0 Received: by 10.42.72.133 with SMTP id o5mr1842185icj.315.1298090568305; Fri, 18 Feb 2011 20:42:48 -0800 (PST) Received: by 10.42.225.193 with HTTP; Fri, 18 Feb 2011 20:42:48 -0800 (PST) Date: Sat, 19 Feb 2011 12:42:48 +0800 Message-ID: From: dave jones To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: msdosfs kernel panic with a broken usb flash drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 05:11:43 -0000 Hello, Recently I have two broken USB thumb drives. I tried to mount /dev/da0s1 by using mount_msdosfs /dev/da0s1 /mnt, and I got the kernel panic. I tried another broken usb drive, the result is the same, kernel panic. I also tried it on Linux using "mount -t /dev/sdb1 /mnt", no panic. Does it make sense that mounting broken USB drives would cause the kernel panic? Any idea how to solve this issue? thank you. Regards, Dave. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 08:59:29 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63081106564A for ; Sat, 19 Feb 2011 08:59:29 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6EC8FC12 for ; Sat, 19 Feb 2011 08:59:28 +0000 (UTC) Received: by pvc22 with SMTP id 22so727728pvc.13 for ; Sat, 19 Feb 2011 00:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=iPbRFJtQ9oGLkujcePkR2St7X/9wM7JCDI0jg5Tddpo=; b=S5sh8xhZ4W47upkuC7L6SAB7dUcm9DJItsd1zlHl+wzQUaYT8UXTlZtVkYnV8HavZ9 hncKofLveVe3odmYyd/zlZHTU8e6xCuUqCZW6JkwYVlgWs4Hj6eVD+/Neq8ALQrF0L7L YZuf6yvC44wkw3l8eVHH/jFy0Ju/Lz8zMsS+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jmlf+IgoBDfdvO0765fUWy7yYoWbvj8rYALpqkFPBh5GC4VzNUWNGMLvilMl6UWf5y j1EOmoDuiVZ4aMhXZy/0873Jaz6eXFStN/7UYCWV2zlSjBGOUPsrVN9ROOsZVD0meD1d 4vNRgq+JGyYnRu8GGMY6BrbbjKhvnky2FVYMU= MIME-Version: 1.0 Received: by 10.143.13.4 with SMTP id q4mr1071763wfi.418.1298104363273; Sat, 19 Feb 2011 00:32:43 -0800 (PST) Received: by 10.142.128.18 with HTTP; Sat, 19 Feb 2011 00:32:43 -0800 (PST) Date: Sat, 19 Feb 2011 03:32:43 -0500 Message-ID: From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ZFS][PATCH] Read-only root file system prevents SPA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 08:59:29 -0000 Justin, et al... >From a user perspective, sounds great! Always thought the cachefile was a pain. For example, some systems use encrypted pools, for which ZFS is rightly unaware of them until the cleartext devices are attached. ZFS SPA's attempts to manage it early in the process were annoying too. On lots of machines, the root fs (/) is read-only from power on. If a cache is desired, the cachefile parameter is set to either a tiny ufs state partition or mfs. Or /boot/zfs is mounted on the either of same via fstab. If not, cachefile=none :) zpool import -a still works regardless of the cache because it tastes all the devices, including CD-ROM's, heh. Works for me. With the configuration on disk as a design feature of ZFS, I'm not really sure of the need for a cachefile anyways. Other than maybe to limit tasting for a specific pool to select devices. Or having the kernel automagically do the zpool import -a (actually whatever subset of pools was in use previously) part for you on boot. BTW, there is no "zfs import" command. Nor is there a plain "zpool import" that does an import without further arguments. Though it does do the tasting and listing. And I'm not sure if, as with the un-writeable case, setting cachefile=none would also erroneously prevent needed events from occuring. If so, that should be fixed as well. Having vfs.zfs.ccw_retry_interval=0 meaning 'never update' would be fine. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 09:57:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 719E81065673 for ; Sat, 19 Feb 2011 09:57:30 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id F3FE58FC1B for ; Sat, 19 Feb 2011 09:57:29 +0000 (UTC) Received: by fxm19 with SMTP id 19so1168451fxm.13 for ; Sat, 19 Feb 2011 01:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=e/h/gwa9YvQ4660nXgBK19eH7B8fuMy2Inx1uFMdns0=; b=hmg9qcTwCZ2L1Gq8ZpM5uAN93AVTY5bu2/FTdi72G9fBLsFQB2EqY0N9pYm84FH5ar A51titu96vMEQe1SSBorVAH5YO062pNmO/LchLZ3chF97ZYRS3OwPqdgrsCkRHl+HWCv VTUPFstDd/XaEmRWiiRWFz96nwvKFZfPZMY6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=qH1HH7mI3enSydQ4aDEKBxVIOKQUx2XEz9PRqjQMBznYxrzfpFVX0y49x0TQ/h3eGk uVVoo3zI/Jmx9+ZFXTe9l7cq0eg/j3cVtaKOeri1BW6z5yJ/XeHI54tMDpac1i9t3FcO OHO0qj8KSGJCkKo5Pec1CAxupIcZ6niA1DEDI= Received: by 10.223.86.13 with SMTP id q13mr2283717fal.53.1298109396853; Sat, 19 Feb 2011 01:56:36 -0800 (PST) Received: from ernst.jennejohn.org (p578E384B.dip.t-dialin.net [87.142.56.75]) by mx.google.com with ESMTPS id a2sm224412faw.22.2011.02.19.01.56.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Feb 2011 01:56:35 -0800 (PST) Date: Sat, 19 Feb 2011 10:56:34 +0100 From: Gary Jennejohn To: dave jones Message-ID: <20110219105634.1c5e4402@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: msdosfs kernel panic with a broken usb flash drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 09:57:30 -0000 On Sat, 19 Feb 2011 12:42:48 +0800 dave jones wrote: > Recently I have two broken USB thumb drives. I tried to mount /dev/da0s1 > by using mount_msdosfs /dev/da0s1 /mnt, and I got the kernel panic. > I tried another broken usb drive, the result is the same, kernel panic. > I also tried it on Linux using "mount -t /dev/sdb1 /mnt", no panic. > > Does it make sense that mounting broken USB drives would cause the > kernel panic? > Any idea how to solve this issue? thank you. > Without back trace from ddb or a kernel crash dump it would a little difficult for anyone to provide an intelligent answer. -- Gary Jennejohn From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 10:55:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E69C106564A for ; Sat, 19 Feb 2011 10:55:35 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C4A7A8FC14 for ; Sat, 19 Feb 2011 10:55:34 +0000 (UTC) Received: by wyb32 with SMTP id 32so350411wyb.13 for ; Sat, 19 Feb 2011 02:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ci5W3dDDta3JX4HEeChNljrx1oAz3lUgx54etVTuK1s=; b=FvFS+oTib6QpSEo5onpwRVJEeSJTHMpoVdfQ8wQk5ddh2w6G0UIfMGufnUeIGK+5VJ g6kdPtDxEaW1NB25kR2cjg/eM8OJswPsTI9K6ME6NfyiEUFP4CWSK+ps7dpChO4EWRPe y0mlku+R2CVix/NoaeC+jlFhRM7McYWVrqh3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MkbDlQvinxcPX5PTQPzqJBAFzg+pDkSoKXcmY8KAApJhlQ2LO1+mlcgulaYvKSzcE4 qAMn4tHi9md+0daDMDPd2XuJpkk+TmcapJlFmre1z6JOd6rQQb7jISZC/XNZ2JOtEJc1 ZfKOASAJzA5bEhaWN4EocE8EWHWEoy7lq0uHA= MIME-Version: 1.0 Received: by 10.216.150.129 with SMTP id z1mr1442712wej.113.1298112933479; Sat, 19 Feb 2011 02:55:33 -0800 (PST) Received: by 10.216.80.147 with HTTP; Sat, 19 Feb 2011 02:55:33 -0800 (PST) In-Reply-To: <4D5DD580.9040701@freebsd.org> References: <4D5DD580.9040701@freebsd.org> Date: Sat, 19 Feb 2011 10:55:33 +0000 Message-ID: From: krad To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: zfs boot on 4k drives in -STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 10:55:35 -0000 On 18 February 2011 02:12, Lawrence Stewart wrote: > On 02/17/11 20:30, krad wrote: >> Hi, >> >> What is the current state of zfs booting of a 4k aligned drive >> (ashift=12)? I have tried the patch in pr153695 but it wont apply >> cleanly to stable as I think it is meant for current. Is one going to >> be made available for STABLE at any point? > > It works fine. Use the gptzfsboot and zfsloader from here and you're > good to go - no patches or anything else required: > > http://people.freebsd.org/~pjd/zfsboot/ > > Cheers, > Lawrence > thanks for the advice ill give it a go From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 13:37:33 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE21106566C; Sat, 19 Feb 2011 13:37:33 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 565238FC0A; Sat, 19 Feb 2011 13:37:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1JDbXqB086833; Sat, 19 Feb 2011 13:37:33 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1JDbXOU086829; Sat, 19 Feb 2011 13:37:33 GMT (envelope-from jh) Date: Sat, 19 Feb 2011 13:37:33 GMT Message-Id: <201102191337.p1JDbXOU086829@freefall.freebsd.org> To: ceri@submonkey.net, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: bin/94635: snapinfo(8)/libufs only works for disk-backed filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 13:37:33 -0000 Synopsis: snapinfo(8)/libufs only works for disk-backed filesystems State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Sat Feb 19 13:37:32 UTC 2011 State-Changed-Why: Reportedly fixed in supported branches. http://www.freebsd.org/cgi/query-pr.cgi?pr=94635 From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 13:39:27 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9254B1065672; Sat, 19 Feb 2011 13:39:27 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 695AE8FC0A; Sat, 19 Feb 2011 13:39:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1JDdROa086966; Sat, 19 Feb 2011 13:39:27 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1JDdQih086962; Sat, 19 Feb 2011 13:39:26 GMT (envelope-from jh) Date: Sat, 19 Feb 2011 13:39:26 GMT Message-Id: <201102191339.p1JDdQih086962@freefall.freebsd.org> To: root@koellers.net, jh@FreeBSD.org, freebsd-fs@FreeBSD.org, jh@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: bin/121779: [ufs] snapinfo(8) (and related tools?) only work for toplevel mount points X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 13:39:27 -0000 Synopsis: [ufs] snapinfo(8) (and related tools?) only work for toplevel mount points State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Sat Feb 19 13:38:24 UTC 2011 State-Changed-Why: I couldn't reproduce this. Can you still reproduce on a supported release? Responsible-Changed-From-To: freebsd-fs->jh Responsible-Changed-By: jh Responsible-Changed-When: Sat Feb 19 13:38:24 UTC 2011 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=121779 From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 14:30:15 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F55106566C for ; Sat, 19 Feb 2011 14:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0448FC18 for ; Sat, 19 Feb 2011 14:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1JEUF5V039938 for ; Sat, 19 Feb 2011 14:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1JEUF3o039932; Sat, 19 Feb 2011 14:30:15 GMT (envelope-from gnats) Date: Sat, 19 Feb 2011 14:30:15 GMT Message-Id: <201102191430.p1JEUF3o039932@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/133614: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 14:30:15 -0000 The following reply was made to PR kern/133614; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/133614: commit references a PR Date: Sat, 19 Feb 2011 14:27:20 +0000 (UTC) Author: jh Date: Sat Feb 19 14:27:14 2011 New Revision: 218852 URL: http://svn.freebsd.org/changeset/base/218852 Log: Don't restore old mount options and flags if VFS_MOUNT(9) succeeds but vfs_export() fails. Restoring old options and flags after successful VFS_MOUNT(9) call may cause the file system internal state to become inconsistent with mount options and flags. Specifically the FFS super block fs_ronly field and the MNT_RDONLY flag may get out of sync. PR: kern/133614 Discussed on: freebsd-hackers Modified: head/sys/kern/vfs_mount.c Modified: head/sys/kern/vfs_mount.c ============================================================================== --- head/sys/kern/vfs_mount.c Sat Feb 19 13:23:13 2011 (r218851) +++ head/sys/kern/vfs_mount.c Sat Feb 19 14:27:14 2011 (r218852) @@ -70,7 +70,7 @@ __FBSDID("$FreeBSD$"); #define VFS_MOUNTARG_SIZE_MAX (1024 * 64) static int vfs_domount(struct thread *td, const char *fstype, - char *fspath, int fsflags, void *fsdata); + char *fspath, int fsflags, struct vfsoptlist **optlist); static void free_mntarg(struct mntarg *ma); static int usermount = 0; @@ -667,7 +667,7 @@ vfs_donmount(struct thread *td, int fsfl goto bail; } - error = vfs_domount(td, fstype, fspath, fsflags, optlist); + error = vfs_domount(td, fstype, fspath, fsflags, &optlist); bail: /* copyout the errmsg */ if (errmsg_pos != -1 && ((2 * errmsg_pos + 1) < fsoptions->uio_iovcnt) @@ -683,7 +683,7 @@ bail: } } - if (error != 0) + if (optlist != NULL) vfs_freeopts(optlist); return (error); } @@ -762,12 +762,12 @@ mount(td, uap) */ static int vfs_domount_first( - struct thread *td, /* Calling thread. */ - struct vfsconf *vfsp, /* File system type. */ - char *fspath, /* Mount path. */ - struct vnode *vp, /* Vnode to be covered. */ - int fsflags, /* Flags common to all filesystems. */ - void *fsdata /* Options local to the filesystem. */ + struct thread *td, /* Calling thread. */ + struct vfsconf *vfsp, /* File system type. */ + char *fspath, /* Mount path. */ + struct vnode *vp, /* Vnode to be covered. */ + int fsflags, /* Flags common to all filesystems. */ + struct vfsoptlist **optlist /* Options local to the filesystem. */ ) { struct vattr va; @@ -807,7 +807,7 @@ vfs_domount_first( /* Allocate and initialize the filesystem. */ mp = vfs_mount_alloc(vp, vfsp, fspath, td->td_ucred); /* XXXMAC: pass to vfs_mount_alloc? */ - mp->mnt_optnew = fsdata; + mp->mnt_optnew = *optlist; /* Set the mount level flags. */ mp->mnt_flag = (fsflags & (MNT_UPDATEMASK | MNT_ROOTFS | MNT_RDONLY)); @@ -830,6 +830,7 @@ vfs_domount_first( if (mp->mnt_opt != NULL) vfs_freeopts(mp->mnt_opt); mp->mnt_opt = mp->mnt_optnew; + *optlist = NULL; (void)VFS_STATFS(mp, &mp->mnt_stat); /* @@ -872,16 +873,16 @@ vfs_domount_first( */ static int vfs_domount_update( - struct thread *td, /* Calling thread. */ - struct vnode *vp, /* Mount point vnode. */ - int fsflags, /* Flags common to all filesystems. */ - void *fsdata /* Options local to the filesystem. */ + struct thread *td, /* Calling thread. */ + struct vnode *vp, /* Mount point vnode. */ + int fsflags, /* Flags common to all filesystems. */ + struct vfsoptlist **optlist /* Options local to the filesystem. */ ) { struct oexport_args oexport; struct export_args export; struct mount *mp; - int error, flag; + int error, export_error, flag; mtx_assert(&Giant, MA_OWNED); ASSERT_VOP_ELOCKED(vp, __func__); @@ -932,7 +933,7 @@ vfs_domount_update( if ((mp->mnt_flag & MNT_ASYNC) == 0) mp->mnt_kern_flag &= ~MNTK_ASYNC; MNT_IUNLOCK(mp); - mp->mnt_optnew = fsdata; + mp->mnt_optnew = *optlist; vfs_mergeopts(mp->mnt_optnew, mp->mnt_opt); /* @@ -942,11 +943,12 @@ vfs_domount_update( */ error = VFS_MOUNT(mp); + export_error = 0; if (error == 0) { /* Process the export option. */ if (vfs_copyopt(mp->mnt_optnew, "export", &export, sizeof(export)) == 0) { - error = vfs_export(mp, &export); + export_error = vfs_export(mp, &export); } else if (vfs_copyopt(mp->mnt_optnew, "export", &oexport, sizeof(oexport)) == 0) { export.ex_flags = oexport.ex_flags; @@ -958,7 +960,7 @@ vfs_domount_update( export.ex_masklen = oexport.ex_masklen; export.ex_indexfile = oexport.ex_indexfile; export.ex_numsecflavors = 0; - error = vfs_export(mp, &export); + export_error = vfs_export(mp, &export); } } @@ -988,6 +990,7 @@ vfs_domount_update( if (mp->mnt_opt != NULL) vfs_freeopts(mp->mnt_opt); mp->mnt_opt = mp->mnt_optnew; + *optlist = NULL; (void)VFS_STATFS(mp, &mp->mnt_stat); /* * Prevent external consumers of mount options from reading @@ -1005,7 +1008,7 @@ end: vp->v_iflag &= ~VI_MOUNT; VI_UNLOCK(vp); vrele(vp); - return (error); + return (error != 0 ? error : export_error); } /* @@ -1013,11 +1016,11 @@ end: */ static int vfs_domount( - struct thread *td, /* Calling thread. */ - const char *fstype, /* Filesystem type. */ - char *fspath, /* Mount path. */ - int fsflags, /* Flags common to all filesystems. */ - void *fsdata /* Options local to the filesystem. */ + struct thread *td, /* Calling thread. */ + const char *fstype, /* Filesystem type. */ + char *fspath, /* Mount path. */ + int fsflags, /* Flags common to all filesystems. */ + struct vfsoptlist **optlist /* Options local to the filesystem. */ ) { struct vfsconf *vfsp; @@ -1087,9 +1090,9 @@ vfs_domount( vp = nd.ni_vp; if ((fsflags & MNT_UPDATE) == 0) { error = vfs_domount_first(td, vfsp, fspath, vp, fsflags, - fsdata); + optlist); } else { - error = vfs_domount_update(td, vp, fsflags, fsdata); + error = vfs_domount_update(td, vp, fsflags, optlist); } mtx_unlock(&Giant); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 14:35:08 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E191410656AA for ; Sat, 19 Feb 2011 14:35:08 +0000 (UTC) (envelope-from domadmin@koellers.net) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4298FC1B for ; Sat, 19 Feb 2011 14:35:08 +0000 (UTC) Received: from [87.245.53.74] (helo=mail.koellers.net) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Pqnhz-000666-L2; Sat, 19 Feb 2011 15:22:51 +0100 Received: from [192.168.1.137] (AMILO [192.168.1.137]) by mail.koellers.net with SMTP; Sat, 19 Feb 2011 15:21:55 +0100 Message-ID: <4D5FD231.60505@koellers.net> Date: Sat, 19 Feb 2011 15:22:41 +0100 From: Domain Admin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: jh@FreeBSD.org References: <201102191339.p1JDdQih086962@freefall.freebsd.org> In-Reply-To: <201102191339.p1JDdQih086962@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: lars@koellers.net Cc: freebsd-fs@FreeBSD.org, root@koellers.net Subject: Re: bin/121779: [ufs] snapinfo(8) (and related tools?) only work for toplevel mount points X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 14:35:09 -0000 Hello, sorry, but I can't repoduce this anymore. The server and installation is now running Solaris. Am 19.02.2011 14:39, schrieb jh@FreeBSD.org: > Synopsis: [ufs] snapinfo(8) (and related tools?) only work for toplevel mount points > > State-Changed-From-To: open->feedback > State-Changed-By: jh > State-Changed-When: Sat Feb 19 13:38:24 UTC 2011 > State-Changed-Why: > I couldn't reproduce this. Can you still reproduce on a supported release? > > > Responsible-Changed-From-To: freebsd-fs->jh > Responsible-Changed-By: jh > Responsible-Changed-When: Sat Feb 19 13:38:24 UTC 2011 > Responsible-Changed-Why: > Track. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121779 > Best regards Lars -- E-Mail: Lars@koellers.net From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 21:07:41 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 044C910656A3; Sat, 19 Feb 2011 21:07:41 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CFA9A8FC13; Sat, 19 Feb 2011 21:07:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1JL7e9v066297; Sat, 19 Feb 2011 21:07:40 GMT (envelope-from alc@freefall.freebsd.org) Received: (from alc@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1JL7edL066293; Sat, 19 Feb 2011 21:07:40 GMT (envelope-from alc) Date: Sat, 19 Feb 2011 21:07:40 GMT Message-Id: <201102192107.p1JL7edL066293@freefall.freebsd.org> To: citrin@citrin.ru, alc@FreeBSD.org, freebsd-fs@FreeBSD.org From: alc@FreeBSD.org Cc: Subject: Re: kern/152488: [tmpfs] [patch] mtime of file updated when only inode changed (file data not changed) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 21:07:41 -0000 Synopsis: [tmpfs] [patch] mtime of file updated when only inode changed (file data not changed) State-Changed-From-To: open->patched State-Changed-By: alc State-Changed-When: Sat Feb 19 21:06:57 UTC 2011 State-Changed-Why: Change applied to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=152488 From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 21:10:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5BB61065672 for ; Sat, 19 Feb 2011 21:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B63898FC08 for ; Sat, 19 Feb 2011 21:10:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1JLAALu066431 for ; Sat, 19 Feb 2011 21:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1JLAAZa066430; Sat, 19 Feb 2011 21:10:10 GMT (envelope-from gnats) Date: Sat, 19 Feb 2011 21:10:10 GMT Message-Id: <201102192110.p1JLAAZa066430@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/152488: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 21:10:10 -0000 The following reply was made to PR kern/152488; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/152488: commit references a PR Date: Sat, 19 Feb 2011 21:04:41 +0000 (UTC) Author: alc Date: Sat Feb 19 21:04:36 2011 New Revision: 218863 URL: http://svn.freebsd.org/changeset/base/218863 Log: tmpfs_remove() isn't modifying the file's data, so it shouldn't set TMPFS_NODE_MODIFIED on the node. PR: 152488 Submitted by: Anton Yuzhaninov Reviewed by: kib MFC after: 1 week Modified: head/sys/fs/tmpfs/tmpfs_vnops.c Modified: head/sys/fs/tmpfs/tmpfs_vnops.c ============================================================================== --- head/sys/fs/tmpfs/tmpfs_vnops.c Sat Feb 19 17:44:13 2011 (r218862) +++ head/sys/fs/tmpfs/tmpfs_vnops.c Sat Feb 19 21:04:36 2011 (r218863) @@ -853,8 +853,7 @@ tmpfs_remove(struct vop_remove_args *v) tmpfs_free_dirent(tmp, de, TRUE); if (node->tn_links > 0) - node->tn_status |= TMPFS_NODE_ACCESSED | TMPFS_NODE_CHANGED | \ - TMPFS_NODE_MODIFIED; + node->tn_status |= TMPFS_NODE_ACCESSED | TMPFS_NODE_CHANGED; error = 0; out: _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Feb 19 21:20:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 795171065672; Sat, 19 Feb 2011 21:20:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 07FF08FC12; Sat, 19 Feb 2011 21:20:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAAvDX02DaFvO/2dsb2JhbACEIKMMqVePc4Eng0F2BIUNhwY X-IronPort-AV: E=Sophos;i="4.62,192,1297054800"; d="scan'208";a="110434568" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 19 Feb 2011 16:20:24 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4BE9FB3F2F; Sat, 19 Feb 2011 16:20:24 -0500 (EST) Date: Sat, 19 Feb 2011 16:20:24 -0500 (EST) From: Rick Macklem To: Lawrence Stewart Message-ID: <1194340518.139022.1298150424303.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4D5F0825.9010607@freebsd.org> 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 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: Mounting NFSv4 as root fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 21:20:25 -0000 > On 02/19/11 08:38, Rick Macklem wrote: > >> Hi Rick, > >> > >> I've set up a NFS server to pxeboot a set of testbed clients from. > >> The > >> server filesystem tree the client needs to use as its root has > >> nullfs > >> mounted directories in it. Therefore, NFSv4 is the only useful way > >> to > >> mount it on the client because of the cross mount point traversing > >> capabilities built into v4. I've verified that I can "mount_nfs -o > >> nfsv4 > >> ..." on the command line and see all the files in the tree so I > >> have > >> things working fine on the server side. > >> > >> I was aware our pxeboot only supports NFSv3, but hoped that by > >> specifying "newfs" and "nfsv4" in the fstype and options fields > >> respectively in fstab that things might just work when the mount > >> root > >> step after the kernel boot happens. It doesn't as I found out, > >> because > >> of two issues: > >> > >> 1. I believe there is a bug in the newnfs code. nfs_diskless.c > >> wasn't > >> copied from the old nfsclient and suitably modified for use with > >> newnfs. > >> As a result during boot, the ncl_mountroot() function in > >> nfs_clvfsops.c > >> calls nfs_setup_diskless() which calls into the old nfs code and > >> badness > >> happens from there on in. I have a patch which fixes this issue, > >> though > >> it may be completely the wrong way to do things as I'm very new (as > >> in > >> 24 hours new) to the NFS code. > >> > > Yep. I didn't see an easy way to set up the diskless root so that it > > would > > work for both clients concurrently, so I was planning on switching > > it if/when > > "newnfs" becomes the default client. (You can switch fairly easily. > > Just > > crib the code across, as it sounds like you have and then make sure > > the > > xxx_mountroot() in "newnfs" gets called instead of nfs_mountroot() > > in the > > other one. > > Yes that's exactly what I did. > > > However, that will just get a "newnfs" NFSv3 root mount to work. > > Yup, confirmed working as expected (mount output shows "newnfs" for / > whereas before it would fall back to "nfs" after the newnfs code > crapped > out. > > >> 2. pxeboot stores the filehandle and filehandle length it used to > >> grab > >> the kernel via NFS in the kernel's env and after the kernel has > >> booted, > >> it looks for these variables and reuses them i.e. at no point in > >> the > >> process does the code attempt to upgrade to NFSv4 if the bootstrap > >> uses > >> NFSv3 to grab the kernel. > >> > >> For my particular use case, I'm quite happy for the kernel to be > >> pulled > >> via NFSv3, but can't boot the client without somehow getting the > >> client > >> to switch to NFSv4 at the point where it mount's root after the > >> kernel > >> has finished booting. > >> > >> I tried a very hacky test in mountnfs() in nfs_clvfsops.c to see if > >> I > >> could set the NFSV4 flag, unset the V3 flag and tell the code to > >> forget > >> about the cached file handle set by the loader just to see if the > >> code > >> would try to renegotiate using v4... it crashed and burned. > >> > > The same file handle should work for NFSv4 (at least a FReeBSD > > server > > generates the same FH for a v3 vs v4 mount). > > Ah, interesting and good to know, thanks. So assuming the server is v4 > capable, you can just start issuing v4 RPCs to the handle established > by > pxeboot and things should keep working? > Should might be too strong a word, but at least for the FreeBSD server, yes. (I don't know about other servers. I just suspect that the FH's will be the same. The change from NFSv2 -> NFSv3 was caused by the NFSv3 making it a variable size. (Most servers fill the same FH in for NFSv2 and then just pad it to 32bytes.) > >> So, before I spend any more time on this, I hope to get your (or > >> anyone > >> else reading for that matter) thoughts on how best to proceed. Some > >> questions: > >> > >> - Could you guesstimate how much work is involved to get v4 support > >> into > >> libstand so that pxeboot can talk v4 natively? I spent quite some > >> time > >> poking at libstand's code last night but don't understand the NFSv4 > >> RPC > >> mechanism enough to attempt writing the basic code to do it yet. > >> The > >> RFC > >> explains the ordering of OPs needed quit well but I don't quite > >> grok > >> how > >> the data structures for interpreting responses work. > >> > > Lots. It will be easier to get the kernel to use v4 after pxeboot > > has > > loaded it via v3. > > ACK. > > >> - Can you think of a hacky simple way to force my client to > >> renegotiate > >> the mount as v4 at the time mount root happens? > >> > > If you are will to spend man weeks on this, you can probably get > > something to work for your lab (useless for others, because you'll > > have to hard wire a bunch of stuff into the kernel like your DNS > > domain name...). > > > > I have never intended to try and make an NFSv4 root mount work. > > (Someone said NFSv4 is NFS in name only:-) > > > > One of the most difficult parts will be the uid/gid<->name mapping. > > You would have to hack this enough so that it worked without > > nfsuserd. > > Something like hard wiring mappings into the kernel cache for enough > > entries that the root works. (Note that names look like > > root@cis.uoguelph.ca, > > so it needs to know the DNS domain as well as "root" == uid 0.) > > Then hopefully you don't need other mappings to work, because it > > would > > have to work without nfsuserd running and with nfsuserd running (in > > the > > root fs). > > > > Short answer. A severely hacked kernel might work for your lab, but > > a > > generic solution for FreeBSD would be very difficult. > > Thanks heaps for the brain dump, it really helps put things in > perspective. It's sounding like a much bigger job than I thought it > would be, even for a hacked up lab-only solution. > > > If you could move the "nullfs" mounts down a level, so the NFSv4 > > mount > > was below an NFSv3 root fs, that would be much easier. > > Agreed. The issue is we're using the ezjail management script from > ports > to manage the bootable client filesystems on the server, and it uses > nullfs mounts between a base filesystem and the client filesystems to > avoid duplicating all the utilities/libs in /bin, /sbin, /lib and > /libexec multiple times. Works well but not for this use case... oh > well. > > I guess it will be significantly easier to hack ezjail to just copy > the > dirs from the basejail into each client rather than try get the all > singing all dancing NFSv4 option going. > > Thanks again for your insights. > > Cheers, > Lawrence