From owner-freebsd-fs@FreeBSD.ORG Sun Nov 13 20:30:00 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 86DFA106566C; Sun, 13 Nov 2011 20:30:00 +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 5BBB88FC16; Sun, 13 Nov 2011 20:30:00 +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 pADKU0Vl022011; Sun, 13 Nov 2011 20:30:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pADKU04p021997; Sun, 13 Nov 2011 20:30:00 GMT (envelope-from linimon) Date: Sun, 13 Nov 2011 20:30:00 GMT Message-Id: <201111132030.pADKU04p021997@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162519: [zfs] "zpool import" relies on buggy realpath() behaviour 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 Nov 2011 20:30:00 -0000 Synopsis: [zfs] "zpool import" relies on buggy realpath() behaviour Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 13 20:28:39 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162519 From owner-freebsd-fs@FreeBSD.ORG Mon Nov 14 07:12:54 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 9CCBA1065678 for ; Mon, 14 Nov 2011 07:12:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3758FC21 for ; Mon, 14 Nov 2011 07:12:54 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pAE6u81e061357 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 13 Nov 2011 22:56:10 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EC0BB84.5080803@freebsd.org> Date: Sun, 13 Nov 2011 22:56:04 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ZFS for dummys.... suggestions? 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 Nov 2011 07:12:54 -0000 The time has come for me to look at ZFS.. Is there a reference that is recommended for a quick overview, that doesn't get bogged down in the minute details, but gives a good overview? Preferably using short words, lots of pictures, and written in large crayon.. :-) Julian From owner-freebsd-fs@FreeBSD.ORG Mon Nov 14 07:25:55 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 4A2911065676 for ; Mon, 14 Nov 2011 07:25:55 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1BA8FC17 for ; Mon, 14 Nov 2011 07:25:51 +0000 (UTC) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id pAE76snP021508; Mon, 14 Nov 2011 15:06:55 +0800 (CST) From: Kevin Lo To: Buganini In-Reply-To: References: <1289442296.2128.16.camel@monet> <20101111122455.GA2098@tops> Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Nov 2011 15:06:54 +0800 Message-ID: <1321254414.1951.12.camel@esl.kevlo.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, delphij@FreeBSD.org Subject: Re: patch: let msdosfs(vfat)/ntfs to support UTF-8 locale well 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 Nov 2011 07:25:55 -0000 On Thu, 2011-03-31 at 18:56 +0800, Buganini wrote: > http://security-hole.info/~buganini/patches/kiconv_msdosfs/ > > I've adapted the 4th patchset for CURRENT, > but I've only test it with -ro on amd64. > another i386 machine is on the way. Sorry for the slow response. I've tested your patch and it seems to work fine for me on i386 and amd64. I'd commit your patch if there is no objection, thanks. > Regards, > Buganini Kevin From owner-freebsd-fs@FreeBSD.ORG Mon Nov 14 08:37: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 8B801106564A; Mon, 14 Nov 2011 08:37:37 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 364388FC0C; Mon, 14 Nov 2011 08:37:36 +0000 (UTC) Received: by ywe9 with SMTP id 9so3165269ywe.13 for ; Mon, 14 Nov 2011 00:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gn3xVb44hAp8cabHgc7vMw7I3OR/TelG08/8mM2g7IY=; b=nJI7HrwNUV0lba3jpKMRof1yu916doo25UMKb3aKZaZzh8WmaqFTd7n9qbQnJfk+nE 2edPmvWXgmwFxQVEdF8bV1qfHrZ1ilUnDqYWuI4tTV4Bg7Qzs7Rb1le2+4ht+cbfRMn9 nmz4OavtI0wOfH0Z1cmbFvXgEZEltQixp3gjE= MIME-Version: 1.0 Received: by 10.50.41.196 with SMTP id h4mr22736689igl.42.1321258064605; Mon, 14 Nov 2011 00:07:44 -0800 (PST) Received: by 10.231.34.3 with HTTP; Mon, 14 Nov 2011 00:07:44 -0800 (PST) In-Reply-To: References: <1289442296.2128.16.camel@monet> <20101111122455.GA2098@tops> Date: Mon, 14 Nov 2011 16:07:44 +0800 Message-ID: From: Buganini To: Antony Mawer Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, Kevin Lo , delphij@freebsd.org Subject: Re: patch: let msdosfs(vfat)/ntfs to support UTF-8 locale well 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 Nov 2011 08:37:37 -0000 The patches with new fixes is at http://elizabeth.twbbs.org/~buganini/kiconv_patches/ . Buganini From owner-freebsd-fs@FreeBSD.ORG Mon Nov 14 11:07: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 88B691065675 for ; Mon, 14 Nov 2011 11:07:06 +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 6E1918FC1F for ; Mon, 14 Nov 2011 11:07:06 +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 pAEB76Oc083498 for ; Mon, 14 Nov 2011 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAEB75Wp083496 for freebsd-fs@FreeBSD.org; Mon, 14 Nov 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Nov 2011 11:07:05 GMT Message-Id: <201111141107.pAEB75Wp083496@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 Nov 2011 11:07:06 -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/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161674 fs [ufs] snapshot on journaled ufs doesn't work o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161511 fs [unionfs] Filesystem deadlocks when using multiple uni o kern/161493 fs [nfs] NFS v3 directory structure update slow o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs Random UFS root filesystem corruption with SU+J [regre o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159971 fs [ffs] [panic] panic with soft updates journaling durin o kern/159930 fs [ufs] [panic] kernel core o kern/159418 fs [tmpfs] [panic] [patch] tmpfs kernel panic: recursing o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159233 fs [ext2fs] [patch] fs/ext2fs: finish reallocblk implemen o kern/159232 fs [ext2fs] [patch] fs/ext2fs: merge ext2_readwrite into o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs [amd] amd(8) ICMP storm and unkillable process. o kern/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157722 fs [geli] unable to newfs a geli encrypted partition o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/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/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 p kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode 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/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/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/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 s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/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/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/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/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/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs f kern/127375 fs [zfs] If vm.kmem_size_max>"1073741823" then write spee 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 f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW 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/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/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 o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o 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/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 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 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 262 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 14 17:37: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 93E77106566B for ; Mon, 14 Nov 2011 17:37:54 +0000 (UTC) (envelope-from monthadar@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 5927E8FC12 for ; Mon, 14 Nov 2011 17:37:54 +0000 (UTC) Received: by gyd5 with SMTP id 5so7189600gyd.13 for ; Mon, 14 Nov 2011 09:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Nlyioe69zcfuiJwtM04RUJ1RmhsRwcbfJB5aQVLuNF0=; b=tvJ9PbByt+g8zl0M7XsDi0Ktlfo4NEW/IhyKJUpaWHqYjl4saSpBtQMQXGlA+kBx/r a3aKELNpP0p0Rbw7CLRyTxpHyDFNDqWxklbPVMY48jKQRKyv5hNRyqfgRH11qcBQcOfP 2VM3JQ9XhN04CpYHYyArGJIln5L8wlbIaqlxg= MIME-Version: 1.0 Received: by 10.50.140.1 with SMTP id rc1mr25563913igb.25.1321290907498; Mon, 14 Nov 2011 09:15:07 -0800 (PST) Received: by 10.50.40.226 with HTTP; Mon, 14 Nov 2011 09:15:07 -0800 (PST) Date: Mon, 14 Nov 2011 18:15:07 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Boot kernel from ufs:md0 gives error 22 on AVILA arm board 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 Nov 2011 17:37:54 -0000 Hi, I am having problems booting from ufs:md0 and hope you can help me. I changed the default configuration file AVILA so that it boots from MD instead of NFS. options MD_ROOT #MD is a potential root device options MD_ROOT_SIZE=4096 options ROOTDEVNAME=\"ufs:md0\" I then generated a filesystem and embedded it inside kernel like this: makefs -t ffs -B little -s 4m avila.img path/to/root addr=($(strings -td kernel.bin | grep "MFS Filesystem" | awk '{print $1}')) #calculate start and end address for mdroot rootfs_start=${addr[0]} rootfs_end=$((${addr[1]}+1)) echo "Generating kernel image for AVILA from ${rootfs_start} to ${rootfs_end}" head -c ${rootfs_start} kernel.bin > kernel.new cat avila.img >> kernel.new tail -c +${rootfs_end} kernel.bin >> kernel.new then from redboot: load -b 0x00200000 kernel.new go and I get following error: Trying to mount root from ufs:/dev/md0 []... Mounting from ufs:/dev/md0 failed with error 22. Trying to mount root from ufs:md0 []... Mounting from ufs:md0 failed with error 22. Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ? List of GEOM managed disk devices: redboot/FIS directory redboot/RedBoot config redboot/RedBoot cfid0 md0 mountroot> The md0 partition is there. And this is how I do it for the RouterStation Pro and it works there. When I debug the kernel code I see that the EINVAL is generated from /* * Common code for mount and mountroot */ static int ffs_mountfs(devvp, mp, td) struct vnode *devvp; struct mount *mp; struct thread *td; { ... /* * Try reading the superblock in each of its possible locations. */ for (i = 0; sblock_try[i] != -1; i++) { ... } if (sblock_try[i] == -1) { error = EINVAL; /* XXX needs translation */ goto out; } ... } What am I doing wrong? any help is very appreciated. Best regards -- Monthadar Al Jaberi From owner-freebsd-fs@FreeBSD.ORG Mon Nov 14 18:15: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 D253F1065670 for ; Mon, 14 Nov 2011 18:15:28 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 93C578FC08 for ; Mon, 14 Nov 2011 18:15:28 +0000 (UTC) Received: by yenl11 with SMTP id l11so1822235yen.13 for ; Mon, 14 Nov 2011 10:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ADdvQQyqRsnL/n9BC9XHdVDRPV7UZUIjyUGyh5uKsjk=; b=KsVeInyC6gdKjbqkU5bwVmmWRzsFGM4B6nSxHSOkacsHK6lWvX0R8P2QxEUDLTjDUw AE/Pi2QQfDXxlmOMYhMB5XjpLiXXXAEw7O+ahk8XOZVf/93xQo67lbgEoR0ppR+q9MUS QYmzZUciGwUDH1Hzz18WCtvQHdaysvvMtBKXc= MIME-Version: 1.0 Received: by 10.50.185.232 with SMTP id ff8mr25168356igc.32.1321294527647; Mon, 14 Nov 2011 10:15:27 -0800 (PST) Received: by 10.50.40.226 with HTTP; Mon, 14 Nov 2011 10:15:27 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Nov 2011 19:15:27 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Boot kernel from ufs:md0 gives error 22 on AVILA arm board 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 Nov 2011 18:15:29 -0000 sorry I mixed little endiean with big endiean. br, On Mon, Nov 14, 2011 at 6:15 PM, Monthadar Al Jaberi wrote: > Hi, > > I am having problems booting from ufs:md0 and hope you can help me. > > I changed the default configuration file AVILA so that it boots from > MD instead of NFS. > options =A0 =A0 =A0 =A0 MD_ROOT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #MD is a = potential root device > options =A0 =A0 =A0 =A0 MD_ROOT_SIZE=3D4096 > options =A0 =A0 =A0 =A0 ROOTDEVNAME=3D\"ufs:md0\" > > I then generated a filesystem and embedded it inside kernel like this: > makefs -t ffs -B little -s 4m avila.img path/to/root > > addr=3D($(strings -td kernel.bin | grep "MFS Filesystem" | awk '{print > $1}')) #calculate start and end address for mdroot > rootfs_start=3D${addr[0]} > rootfs_end=3D$((${addr[1]}+1)) > echo "Generating kernel image for AVILA from ${rootfs_start} to ${rootfs_= end}" > head -c ${rootfs_start} kernel.bin > kernel.new > cat avila.img >> kernel.new > tail -c +${rootfs_end} kernel.bin >> kernel.new > > then from redboot: > load -b 0x00200000 kernel.new > go > > and I get following error: > Trying to mount root from ufs:/dev/md0 []... > Mounting from ufs:/dev/md0 failed with error 22. > Trying to mount root from ufs:md0 []... > Mounting from ufs:md0 failed with error 22. > > Loader variables: > > Manual root filesystem specification: > =A0: [options] > =A0 =A0 =A0Mount using filesystem > =A0 =A0 =A0and with the specified (optional) option list. > > =A0 =A0eg. ufs:/dev/da0s1a > =A0 =A0 =A0 =A0zfs:tank > =A0 =A0 =A0 =A0cd9660:/dev/acd0 ro > =A0 =A0 =A0 =A0 =A0(which is equivalent to: mount -t cd9660 -o ro /dev/ac= d0 /) > > =A0? =A0 =A0 =A0 =A0 =A0 =A0 =A0 List valid disk boot devices > =A0. =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yield 1 second (for background tasks) > =A0 =A0 =A0Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > redboot/FIS directory redboot/RedBoot config redboot/RedBoot cfid0 md0 > > mountroot> > > The md0 partition is there. And this is how I do it for the > RouterStation Pro and it works there. > > When I debug the kernel code I see that the EINVAL is generated from > /* > =A0* Common code for mount and mountroot > =A0*/ > static int > ffs_mountfs(devvp, mp, td) > =A0 =A0 =A0 =A0struct vnode *devvp; > =A0 =A0 =A0 =A0struct mount *mp; > =A0 =A0 =A0 =A0struct thread *td; > { > ... > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Try reading the superblock in each of its possible loca= tions. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0for (i =3D 0; sblock_try[i] !=3D -1; i++) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0if (sblock_try[i] =3D=3D -1) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error =3D EINVAL; =A0 =A0 =A0 =A0 /* XXX n= eeds translation */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > =A0 =A0 =A0 =A0} > ... > } > > What am I doing wrong? any help is very appreciated. > Best regards > -- > Monthadar Al Jaberi > --=20 Monthadar Al Jaberi From owner-freebsd-fs@FreeBSD.ORG Mon Nov 14 19:01: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 AB4CC106566C; Mon, 14 Nov 2011 19:01:41 +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 839348FC14; Mon, 14 Nov 2011 19:01:41 +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 pAEJ1f51026895; Mon, 14 Nov 2011 19:01:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAEJ1fp4026886; Mon, 14 Nov 2011 19:01:41 GMT (envelope-from linimon) Date: Mon, 14 Nov 2011 19:01:41 GMT Message-Id: <201111141901.pAEJ1fp4026886@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162564: [ext2fs][patch] fs/ext2fs: Add include guard 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 Nov 2011 19:01:41 -0000 Synopsis: [ext2fs][patch] fs/ext2fs: Add include guard Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 14 19:01:30 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162564 From owner-freebsd-fs@FreeBSD.ORG Tue Nov 15 01:40:06 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 3CB0B106566B for ; Tue, 15 Nov 2011 01:40:06 +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 142AA8FC15 for ; Tue, 15 Nov 2011 01:40:06 +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 pAF1e5DB091491 for ; Tue, 15 Nov 2011 01:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAF1e5K6091490; Tue, 15 Nov 2011 01:40:05 GMT (envelope-from gnats) Date: Tue, 15 Nov 2011 01:40:05 GMT Message-Id: <201111150140.pAF1e5K6091490@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159351: 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: Tue, 15 Nov 2011 01:40:06 -0000 The following reply was made to PR kern/159351; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159351: commit references a PR Date: Tue, 15 Nov 2011 01:39:16 +0000 (UTC) Author: rmacklem Date: Tue Nov 15 01:39:02 2011 New Revision: 227517 URL: http://svn.freebsd.org/changeset/base/227517 Log: Move the setting of the default value for nm_wcommitsize to before the nfs_decode_args() call in the new NFS client, so that a specfied command line value won't be overwritten. Also, modify the calculation for small values of desiredvnodes to avoid an unusually large value or a divide by zero crash. It seems that the default value for nm_wcommitsize is very conservative and may need to change at some time. PR: kern/159351 Submitted by: onwahe at gmail.com (earlier version) Reviewed by: jhb MFC after: 2 weeks Modified: head/sys/fs/nfsclient/nfs_clvfsops.c Modified: head/sys/fs/nfsclient/nfs_clvfsops.c ============================================================================== --- head/sys/fs/nfsclient/nfs_clvfsops.c Mon Nov 14 23:01:08 2011 (r227516) +++ head/sys/fs/nfsclient/nfs_clvfsops.c Tue Nov 15 01:39:02 2011 (r227517) @@ -1231,6 +1231,10 @@ mountnfs(struct nfs_args *argp, struct m nmp->nm_timeo = NFS_TIMEO; nmp->nm_retry = NFS_RETRANS; nmp->nm_readahead = NFS_DEFRAHEAD; + if (desiredvnodes >= 11000) + nmp->nm_wcommitsize = hibufspace / (desiredvnodes / 1000); + else + nmp->nm_wcommitsize = hibufspace / 10; nfs_decode_args(mp, nmp, argp, hst, cred, td); @@ -1252,7 +1256,6 @@ mountnfs(struct nfs_args *argp, struct m nmp->nm_rsize = NFS_RSIZE; nmp->nm_readdirsize = NFS_READDIRSIZE; } - nmp->nm_wcommitsize = hibufspace / (desiredvnodes / 1000); nmp->nm_numgrps = NFS_MAXGRPS; nmp->nm_tprintf_delay = nfs_tprintf_delay; if (nmp->nm_tprintf_delay < 0) _______________________________________________ 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 Tue Nov 15 19:14:56 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 D0AB6106564A for ; Tue, 15 Nov 2011 19:14:56 +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 8E91F8FC14 for ; Tue, 15 Nov 2011 19:14:56 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RQOT8-00075L-4S for freebsd-fs@freebsd.org; Tue, 15 Nov 2011 20:14:54 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2011 20:14:54 +0100 Received: from jtotz by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2011 20:14:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Tue, 15 Nov 2011 19:14:42 +0000 Lines: 29 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 Subject: zfs: panic on import 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 Nov 2011 19:14:56 -0000 Hi, I get a lovely panic everytime i try to import my pool. panic: page fault ... #5 ... calltrap #6 ... zio_vdev_io_start #7 ... zio_execute #8 ... zio_ioctl #9 ... zio_flush #10 ... vdev_config_sync #11 ... spa_sync #12 ... txg_sync_thread #13 ... fork_exit #14 ... fork_trampoline This is for a funky config in which one half of a zfs-mirror sits on a local gpt partition and the other half on a local file on a ufs volume (dont ask why). The machine is running a 8.2-stable, compiled on 5th Sept 2011. Maybe r226617 fixed this? Any idea how to get it back alive? Johannes From owner-freebsd-fs@FreeBSD.ORG Tue Nov 15 19:24: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 6DC20106566C for ; Tue, 15 Nov 2011 19:24:35 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 291958FC16 for ; Tue, 15 Nov 2011 19:24:34 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so9640613vcb.13 for ; Tue, 15 Nov 2011 11:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AT8An0vX4td+N2cUB8S/6Aw1Sv0zcikVjdyUFZee4tM=; b=td5rH6t/6yLY4pwaFriOXEpEZoVLDubsuSHM8/XPLqO9mRqetsnNMWdN4FSviu8e9I iXDgZpTQGkllORRB0I0cDPtl43Y/vRHnosW8/hSJyQlu3bi5mJl6cFrg9vY5kuoBP9S/ f0PuZn88V0RHgSc32DMFMGXANYxfY0WfsY0Mw= MIME-Version: 1.0 Received: by 10.220.108.136 with SMTP id f8mr3174064vcp.30.1321385074395; Tue, 15 Nov 2011 11:24:34 -0800 (PST) Received: by 10.220.190.71 with HTTP; Tue, 15 Nov 2011 11:24:34 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 11:24:34 -0800 Message-ID: From: Freddie Cash To: Johannes Totz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: zfs: panic on import 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 Nov 2011 19:24:35 -0000 On Tue, Nov 15, 2011 at 11:14 AM, Johannes Totz wrote: > I get a lovely panic everytime i try to import my pool. > > panic: page fault > ... > #5 ... calltrap > #6 ... zio_vdev_io_start > #7 ... zio_execute > #8 ... zio_ioctl > #9 ... zio_flush > #10 ... vdev_config_sync > #11 ... spa_sync > #12 ... txg_sync_thread > #13 ... fork_exit > #14 ... fork_trampoline > > This is for a funky config in which one half of a zfs-mirror sits on a > local gpt partition and the other half on a local file on a ufs volume > (dont ask why). > > The machine is running a 8.2-stable, compiled on 5th Sept 2011. > > Maybe r226617 fixed this? > Any idea how to get it back alive? > Have you tried "import -F" or to import it readonly? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue Nov 15 19: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 C826A1065670 for ; Tue, 15 Nov 2011 19:31:41 +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 8261A8FC0A for ; Tue, 15 Nov 2011 19:31:41 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RQOjK-0007Zo-7E for freebsd-fs@freebsd.org; Tue, 15 Nov 2011 20:31:38 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2011 20:31:38 +0100 Received: from jtotz by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2011 20:31:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Tue, 15 Nov 2011 19:31:25 +0000 Lines: 34 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: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: zfs: panic on import 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 Nov 2011 19:31:41 -0000 On 15/11/2011 19:24, Freddie Cash wrote: > On Tue, Nov 15, 2011 at 11:14 AM, Johannes Totzwrote: > >> I get a lovely panic everytime i try to import my pool. >> >> panic: page fault >> ... >> #5 ... calltrap >> #6 ... zio_vdev_io_start >> #7 ... zio_execute >> #8 ... zio_ioctl >> #9 ... zio_flush >> #10 ... vdev_config_sync >> #11 ... spa_sync >> #12 ... txg_sync_thread >> #13 ... fork_exit >> #14 ... fork_trampoline >> >> This is for a funky config in which one half of a zfs-mirror sits on a >> local gpt partition and the other half on a local file on a ufs volume >> (dont ask why). >> >> The machine is running a 8.2-stable, compiled on 5th Sept 2011. >> >> Maybe r226617 fixed this? >> Any idea how to get it back alive? >> > > Have you tried "import -F" or to import it readonly? Same panic. Also, I can delete/rename the second-half-on-ufs of the mirror but that gets me the same panic; instead of just a degraded pool. From owner-freebsd-fs@FreeBSD.ORG Wed Nov 16 10:25:31 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 D3BE4106566C for ; Wed, 16 Nov 2011 10:25:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DE8B18FC0A for ; Wed, 16 Nov 2011 10:25:30 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAG9rmfc056436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2011 11:53:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAG9rmdb007215 for ; Wed, 16 Nov 2011 11:53:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAG9rmjK007214 for fs@freebsd.org; Wed, 16 Nov 2011 11:53:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Nov 2011 11:53:48 +0200 From: Kostik Belousov To: fs@freebsd.org Message-ID: <20111116095348.GD50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YcxAF3djuctrf0Jt" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: VOP_VPTOCNP() interface change 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 Nov 2011 10:25:31 -0000 --YcxAF3djuctrf0Jt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Apparently, the VOP_VPTOCNP() interface has a fatal flaw that only matter for nullfs vnodes. The problem is that resulting vnode is only required to be held on return from the successfull call to vop, instead of being referenced. I designed the interface this way because dropping the reference might need to take the vnode lock, which is highly inconvenient in the main loop of vn_fullpath(), which holds the namecache rwlock for read. Nullfs VOP_INACTIVE() method reclaims the vnode, which in combination with the VOP_VPTOCNP() interface means that the directory vnode returned from VOP_VPTOCNP() is reclaimed in advance, causing vn_fullpath() to error with EBADF or like. It appeared that my worries about dropping the cache lock were unfounded. Below is the patch that changes the requirements for VOP_VPTOCNP(), now the dvp must be referenced. I converted all in-tree implementations of VOP_VPTOCNP(), it appeared to be trivial, which is expected, because vhold(9) and vref(9) are similar in the locking. So I do not expect much troubles for out-of-tree fs implementation of VOP_VPTOCNP, if any. Below is the patch, it was tested by Peter Holm. Among other issues, I believe that it should fix some JVM errors when JVM is run from the nullfs-mounted fs. Please comment, I will commit the patch in a week. diff --git a/share/man/man9/VOP_VPTOCNP.9 b/share/man/man9/VOP_VPTOCNP.9 index 6bcbd25..671c8df 100644 --- a/share/man/man9/VOP_VPTOCNP.9 +++ b/share/man/man9/VOP_VPTOCNP.9 @@ -65,9 +65,9 @@ is not a directory, then .Nm returns ENOENT. .Sh LOCKS -The vnode should be locked on entry and will still be locked on exit. The -parent directory vnode will be unlocked on a successful exit. However, it -will have its hold count incremented. +The vnode should be locked on entry and will still be locked on exit. +The parent directory vnode will be unlocked on a successful exit. +However, it will have its use count incremented. .Sh RETURN VALUES Zero is returned on success, otherwise an error code is returned. .Sh ERRORS diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c b/= sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c index a880961..65fc902 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c @@ -1594,7 +1594,7 @@ zfsctl_snapshot_vptocnp(struct vop_vptocnp_args *ap) *ap->a_buflen -=3D len; bcopy(sep->se_name, ap->a_buf + *ap->a_buflen, len); mutex_exit(&sdp->sd_lock); - vhold(dvp); + vref(dvp); *ap->a_vpp =3D dvp; } VN_RELE(dvp); diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops.c index eb154b1..22908b9 100644 --- a/sys/fs/devfs/devfs_vnops.c +++ b/sys/fs/devfs/devfs_vnops.c @@ -261,7 +261,7 @@ devfs_vptocnp(struct vop_vptocnp_args *ap) } else if (vp->v_type =3D=3D VDIR) { if (dd =3D=3D dmp->dm_rootdir) { *dvp =3D vp; - vhold(*dvp); + vref(*dvp); goto finished; } i -=3D dd->de_dirent->d_namlen; @@ -289,6 +289,8 @@ devfs_vptocnp(struct vop_vptocnp_args *ap) mtx_unlock(&devfs_de_interlock); vholdl(*dvp); VI_UNLOCK(*dvp); + vref(*dvp); + vdrop(*dvp); } else { mtx_unlock(&devfs_de_interlock); error =3D ENOENT; diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c index 5717a01..a45ccf7 100644 --- a/sys/fs/nullfs/null_subr.c +++ b/sys/fs/nullfs/null_subr.c @@ -289,22 +289,12 @@ null_checkvp(vp, fil, lno) #endif if (a->null_lowervp =3D=3D NULLVP) { /* Should never happen */ - int i; u_long *p; - printf("vp =3D %p, ZERO ptr\n", (void *)vp); - for (p =3D (u_long *) a, i =3D 0; i < 8; i++) - printf(" %lx", p[i]); - printf("\n"); - panic("null_checkvp"); + panic("null_checkvp %p", vp); } VI_LOCK_FLAGS(a->null_lowervp, MTX_DUPOK); - if (a->null_lowervp->v_usecount < 1) { - int i; u_long *p; - printf("vp =3D %p, unref'ed lowervp\n", (void *)vp); - for (p =3D (u_long *) a, i =3D 0; i < 8; i++) - printf(" %lx", p[i]); - printf("\n"); - panic ("null with unref'ed lowervp"); - } + if (a->null_lowervp->v_usecount < 1) + panic ("null with unref'ed lowervp, vp %p lvp %p", + vp, a->null_lowervp); VI_UNLOCK(a->null_lowervp); #ifdef notyet printf("null %x/%d -> %x/%d [%s, %d]\n", diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index 30a38da..bcf8750 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -729,7 +729,7 @@ null_print(struct vop_print_args *ap) { struct vnode *vp =3D ap->a_vp; =20 - printf("\tvp=3D%p, lowervp=3D%p\n", vp, NULLVPTOLOWERVP(vp)); + printf("\tvp=3D%p, lowervp=3D%p\n", vp, VTONULL(vp)->null_lowervp); return (0); } =20 @@ -784,6 +784,7 @@ null_vptocnp(struct vop_vptocnp_args *ap) vhold(lvp); VOP_UNLOCK(vp, 0); /* vp is held by vn_vptocnp_locked that called us */ ldvp =3D lvp; + vref(lvp); error =3D vn_vptocnp(&ldvp, cred, ap->a_buf, ap->a_buflen); vdrop(lvp); if (error !=3D 0) { @@ -797,19 +798,17 @@ null_vptocnp(struct vop_vptocnp_args *ap) */ error =3D vn_lock(ldvp, LK_EXCLUSIVE); if (error !=3D 0) { + vrele(ldvp); vn_lock(vp, locked | LK_RETRY); - vdrop(ldvp); return (ENOENT); } vref(ldvp); - vdrop(ldvp); error =3D null_nodeget(vp->v_mount, ldvp, dvp); if (error =3D=3D 0) { #ifdef DIAGNOSTIC NULLVPTOLOWERVP(*dvp); #endif - vhold(*dvp); - vput(*dvp); + VOP_UNLOCK(*dvp, 0); /* keep reference on *dvp */ } else vput(ldvp); =20 diff --git a/sys/fs/pseudofs/pseudofs_vnops.c b/sys/fs/pseudofs/pseudofs_vn= ops.c index 27b2605..a89174c 100644 --- a/sys/fs/pseudofs/pseudofs_vnops.c +++ b/sys/fs/pseudofs/pseudofs_vnops.c @@ -410,8 +410,7 @@ pfs_vptocnp(struct vop_vptocnp_args *ap) } =20 *buflen =3D i; - vhold(*dvp); - vput(*dvp); + VOP_UNLOCK(*dvp, 0); vn_lock(vp, locked | LK_RETRY); vfs_unbusy(mp); =20 diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c index 11efcab..177fd56 100644 --- a/sys/kern/vfs_cache.c +++ b/sys/kern/vfs_cache.c @@ -1068,16 +1068,8 @@ vn_vptocnp(struct vnode **vp, struct ucred *cred, ch= ar *buf, u_int *buflen) =20 CACHE_RLOCK(); error =3D vn_vptocnp_locked(vp, cred, buf, buflen); - if (error =3D=3D 0) { - /* - * vn_vptocnp_locked() dropped hold acquired by - * VOP_VPTOCNP immediately after locking the - * cache. Since we are going to drop the cache rlock, - * re-hold the result. - */ - vhold(*vp); + if (error =3D=3D 0) CACHE_RUNLOCK(); - } return (error); } =20 @@ -1096,6 +1088,9 @@ vn_vptocnp_locked(struct vnode **vp, struct ucred *cr= ed, char *buf, if (ncp !=3D NULL) { if (*buflen < ncp->nc_nlen) { CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT((*vp)->v_mount); + vrele(*vp); + VFS_UNLOCK_GIANT(vfslocked); numfullpathfail4++; error =3D ENOMEM; SDT_PROBE(vfs, namecache, fullpath, return, error, @@ -1106,18 +1101,23 @@ vn_vptocnp_locked(struct vnode **vp, struct ucred *= cred, char *buf, memcpy(buf + *buflen, ncp->nc_name, ncp->nc_nlen); SDT_PROBE(vfs, namecache, fullpath, hit, ncp->nc_dvp, ncp->nc_name, vp, 0, 0); + dvp =3D *vp; *vp =3D ncp->nc_dvp; + vref(*vp); + CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(dvp->v_mount); + vrele(dvp); + VFS_UNLOCK_GIANT(vfslocked); + CACHE_RLOCK(); return (0); } SDT_PROBE(vfs, namecache, fullpath, miss, vp, 0, 0, 0, 0); =20 - vhold(*vp); CACHE_RUNLOCK(); vfslocked =3D VFS_LOCK_GIANT((*vp)->v_mount); vn_lock(*vp, LK_SHARED | LK_RETRY); error =3D VOP_VPTOCNP(*vp, &dvp, cred, buf, buflen); - VOP_UNLOCK(*vp, 0); - vdrop(*vp); + vput(*vp); VFS_UNLOCK_GIANT(vfslocked); if (error) { numfullpathfail2++; @@ -1128,16 +1128,20 @@ vn_vptocnp_locked(struct vnode **vp, struct ucred *= cred, char *buf, =20 *vp =3D dvp; CACHE_RLOCK(); - if ((*vp)->v_iflag & VI_DOOMED) { + if (dvp->v_iflag & VI_DOOMED) { /* forced unmount */ CACHE_RUNLOCK(); - vdrop(*vp); + vfslocked =3D VFS_LOCK_GIANT(dvp->v_mount); + vrele(dvp); + VFS_UNLOCK_GIANT(vfslocked); error =3D ENOENT; SDT_PROBE(vfs, namecache, fullpath, return, error, vp, NULL, 0, 0); return (error); } - vdrop(*vp); + /* + * *vp has its use count incremented still. + */ =20 return (0); } @@ -1149,10 +1153,11 @@ static int vn_fullpath1(struct thread *td, struct vnode *vp, struct vnode *rdir, char *buf, char **retbuf, u_int buflen) { - int error, slash_prefixed; + int error, slash_prefixed, vfslocked; #ifdef KDTRACE_HOOKS struct vnode *startvp =3D vp; #endif + struct vnode *vp1; =20 buflen--; buf[buflen] =3D '\0'; @@ -1161,6 +1166,7 @@ vn_fullpath1(struct thread *td, struct vnode *vp, str= uct vnode *rdir, =20 SDT_PROBE(vfs, namecache, fullpath, entry, vp, 0, 0, 0, 0); numfullpathcalls++; + vref(vp); CACHE_RLOCK(); if (vp->v_type !=3D VDIR) { error =3D vn_vptocnp_locked(&vp, td->td_ucred, buf, &buflen); @@ -1168,6 +1174,9 @@ vn_fullpath1(struct thread *td, struct vnode *vp, str= uct vnode *rdir, return (error); if (buflen =3D=3D 0) { CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + vrele(vp); + VFS_UNLOCK_GIANT(vfslocked); return (ENOMEM); } buf[--buflen] =3D '/'; @@ -1177,16 +1186,29 @@ vn_fullpath1(struct thread *td, struct vnode *vp, s= truct vnode *rdir, if (vp->v_vflag & VV_ROOT) { if (vp->v_iflag & VI_DOOMED) { /* forced unmount */ CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + vrele(vp); + VFS_UNLOCK_GIANT(vfslocked); error =3D ENOENT; SDT_PROBE(vfs, namecache, fullpath, return, error, vp, NULL, 0, 0); break; } - vp =3D vp->v_mount->mnt_vnodecovered; + vp1 =3D vp->v_mount->mnt_vnodecovered; + vref(vp1); + CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + vrele(vp); + VFS_UNLOCK_GIANT(vfslocked); + vp =3D vp1; + CACHE_RLOCK(); continue; } if (vp->v_type !=3D VDIR) { CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + vrele(vp); + VFS_UNLOCK_GIANT(vfslocked); numfullpathfail1++; error =3D ENOTDIR; SDT_PROBE(vfs, namecache, fullpath, return, @@ -1198,6 +1220,9 @@ vn_fullpath1(struct thread *td, struct vnode *vp, str= uct vnode *rdir, break; if (buflen =3D=3D 0) { CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + vrele(vp); + VFS_UNLOCK_GIANT(vfslocked); error =3D ENOMEM; SDT_PROBE(vfs, namecache, fullpath, return, error, startvp, NULL, 0, 0); @@ -1211,6 +1236,9 @@ vn_fullpath1(struct thread *td, struct vnode *vp, str= uct vnode *rdir, if (!slash_prefixed) { if (buflen =3D=3D 0) { CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + vrele(vp); + VFS_UNLOCK_GIANT(vfslocked); numfullpathfail4++; SDT_PROBE(vfs, namecache, fullpath, return, ENOMEM, startvp, NULL, 0, 0); @@ -1220,6 +1248,9 @@ vn_fullpath1(struct thread *td, struct vnode *vp, str= uct vnode *rdir, } numfullpathfound++; CACHE_RUNLOCK(); + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + vrele(vp); + VFS_UNLOCK_GIANT(vfslocked); =20 SDT_PROBE(vfs, namecache, fullpath, return, 0, startvp, buf + buflen, 0, 0); diff --git a/sys/kern/vfs_default.c b/sys/kern/vfs_default.c index e9f8151..e47498e 100644 --- a/sys/kern/vfs_default.c +++ b/sys/kern/vfs_default.c @@ -844,7 +844,7 @@ out: free(dirbuf, M_TEMP); if (!error) { *buflen =3D i; - vhold(*dvp); + vref(*dvp); } if (covered) { vput(*dvp); --YcxAF3djuctrf0Jt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7DiCsACgkQC3+MBN1Mb4hPPACgkKcAtEpvrR3P+/sAyofywP8l LFgAoNcgCy7+aROMTO76RWEBn6pbmADe =r5x7 -----END PGP SIGNATURE----- --YcxAF3djuctrf0Jt-- From owner-freebsd-fs@FreeBSD.ORG Wed Nov 16 17:47:50 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 647DA106566B for ; Wed, 16 Nov 2011 17:47:50 +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 1E93B8FC0A for ; Wed, 16 Nov 2011 17:47:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RQjaO-0005ee-JS for freebsd-fs@freebsd.org; Wed, 16 Nov 2011 18:47:48 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2011 18:47:48 +0100 Received: from jtotz by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2011 18:47:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Wed, 16 Nov 2011 17:47:32 +0000 Lines: 41 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: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: zfs: panic on import 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 Nov 2011 17:47:50 -0000 On 15/11/2011 19:31, Johannes Totz wrote: > On 15/11/2011 19:24, Freddie Cash wrote: >> On Tue, Nov 15, 2011 at 11:14 AM, Johannes >> Totzwrote: >> >>> I get a lovely panic everytime i try to import my pool. >>> >>> panic: page fault >>> ... >>> #5 ... calltrap >>> #6 ... zio_vdev_io_start >>> #7 ... zio_execute >>> #8 ... zio_ioctl >>> #9 ... zio_flush >>> #10 ... vdev_config_sync >>> #11 ... spa_sync >>> #12 ... txg_sync_thread >>> #13 ... fork_exit >>> #14 ... fork_trampoline >>> >>> This is for a funky config in which one half of a zfs-mirror sits on a >>> local gpt partition and the other half on a local file on a ufs volume >>> (dont ask why). >>> >>> The machine is running a 8.2-stable, compiled on 5th Sept 2011. >>> >>> Maybe r226617 fixed this? >>> Any idea how to get it back alive? >>> >> >> Have you tried "import -F" or to import it readonly? > > Same panic. > > Also, I can delete/rename the second-half-on-ufs of the mirror but that > gets me the same panic; instead of just a degraded pool. Ugh... and OpenIndiana does not read GPT... Does anybody have a very recent FreeBSD live cd/dvd image that I could try? From owner-freebsd-fs@FreeBSD.ORG Wed Nov 16 17:50:48 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 27CE4106566B for ; Wed, 16 Nov 2011 17:50:48 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D63EC8FC0A for ; Wed, 16 Nov 2011 17:50:47 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so1151826vcb.13 for ; Wed, 16 Nov 2011 09:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UaAUmp2CCjakyJpzkdBUydffOGb0lobZUTLZaXu4U60=; b=qwNtlyvZCEsv9i30qX7Gv/BI1QhcIm8J51BRuNxfpNtiozxd9SJLWPUzQ43QEaUZA1 n0gtdXhRqqdxcbjUjVoiC1IU9zbPkZJpIs7q7OE79Yq7bsDvVD3pD+DJBogrI4Hb/yv5 sUSDHlmsnmrqub2jfuhpK5LNExnNQ6InJ4EVg= MIME-Version: 1.0 Received: by 10.220.39.130 with SMTP id g2mr3676584vce.135.1321465846829; Wed, 16 Nov 2011 09:50:46 -0800 (PST) Received: by 10.220.190.71 with HTTP; Wed, 16 Nov 2011 09:50:46 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 09:50:46 -0800 Message-ID: From: Freddie Cash To: Johannes Totz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: zfs: panic on import 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 Nov 2011 17:50:48 -0000 On Wed, Nov 16, 2011 at 9:47 AM, Johannes Totz wrote: > Does anybody have a very recent FreeBSD live cd/dvd image that I could try? > The FreeBSD 9.0 install CD is a LiveCD. The first screen gives you the option of starting the installer or dropping to a shell. 9.0-RC2 CDs are available on ftp://ftp.freebsd.org and should be available on most mirrors by now. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed Nov 16 18:41: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 150161065678 for ; Wed, 16 Nov 2011 18:41:08 +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 C13B98FC24 for ; Wed, 16 Nov 2011 18:41:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RQkPv-0001Od-Us for freebsd-fs@freebsd.org; Wed, 16 Nov 2011 19:41:03 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2011 19:41:03 +0100 Received: from jtotz by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2011 19:41:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Wed, 16 Nov 2011 18:40:50 +0000 Lines: 31 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: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: zfs: panic on import 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 Nov 2011 18:41:08 -0000 On 16/11/2011 17:50, Freddie Cash wrote: > On Wed, Nov 16, 2011 at 9:47 AM, Johannes Totz wrote: > >> Does anybody have a very recent FreeBSD live cd/dvd image that I could try? >> > > The FreeBSD 9.0 install CD is a LiveCD. The first screen gives you the > option of starting the installer or dropping to a shell. > > 9.0-RC2 CDs are available on ftp://ftp.freebsd.org and should be available > on most mirrors by now. > Ah thanks for the pointer, I always get lost navigating the ftp sever... But, same panic unfortunately (transcribbled): current process: txg_thread_enter panic: page fault ... #5 ... calltrap #6 ... zio_vdev_io_start #7 ... zio_execute #8 ... zio_ioctl #9 ... zio_flush #10 ... vdev_config_sync #11 ... spa_sync #12 ... txg_sync_thread #13 ... fork_exit #14 ... fork_trampoline From owner-freebsd-fs@FreeBSD.ORG Wed Nov 16 23:53:47 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 02D0E106566C for ; Wed, 16 Nov 2011 23:53:47 +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 AEE2E8FC17 for ; Wed, 16 Nov 2011 23:53:46 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RQpIW-0005SM-TI for freebsd-fs@freebsd.org; Thu, 17 Nov 2011 00:53:44 +0100 Received: from 78-86-4-158.zone2.bethere.co.uk ([78.86.4.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2011 00:53:44 +0100 Received: from jtotz by 78-86-4-158.zone2.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2011 00:53:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Wed, 16 Nov 2011 23:53:29 +0000 Lines: 39 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: 78-86-4-158.zone2.bethere.co.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: zfs: panic on import 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 Nov 2011 23:53:47 -0000 On 16/11/2011 18:40, Johannes Totz wrote: > On 16/11/2011 17:50, Freddie Cash wrote: >> On Wed, Nov 16, 2011 at 9:47 AM, Johannes Totz >> wrote: >> >>> Does anybody have a very recent FreeBSD live cd/dvd image that I >>> could try? >>> >> >> The FreeBSD 9.0 install CD is a LiveCD. The first screen gives you the >> option of starting the installer or dropping to a shell. >> >> 9.0-RC2 CDs are available on ftp://ftp.freebsd.org and should be >> available >> on most mirrors by now. >> > > Ah thanks for the pointer, I always get lost navigating the ftp sever... > > But, same panic unfortunately (transcribbled): > > current process: txg_thread_enter > panic: page fault > ... > #5 ... calltrap > #6 ... zio_vdev_io_start > #7 ... zio_execute > #8 ... zio_ioctl > #9 ... zio_flush > #10 ... vdev_config_sync > #11 ... spa_sync > #12 ... txg_sync_thread > #13 ... fork_exit > #14 ... fork_trampoline This PR http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 seems related. I also offlined the file-vdev before the machine crashed. Now it panics on import. And I don't get any dump either... From owner-freebsd-fs@FreeBSD.ORG Thu Nov 17 00:20:08 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 7D346106564A for ; Thu, 17 Nov 2011 00:20:08 +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 6490F8FC12 for ; Thu, 17 Nov 2011 00:20:08 +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 pAH0K81q055686 for ; Thu, 17 Nov 2011 00:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAH0K8cW055684; Thu, 17 Nov 2011 00:20:08 GMT (envelope-from gnats) Date: Thu, 17 Nov 2011 00:20:08 GMT Message-Id: <201111170020.pAH0K8cW055684@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Johannes Totz" Cc: Subject: Re: kern/155587: [zfs] [panic] kernel panic with zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Johannes Totz List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 00:20:08 -0000 The following reply was made to PR kern/155587; it has been noted by GNATS. From: "Johannes Totz" To: , Cc: Subject: Re: kern/155587: [zfs] [panic] kernel panic with zfs Date: Wed, 16 Nov 2011 23:58:36 -0000 I have a very similar issue. I offlined a file-vdev and the machine panic'd. Now I get a panic every time I try to import the pool. Unfortunately, some bits of the panic info scroll off screen. This is transcribbled: current process: txg_thread_enter panic: page fault ... #5 ... calltrap #6 ... zio_vdev_io_start #7 ... zio_execute #8 ... zio_ioctl #9 ... zio_flush #10 ... vdev_config_sync #11 ... spa_sync #12 ... txg_sync_thread #13 ... fork_exit #14 ... fork_trampoline This happens with 9.0-RC2 live disc and 8.2-stable (compiled on 5th Sept 2011). From owner-freebsd-fs@FreeBSD.ORG Thu Nov 17 00:21:26 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 19067106566C for ; Thu, 17 Nov 2011 00:21:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0C68FC0A for ; Thu, 17 Nov 2011 00:21:24 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id CAA02530; Thu, 17 Nov 2011 02:21:22 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RQpjG-00091H-8G; Thu, 17 Nov 2011 02:21:22 +0200 Message-ID: <4EC45380.7080006@FreeBSD.org> Date: Thu, 17 Nov 2011 02:21:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Johannes Totz References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: zfs: panic on import 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 Nov 2011 00:21:26 -0000 on 17/11/2011 01:53 Johannes Totz said the following: > On 16/11/2011 18:40, Johannes Totz wrote: >> On 16/11/2011 17:50, Freddie Cash wrote: >>> On Wed, Nov 16, 2011 at 9:47 AM, Johannes Totz >>> wrote: >>> >>>> Does anybody have a very recent FreeBSD live cd/dvd image that I >>>> could try? >>>> >>> >>> The FreeBSD 9.0 install CD is a LiveCD. The first screen gives you the >>> option of starting the installer or dropping to a shell. >>> >>> 9.0-RC2 CDs are available on ftp://ftp.freebsd.org and should be >>> available >>> on most mirrors by now. >>> >> >> Ah thanks for the pointer, I always get lost navigating the ftp sever... >> >> But, same panic unfortunately (transcribbled): >> >> current process: txg_thread_enter >> panic: page fault >> ... >> #5 ... calltrap >> #6 ... zio_vdev_io_start >> #7 ... zio_execute >> #8 ... zio_ioctl >> #9 ... zio_flush >> #10 ... vdev_config_sync >> #11 ... spa_sync >> #12 ... txg_sync_thread >> #13 ... fork_exit >> #14 ... fork_trampoline > > This PR http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 seems related. I > also offlined the file-vdev before the machine crashed. Now it panics on import. > And I don't get any dump either... Perhaps the following commit might help you http://svnweb.freebsd.org/base?view=revision&revision=226617 -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Nov 17 13:30: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 5BE2A106564A for ; Thu, 17 Nov 2011 13:30:21 +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 DA26E8FC08 for ; Thu, 17 Nov 2011 13:30:20 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RR22k-0007xK-NR for freebsd-fs@freebsd.org; Thu, 17 Nov 2011 14:30:18 +0100 Received: from 78-86-4-158.zone2.bethere.co.uk ([78.86.4.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2011 14:30:18 +0100 Received: from jtotz by 78-86-4-158.zone2.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Nov 2011 14:30:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Thu, 17 Nov 2011 13:30:08 +0000 Lines: 49 Message-ID: References: <4EC45380.7080006@FreeBSD.org> 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: 78-86-4-158.zone2.bethere.co.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <4EC45380.7080006@FreeBSD.org> Subject: Re: zfs: panic on import 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 Nov 2011 13:30:21 -0000 On 17/11/2011 00:21, Andriy Gapon wrote: > on 17/11/2011 01:53 Johannes Totz said the following: >> On 16/11/2011 18:40, Johannes Totz wrote: >>> On 16/11/2011 17:50, Freddie Cash wrote: >>>> On Wed, Nov 16, 2011 at 9:47 AM, Johannes Totz >>>> wrote: >>>> >>>>> Does anybody have a very recent FreeBSD live cd/dvd image that I >>>>> could try? >>>>> >>>> >>>> The FreeBSD 9.0 install CD is a LiveCD. The first screen gives you the >>>> option of starting the installer or dropping to a shell. >>>> >>>> 9.0-RC2 CDs are available on ftp://ftp.freebsd.org and should be >>>> available >>>> on most mirrors by now. >>>> >>> >>> Ah thanks for the pointer, I always get lost navigating the ftp sever... >>> >>> But, same panic unfortunately (transcribbled): >>> >>> current process: txg_thread_enter >>> panic: page fault >>> ... >>> #5 ... calltrap >>> #6 ... zio_vdev_io_start >>> #7 ... zio_execute >>> #8 ... zio_ioctl >>> #9 ... zio_flush >>> #10 ... vdev_config_sync >>> #11 ... spa_sync >>> #12 ... txg_sync_thread >>> #13 ... fork_exit >>> #14 ... fork_trampoline >> >> This PR http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 seems related. I >> also offlined the file-vdev before the machine crashed. Now it panics on import. >> And I don't get any dump either... > > > Perhaps the following commit might help you > http://svnweb.freebsd.org/base?view=revision&revision=226617 Indeed, it looks like it could be relevant. But, unfortunately, I dont have any means to compile a current live-disc at the moment :( you wouldn't happen to have one handy? From owner-freebsd-fs@FreeBSD.ORG Fri Nov 18 03:05:58 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 B5D041065674; Fri, 18 Nov 2011 03:05:58 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 34A848FC21; Fri, 18 Nov 2011 03:05:57 +0000 (UTC) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id pAI35rvn015270; Fri, 18 Nov 2011 11:05:53 +0800 (CST) From: Kevin Lo To: Buganini In-Reply-To: References: <1289442296.2128.16.camel@monet> <20101111122455.GA2098@tops> Content-Type: text/plain; charset="UTF-8" Date: Fri, 18 Nov 2011 11:05:53 +0800 Message-ID: <1321585553.2044.1.camel@esl.kevlo.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, delphij@FreeBSD.org Subject: Re: patch: let msdosfs(vfat)/ntfs to support UTF-8 locale well 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 Nov 2011 03:05:58 -0000 Buganini wrote: > The patches with new fixes is at > http://elizabeth.twbbs.org/~buganini/kiconv_patches/ . Thanks. Committed to HEAD(r227650). > Buganini Kevin From owner-freebsd-fs@FreeBSD.ORG Fri Nov 18 12:11:49 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 4FD0B106567A for ; Fri, 18 Nov 2011 12:11:49 +0000 (UTC) (envelope-from radiomlodychbandytow@o2.pl) Received: from moh2-ve1.go2.pl (moh2-ve1.go2.pl [193.17.41.186]) by mx1.freebsd.org (Postfix) with ESMTP id 107D58FC12 for ; Fri, 18 Nov 2011 12:11:48 +0000 (UTC) Received: from moh2-ve1.go2.pl (unknown [10.0.0.186]) by moh2-ve1.go2.pl (Postfix) with ESMTP id 16AB044D7C3 for ; Fri, 18 Nov 2011 13:11:47 +0100 (CET) Received: from unknown (unknown [10.0.0.142]) by moh2-ve1.go2.pl (Postfix) with SMTP for ; Fri, 18 Nov 2011 13:11:47 +0100 (CET) Received: from host892524678.com-promis.3s.pl [89.25.246.78] by poczta.o2.pl with ESMTP id lftIzn; Fri, 18 Nov 2011 13:11:47 +0100 Message-ID: <4EC64B7E.20406@o2.pl> Date: Fri, 18 Nov 2011 13:11:42 +0100 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-O2-Trust: 2, 64 X-O2-SPF: neutral Subject: ZFS version 30 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 Nov 2011 12:11:49 -0000 There was a rumour that Oracle was to open source the latest ZFS code after Solaris 11 release. Any news about it? -- Twoje radio From owner-freebsd-fs@FreeBSD.ORG Fri Nov 18 12:49:31 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 99D80106566C for ; Fri, 18 Nov 2011 12:49:31 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 3881D8FC14 for ; Fri, 18 Nov 2011 12:49:31 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 6A66D133A9; Fri, 18 Nov 2011 13:49:30 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id W0t8FtCEk-c0; Fri, 18 Nov 2011 13:49:25 +0100 (CET) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id 4C3B4133A0; Fri, 18 Nov 2011 13:49:25 +0100 (CET) Message-ID: <4EC65454.7040403@FreeBSD.org> Date: Fri, 18 Nov 2011 13:49:24 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= References: <4EC64B7E.20406@o2.pl> In-Reply-To: <4EC64B7E.20406@o2.pl> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS version 30 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 Nov 2011 12:49:31 -0000 On 18.11.2011 13:11, Radio młodych bandytów wrote: > There was a rumour that Oracle was to open source the latest ZFS code > after Solaris 11 release. Any news about it? > The source code released with Orace Solaris 11 does not contain any CDDL code. More information here: http://oss.oracle.com/systems-opensourcecode/ I personally do not believe that there will be any new release of ZFS source code in the near future. This depends purely on Oracle. We are currently cooperating with Illumos (http://www.illumos.org): - Illumos has more ZFS developers than we do - we have been importing bugfixes and new features from Illumos - we have been reporting bugs and features from our development that might be of value for Illumos This way the code can be reviewed by more eyes and tested in by a broader userbase. -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Fri Nov 18 18:53: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 5FF8A1065676 for ; Fri, 18 Nov 2011 18:53:10 +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 16C468FC1B for ; Fri, 18 Nov 2011 18:53:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RRTYg-0003Pn-FI for freebsd-fs@freebsd.org; Fri, 18 Nov 2011 19:53:06 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2011 19:53:06 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2011 19:53:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Mark Atkinson Date: Fri, 18 Nov 2011 10:52:53 -0800 Lines: 23 Message-ID: References: <1289442296.2128.16.camel@monet> <20101111122455.GA2098@tops> <1321254414.1951.12.camel@esl.kevlo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111109 Thunderbird/8.0 In-Reply-To: <1321254414.1951.12.camel@esl.kevlo.org> X-Enigmail-Version: undefined Subject: Re: patch: let msdosfs(vfat)/ntfs to support UTF-8 locale well 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 Nov 2011 18:53:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/13/2011 23:06, Kevin Lo wrote: > On Thu, 2011-03-31 at 18:56 +0800, Buganini wrote: >> http://security-hole.info/~buganini/patches/kiconv_msdosfs/ >> >> I've adapted the 4th patchset for CURRENT, but I've only test it >> with -ro on amd64. another i386 machine is on the way. > > Sorry for the slow response. I've tested your patch and it seems to > work fine for me on i386 and amd64. I'd commit your patch if there > is no objection, thanks. kern/133174 ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7GqYUACgkQrDN5kXnx8ybHuwCfc9q+EA0N8AtCbPhqFqxWsT5L m7cAnApd6/ztcagX7y5xxNeopBhda532 =GOdp -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 19 03:30:11 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 29530106566C for ; Sat, 19 Nov 2011 03:30:11 +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 18D638FC08 for ; Sat, 19 Nov 2011 03:30:11 +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 pAJ3UA1S047291 for ; Sat, 19 Nov 2011 03:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAJ3UAUM047286; Sat, 19 Nov 2011 03:30:10 GMT (envelope-from gnats) Date: Sat, 19 Nov 2011 03:30:10 GMT Message-Id: <201111190330.pAJ3UAUM047286@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/153847: 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 Nov 2011 03:30:11 -0000 The following reply was made to PR kern/153847; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/153847: commit references a PR Date: Sat, 19 Nov 2011 03:20:28 +0000 (UTC) Author: rmacklem Date: Sat Nov 19 03:20:15 2011 New Revision: 227690 URL: http://svn.freebsd.org/changeset/base/227690 Log: The old NFS client will crash due to the reply being m_freem()'d twice if the server bogusly returns an error with the NFSERR_RETERR bit (bit 31) set. No actual NFS error has this bit set, but it seems that amd will sometimes do this. This patch makes sure the NFSERR_RETERR bit is cleared to avoid a crash. PR: kern/153847 MFC after: 2 weeks Modified: head/sys/nfsclient/nfs_krpc.c Modified: head/sys/nfsclient/nfs_krpc.c ============================================================================== --- head/sys/nfsclient/nfs_krpc.c Sat Nov 19 00:20:28 2011 (r227689) +++ head/sys/nfsclient/nfs_krpc.c Sat Nov 19 03:20:15 2011 (r227690) @@ -540,6 +540,11 @@ tryagain: hz); goto tryagain; } + /* + * Make sure NFSERR_RETERR isn't bogusly set by a server + * such as amd. (No actual NFS error has bit 31 set.) + */ + error &= ~NFSERR_RETERR; /* * If the File Handle was stale, invalidate the lookup _______________________________________________ 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 Nov 19 14:50: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 73E06106566C; Sat, 19 Nov 2011 14:50:06 +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 D3F888FC14; Sat, 19 Nov 2011 14:50:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJTBx06DaFvO/2dsb2JhbABEhQGjFIMvgXIBAQUjBFIbDgoCAg0ZAlkGrFaRGIEwh1GBFgSIGowikiM X-IronPort-AV: E=Sophos;i="4.69,538,1315195200"; d="scan'208";a="144659811" 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 Nov 2011 09:50:04 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D5EABB408C; Sat, 19 Nov 2011 09:50:04 -0500 (EST) Date: Sat, 19 Nov 2011 09:50:04 -0500 (EST) From: Rick Macklem To: Bruce Evans Message-ID: <362559065.2089977.1321714204815.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20111120004351.Q2309@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, Josh Paetzel , zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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 Nov 2011 14:50:06 -0000 Bruce Evans wrote: > On Sat, 5 Nov 2011, Rick Macklem wrote: > > I was away on 5 Nov... > > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > > for the new NFS server. > > Excellent! It's existence for the old nfs server is a bug. The correct > way to enable async is to mount the client async. nfsclient only has > a tiny amount of support for this, but it seems to be suficient: > > % int > % ncl_writerpc(struct vnode *vp, struct uio *uiop, struct ucred *cred, > % int *iomode, int *must_commit, int called_from_strategy) > % { > % ... > % if (vp->v_mount->mnt_kern_flag & MNTK_ASYNC) > % *iomode = NFSWRITE_FILESYNC; > % if (error && NFS_ISV4(vp)) > % error = nfscl_maperr(uiop->uio_td, error, (uid_t)0, (gid_t)0); > % return (error); > % } > > (The old nfs server is similar.) As far as I understand this (not very > far), this "works" by pretending that the server completed the sync > even when the server said otherwise. This is far from being correct, > but a correct version seems too hard since it would require servers > (not just FreeBSD ones) to actually understand asyncness. > > The sysctl shouldn't exist because it just causes the same pretense > to happen on the server. This just applies the hack too globally > -- it now affects all mount instances on all clients. However, > there may be a problem for nfsv2. I used to think that v3 clients > were much less hackish than the above, and implemented async mounts > by not asking servers to do a full NFS[V3]WRITE_FILESYNC for async > mounts. nfsv2 clients can't do that since the nvfs2 protocol is too > simple to be able to request different types and/or levels of syncing. > Now I think that the above hack works for v2 too, but is just a hack. > > > I don't think I had spotted this before, but when I looked I > > saw that, when vfs.nfsrv.async is set non-zero in the old server, > > it returns FILESYNC (which means the write has been committed to > > non-volatile storage) even when it hasn't actually done that. > > > > This can improve performance, but has some negative implications: > > - If the server crashes before the write is committed to > > non-volatile storage, the file modification will be lost. > > (When a server replies UNSTABLE to a write, the client holds > > onto the data in its cache and does the write again if the > > server crashes/reboots before the client does a Commit RPC > > for the file. However, a reply of FILESYNC tells the client > > it can forget about the write, because it is done.) > > - Because of the above, replying FILESYNC when the data is not > > yet committed to non-volatile (also referred to as stable) > > storage, this is a violation of RFC1813. > > > > I wouldn't want this to be the default, but am willing to > > patch head based on the "backwards compatibility" argument. > > My concern with these types of patches is that some people > > will enable them without realizing the risk of data loss > > that they introduce. > > > > So, how do others feel with respect to whether or not this > > patch should be committed to head? > > > > Thanks in advance for any comments, rick > > ps: Here's the patch, just in case anyone is interested. > > --- fs/nfsserver/nfs_nfsdserv.c.sav 2011-11-05 10:29:38.000000000 > > -0400 > > +++ fs/nfsserver/nfs_nfsdserv.c 2011-11-05 10:37:40.000000000 -0400 > > @@ -55,6 +55,11 @@ extern int nfs_rootfhset; > > extern int nfsrv_enable_crossmntpt; > > #endif /* !APPLEKEXT */ > > > > +static int nfs_async = 0; > > +SYSCTL_DECL(_vfs_nfsd); > > +SYSCTL_INT(_vfs_nfsd, OID_AUTO, async, CTLFLAG_RW, &nfs_async, 0, > > + "Tell client that writes were synced even though they were not"); > > + > > /* > > * This list defines the GSS mechanisms supported. > > * (Don't ask me how you get these strings from the RFC stuff like > > @@ -912,7 +917,13 @@ nfsrvd_write(struct nfsrv_descript *nd, > > goto out; > > NFSM_BUILD(tl, u_int32_t *, 4 * NFSX_UNSIGNED); > > *tl++ = txdr_unsigned(retlen); > > - if (stable == NFSWRITE_UNSTABLE) > > + /* > > + * If nfs_async is set, then pretend the write was FILESYNC. > > + * Warning: Doing this violates RFC1813 and runs a risk > > + * of data written by a client being lost when the server > > + * crashes/reboots. > > + */ > > + if (stable == NFSWRITE_UNSTABLE && nfs_async == 0) > > *tl++ = txdr_unsigned(stable); > > else > > *tl++ = txdr_unsigned(NFSWRITE_FILESYNC); > > This is for the v3 and v4 cases, the same as in the old nfs server > where its > existence is clearly just a bug. This is missing support for the v2 > case > where its existence is not so clearly just a bug. Here is the code for > the > v2 case in the old nfs server: > An NFSv2 write is always "FILESYNC". There is no reply argument to say otherwise. The concept of NFSWRITE_UNSTABLE was added for NFSv3. > % int > % nfsrv_write(struct nfsrv_descript *nfsd, struct nfssvc_sock *slp, > % struct mbuf **mrq) > % { > % ... > % if (v3) { > % tl = nfsm_dissect_nonblock(u_int32_t *, 5 * NFSX_UNSIGNED); > % off = fxdr_hyper(tl); > % tl += 3; > % stable = fxdr_unsigned(int, *tl++); > % } else { > % tl = nfsm_dissect_nonblock(u_int32_t *, 4 * NFSX_UNSIGNED); > % off = (off_t)fxdr_unsigned(u_int32_t, *++tl); > % tl += 2; > % if (nfs_async) > % stable = NFSV3WRITE_UNSTABLE; > > The v2 case can't tell what the client asked for, so it frobs `stable' > unconditionally here instead of later depending on the value of > `stable'. > But perhaps doing nothing here works OK, since the client does the > same frobbing (just as unconditionally even for v3-4). > Yep, as above. There is no reply argument and the NFSv2 client will assume FILESYNC. So, I believe doing nothing is fine. > % } > % ... > % if (v3) { > % ... > % /* > % * If nfs_async is set, then pretend the write was FILESYNC. > % */ > % if (stable == NFSV3WRITE_UNSTABLE && !nfs_async) > % *tl++ = txdr_unsigned(stable); > % else > % *tl++ = txdr_unsigned(NFSV3WRITE_FILESYNC); > > Perhaps the hack in the client can be improved slightly by using the > same > logic as here -- only converting to FILESYNC if the server said > UNSTABLE. > I don't know if other states can actually happen. > There is one other state called NFSWRITE_METADATA (means the metadata has been sync'd but the data hasn't). The FreeBSD server never does this, but it seems that, if it is going to lie about it, it might as well lie about the METADATA case as well. rick From owner-freebsd-fs@FreeBSD.ORG Sat Nov 19 14:59:31 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 6808B106564A; Sat, 19 Nov 2011 14:59:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id F16228FC08; Sat, 19 Nov 2011 14:59:30 +0000 (UTC) Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAJExQp5003700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2011 01:59:28 +1100 Date: Sun, 20 Nov 2011 01:59:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Josh Paetzel In-Reply-To: <4EB6B4E9.1000804@tcbug.org> Message-ID: <20111120013659.J2309@besplex.bde.org> References: <1391798614.1239830.1320593648931.JavaMail.root@erie.cs.uoguelph.ca> <4EB6B4E9.1000804@tcbug.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Josh Paetzel , freebsd-fs@freebsd.org, zkirsch@freebsd.org, Ronald Klop Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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 Nov 2011 14:59:31 -0000 On Sun, 6 Nov 2011, Josh Paetzel wrote: > On 11/06/11 07:34, Rick Macklem wrote: >> Ronald Klop wrote: >>> On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem >>> >>> wrote: >>> >>>> Hi, >>>> >>>> Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist >>>> for the new NFS server. >>>> >>>> I don't think I had spotted this before, but when I looked I >>>> saw that, when vfs.nfsrv.async is set non-zero in the old server, >>>> it returns FILESYNC (which means the write has been committed to >>>> non-volatile storage) even when it hasn't actually done that. >>>> >>>> This can improve performance, but has some negative implications: >>>> ... >>> >>> Just out of curiosity. Why would lying about FILESYNC improve >>> performance >>> over UNSTABLE? The server does the same work. Only the client holds >>> data >>> longer in memory. I only see impact if the client has just a little >>> bit of >>> memory. >>> >>> Ronald. >> Well, I'm not sure I have an answer. Josh noted that it makes a big >> difference for them. Maybe he can elaborate? It is not completely clear how fudging FILESYNC gives asyncness, but in general asyncness improves performance by not being sync. syncness forces writing of tinygrams, often several times at the same place for metadata. asyncness should allow the server to delay writing for as long as it wants. > I'll test it out and report back in the next week or so. > > In 8.x, setting the async sysctl was the difference between 80-100MB/sec > and 800 MB/sec (Yes, MegaBytes!) using a variety of different clients, > including the VMWare ESXi 4.x client, Xen 5.6 client, various linux > clients and the FreeBSD client. I'll note that 800MB/sec is getting > close to the underlying filesystem performance, so it's likely that the > gate to performance is in the filesystem in that case. 80-100MB/sec is > basically gigE performance. Didn't you mount the client file systems async? This has worked since FreeBSD-3 or earlier. It also helps to mount the server file system async. Unfortunately, this shows another need for the too-global sysctl on the server -- non-FreeBSD clients might not support async mounts. In my previous reply, I said that the sysctl might not be needed for v2 clients, since even v2 clients can fudge the return code. Now I don't see how that can help -- v2 clients can't ask for UNSTABLE, so v2 servers must always give them FILESYNC (or an error), so the return code is already FILESYNC. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Nov 19 15:08:58 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 B0D9210657D1; Sat, 19 Nov 2011 15:08:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 37B9D8FC14; Sat, 19 Nov 2011 15:08:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGPFx06DaFvO/2dsb2JhbABDhQGmQ4FyAQEEASNWBRYOCgICDRkCSw4GE4gDpC2RD4Ewh1GBFgSIGowikiM X-IronPort-AV: E=Sophos;i="4.69,538,1315195200"; d="scan'208";a="146137044" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 19 Nov 2011 10:08:57 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3665CB4019; Sat, 19 Nov 2011 10:08:57 -0500 (EST) Date: Sat, 19 Nov 2011 10:08:57 -0500 (EST) From: Rick Macklem To: Bruce Evans Message-ID: <559561010.2090200.1321715337128.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20111120013659.J2309@besplex.bde.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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: Josh Paetzel , freebsd-fs@freebsd.org, zkirsch@freebsd.org, Ronald Klop Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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 Nov 2011 15:08:58 -0000 Bruce Evans wrote: > On Sun, 6 Nov 2011, Josh Paetzel wrote: > > > On 11/06/11 07:34, Rick Macklem wrote: > >> Ronald Klop wrote: > >>> On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem > >>> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > >>>> for the new NFS server. > >>>> > >>>> I don't think I had spotted this before, but when I looked I > >>>> saw that, when vfs.nfsrv.async is set non-zero in the old server, > >>>> it returns FILESYNC (which means the write has been committed to > >>>> non-volatile storage) even when it hasn't actually done that. > >>>> > >>>> This can improve performance, but has some negative implications: > >>>> ... > >>> > >>> Just out of curiosity. Why would lying about FILESYNC improve > >>> performance > >>> over UNSTABLE? The server does the same work. Only the client > >>> holds > >>> data > >>> longer in memory. I only see impact if the client has just a > >>> little > >>> bit of > >>> memory. > >>> > >>> Ronald. > >> Well, I'm not sure I have an answer. Josh noted that it makes a big > >> difference for them. Maybe he can elaborate? > > It is not completely clear how fudging FILESYNC gives asyncness, but > in general asyncness improves performance by not being sync. syncness > forces writing of tinygrams, often several times at the same place for > metadata. asyncness should allow the server to delay writing for as > long as it wants. > > > I'll test it out and report back in the next week or so. > > > > In 8.x, setting the async sysctl was the difference between > > 80-100MB/sec > > and 800 MB/sec (Yes, MegaBytes!) using a variety of different > > clients, > > including the VMWare ESXi 4.x client, Xen 5.6 client, various linux > > clients and the FreeBSD client. I'll note that 800MB/sec is getting > > close to the underlying filesystem performance, so it's likely that > > the > > gate to performance is in the filesystem in that case. 80-100MB/sec > > is > > basically gigE performance. > > Didn't you mount the client file systems async? This has worked since > FreeBSD-3 or earlier. It also helps to mount the server file system > async. > > Unfortunately, this shows another need for the too-global sysctl on > the server -- non-FreeBSD clients might not support async mounts. > Yes, I can see an argument for the server sysctl, based on the fact that some clients won't have an "async" mount option. Understandable, since doing so essentially ignores the RFC. I'm waiting to hear from Josh with respect to whether or not the patch does the trick for him. > In my previous reply, I said that the sysctl might not be needed for > v2 clients, since even v2 clients can fudge the return code. Now I > don't see how that can help -- v2 clients can't ask for UNSTABLE, > so v2 servers must always give them FILESYNC (or an error), so the > return code is already FILESYNC. > Yes, there is no argument in the reply. NFSv2 is always FILESYNC. Thanks for the comments, rick From owner-freebsd-fs@FreeBSD.ORG Sat Nov 19 15:34:20 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 2B18A106564A; Sat, 19 Nov 2011 15:34:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id A5F6F8FC0C; Sat, 19 Nov 2011 15:34:13 +0000 (UTC) Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAJFYAfW018583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2011 02:34:11 +1100 Date: Sun, 20 Nov 2011 02:34:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <362559065.2089977.1321714204815.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20111120020331.M2589@besplex.bde.org> References: <362559065.2089977.1321714204815.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.ORG, Josh Paetzel , zkirsch@FreeBSD.ORG Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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 Nov 2011 15:34:20 -0000 On Sat, 19 Nov 2011, Rick Macklem wrote: > Bruce Evans wrote: >> On Sat, 5 Nov 2011, Rick Macklem wrote: >> >> I was away on 5 Nov... >> >>> Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist >>> for the new NFS server. >> >> Excellent! It's existence for the old nfs server is a bug. The correct >> way to enable async is to mount the client async. nfsclient only has >> a tiny amount of support for this, but it seems to be suficient: >> >> % int >> % ncl_writerpc(struct vnode *vp, struct uio *uiop, struct ucred *cred, >> % int *iomode, int *must_commit, int called_from_strategy) >> % { >> % ... >> % if (vp->v_mount->mnt_kern_flag & MNTK_ASYNC) >> % *iomode = NFSWRITE_FILESYNC; >> % if (error && NFS_ISV4(vp)) >> % error = nfscl_maperr(uiop->uio_td, error, (uid_t)0, (gid_t)0); >> % return (error); >> % } >> ... >>> ps: Here's the patch, just in case anyone is interested. >>> --- fs/nfsserver/nfs_nfsdserv.c.sav 2011-11-05 10:29:38.000000000 >>> -0400 >>> +++ fs/nfsserver/nfs_nfsdserv.c 2011-11-05 10:37:40.000000000 -0400 >>> @@ -55,6 +55,11 @@ extern int nfs_rootfhset; >>> extern int nfsrv_enable_crossmntpt; >>> #endif /* !APPLEKEXT */ >>> >>> +static int nfs_async = 0; >>> +SYSCTL_DECL(_vfs_nfsd); >>> +SYSCTL_INT(_vfs_nfsd, OID_AUTO, async, CTLFLAG_RW, &nfs_async, 0, >>> + "Tell client that writes were synced even though they were not"); >>> + >>> /* >>> * This list defines the GSS mechanisms supported. >>> * (Don't ask me how you get these strings from the RFC stuff like >>> @@ -912,7 +917,13 @@ nfsrvd_write(struct nfsrv_descript *nd, >>> goto out; >>> NFSM_BUILD(tl, u_int32_t *, 4 * NFSX_UNSIGNED); >>> *tl++ = txdr_unsigned(retlen); >>> - if (stable == NFSWRITE_UNSTABLE) >>> + /* >>> + * If nfs_async is set, then pretend the write was FILESYNC. >>> + * Warning: Doing this violates RFC1813 and runs a risk >>> + * of data written by a client being lost when the server >>> + * crashes/reboots. >>> + */ >>> + if (stable == NFSWRITE_UNSTABLE && nfs_async == 0) >>> *tl++ = txdr_unsigned(stable); >>> else >>> *tl++ = txdr_unsigned(NFSWRITE_FILESYNC); >> >> This is for the v3 and v4 cases, the same as in the old nfs server >> where its >> existence is clearly just a bug. This is missing support for the v2 >> case >> where its existence is not so clearly just a bug. Here is the code for >> the >> v2 case in the old nfs server: >> > An NFSv2 write is always "FILESYNC". There is no reply argument to say > otherwise. The concept of NFSWRITE_UNSTABLE was added for NFSv3. > >> % int >> % nfsrv_write(struct nfsrv_descript *nfsd, struct nfssvc_sock *slp, >> % struct mbuf **mrq) >> % { >> % ... >> % if (v3) { >> % tl = nfsm_dissect_nonblock(u_int32_t *, 5 * NFSX_UNSIGNED); >> % off = fxdr_hyper(tl); >> % tl += 3; >> % stable = fxdr_unsigned(int, *tl++); >> % } else { >> % tl = nfsm_dissect_nonblock(u_int32_t *, 4 * NFSX_UNSIGNED); >> % off = (off_t)fxdr_unsigned(u_int32_t, *++tl); >> % tl += 2; >> % if (nfs_async) >> % stable = NFSV3WRITE_UNSTABLE; >> >> The v2 case can't tell what the client asked for, so it frobs `stable' >> unconditionally here instead of later depending on the value of >> `stable'. >> But perhaps doing nothing here works OK, since the client does the >> same frobbing (just as unconditionally even for v3-4). >> > Yep, as above. There is no reply argument and the NFSv2 client will > assume FILESYNC. So, I believe doing nothing is fine. No, this means that for async to work for v2, the server must do the frobbing, and the sysctl is needed to enable this :-(. I knew this, but had forgotten the details and tried too hard to kill the sysctl. > >> % } >> % ... >> % if (v3) { >> % ... >> % /* >> % * If nfs_async is set, then pretend the write was FILESYNC. >> % */ >> % if (stable == NFSV3WRITE_UNSTABLE && !nfs_async) >> % *tl++ = txdr_unsigned(stable); >> % else >> % *tl++ = txdr_unsigned(NFSV3WRITE_FILESYNC); >> >> Perhaps the hack in the client can be improved slightly by using the >> same >> logic as here -- only converting to FILESYNC if the server said >> UNSTABLE. >> I don't know if other states can actually happen. >> > There is one other state called NFSWRITE_METADATA (means the metadata > has been sync'd but the data hasn't). The FreeBSD server never does this, > but it seems that, if it is going to lie about it, it might as well > lie about the METADATA case as well. The new nfs server has no references to META-anything, but the old nfs server has the following horribleness which includes lying about this: nfs.h: % /* % * The IO_METASYNC flag should be implemented for local filesystems. % * (Until then, it is nothin at all.) % */ % #ifndef IO_METASYNC % #define IO_METASYNC 0 % #endif nfsserv.c: % /* % * XXX % * The IO_METASYNC flag indicates that all metadata (and not just % * enough to ensure data integrity) mus be written to stable storage % * synchronously. % * (IO_METASYNC is not yet implemented in 4.4BSD-Lite.) % */ % if (stable == NFSV3WRITE_UNSTABLE) % ioflags = IO_NODELOCKED; % else if (stable == NFSV3WRITE_DATASYNC) % ioflags = (IO_SYNC | IO_NODELOCKED); % else % ioflags = (IO_METASYNC | IO_SYNC | IO_NODELOCKED); Apparently, there are only 3 states; the 3rd one is METASYNC and is handled by the else clause; but since IO_METASYNC doesn't exist in 4.4BSD-Lite (sic) and is hacked to 0, the else clause is just an obfuscated spelling of the else if clause and there might as well be only 2 states. This used to be sort of correct, since METASYNC was the default for ffs (sync metadata, async data, with no control over this short of mounting sync to get globally sync data, and O_SYNC to get locally sync data). Now there are the following complications: - async mounts should give async everything. The nfs server has no understanding of these, so it will report FILESYNC although the underlying file system didn't even sync the metadata. Even if it understood them, it has no way short of VOP_FSYNC() to force file systems to follow the client's requests for syncness. (It does use VOP_FSYNC(), but I think not enough to work for every write. Also, VOP_FSYNC() is usually buggy with async mounts and tends to sync all data but leave some metadata unsynced.) - soft updates doesn't give sync metadata (only a good ordering of syncing) - alternative file systems which have very buggy syncness (e.g., msdosfs) or sophistication which probably includes different syncness (e.g., zfs). Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Nov 19 16:55: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 5FF0E106566C; Sat, 19 Nov 2011 16:55:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id DC3CE8FC1E; Sat, 19 Nov 2011 16:55:56 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAJEZNhI003715; Sun, 20 Nov 2011 01:35:23 +1100 Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAJEZEmZ022748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2011 01:35:16 +1100 Date: Sun, 20 Nov 2011 01:35:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20111120004351.Q2309@besplex.bde.org> References: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Josh Paetzel , zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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 Nov 2011 16:55:57 -0000 On Sat, 5 Nov 2011, Rick Macklem wrote: I was away on 5 Nov... > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > for the new NFS server. Excellent! It's existence for the old nfs server is a bug. The correct way to enable async is to mount the client async. nfsclient only has a tiny amount of support for this, but it seems to be suficient: % int % ncl_writerpc(struct vnode *vp, struct uio *uiop, struct ucred *cred, % int *iomode, int *must_commit, int called_from_strategy) % { % ... % if (vp->v_mount->mnt_kern_flag & MNTK_ASYNC) % *iomode = NFSWRITE_FILESYNC; % if (error && NFS_ISV4(vp)) % error = nfscl_maperr(uiop->uio_td, error, (uid_t)0, (gid_t)0); % return (error); % } (The old nfs server is similar.) As far as I understand this (not very far), this "works" by pretending that the server completed the sync even when the server said otherwise. This is far from being correct, but a correct version seems too hard since it would require servers (not just FreeBSD ones) to actually understand asyncness. The sysctl shouldn't exist because it just causes the same pretense to happen on the server. This just applies the hack too globally -- it now affects all mount instances on all clients. However, there may be a problem for nfsv2. I used to think that v3 clients were much less hackish than the above, and implemented async mounts by not asking servers to do a full NFS[V3]WRITE_FILESYNC for async mounts. nfsv2 clients can't do that since the nvfs2 protocol is too simple to be able to request different types and/or levels of syncing. Now I think that the above hack works for v2 too, but is just a hack. > I don't think I had spotted this before, but when I looked I > saw that, when vfs.nfsrv.async is set non-zero in the old server, > it returns FILESYNC (which means the write has been committed to > non-volatile storage) even when it hasn't actually done that. > > This can improve performance, but has some negative implications: > - If the server crashes before the write is committed to > non-volatile storage, the file modification will be lost. > (When a server replies UNSTABLE to a write, the client holds > onto the data in its cache and does the write again if the > server crashes/reboots before the client does a Commit RPC > for the file. However, a reply of FILESYNC tells the client > it can forget about the write, because it is done.) > - Because of the above, replying FILESYNC when the data is not > yet committed to non-volatile (also referred to as stable) > storage, this is a violation of RFC1813. > > I wouldn't want this to be the default, but am willing to > patch head based on the "backwards compatibility" argument. > My concern with these types of patches is that some people > will enable them without realizing the risk of data loss > that they introduce. > > So, how do others feel with respect to whether or not this > patch should be committed to head? > > Thanks in advance for any comments, rick > ps: Here's the patch, just in case anyone is interested. > --- fs/nfsserver/nfs_nfsdserv.c.sav 2011-11-05 10:29:38.000000000 -0400 > +++ fs/nfsserver/nfs_nfsdserv.c 2011-11-05 10:37:40.000000000 -0400 > @@ -55,6 +55,11 @@ extern int nfs_rootfhset; > extern int nfsrv_enable_crossmntpt; > #endif /* !APPLEKEXT */ > > +static int nfs_async = 0; > +SYSCTL_DECL(_vfs_nfsd); > +SYSCTL_INT(_vfs_nfsd, OID_AUTO, async, CTLFLAG_RW, &nfs_async, 0, > + "Tell client that writes were synced even though they were not"); > + > /* > * This list defines the GSS mechanisms supported. > * (Don't ask me how you get these strings from the RFC stuff like > @@ -912,7 +917,13 @@ nfsrvd_write(struct nfsrv_descript *nd, > goto out; > NFSM_BUILD(tl, u_int32_t *, 4 * NFSX_UNSIGNED); > *tl++ = txdr_unsigned(retlen); > - if (stable == NFSWRITE_UNSTABLE) > + /* > + * If nfs_async is set, then pretend the write was FILESYNC. > + * Warning: Doing this violates RFC1813 and runs a risk > + * of data written by a client being lost when the server > + * crashes/reboots. > + */ > + if (stable == NFSWRITE_UNSTABLE && nfs_async == 0) > *tl++ = txdr_unsigned(stable); > else > *tl++ = txdr_unsigned(NFSWRITE_FILESYNC); This is for the v3 and v4 cases, the same as in the old nfs server where its existence is clearly just a bug. This is missing support for the v2 case where its existence is not so clearly just a bug. Here is the code for the v2 case in the old nfs server: % int % nfsrv_write(struct nfsrv_descript *nfsd, struct nfssvc_sock *slp, % struct mbuf **mrq) % { % ... % if (v3) { % tl = nfsm_dissect_nonblock(u_int32_t *, 5 * NFSX_UNSIGNED); % off = fxdr_hyper(tl); % tl += 3; % stable = fxdr_unsigned(int, *tl++); % } else { % tl = nfsm_dissect_nonblock(u_int32_t *, 4 * NFSX_UNSIGNED); % off = (off_t)fxdr_unsigned(u_int32_t, *++tl); % tl += 2; % if (nfs_async) % stable = NFSV3WRITE_UNSTABLE; The v2 case can't tell what the client asked for, so it frobs `stable' unconditionally here instead of later depending on the value of `stable'. But perhaps doing nothing here works OK, since the client does the same frobbing (just as unconditionally even for v3-4). % } % ... % if (v3) { % ... % /* % * If nfs_async is set, then pretend the write was FILESYNC. % */ % if (stable == NFSV3WRITE_UNSTABLE && !nfs_async) % *tl++ = txdr_unsigned(stable); % else % *tl++ = txdr_unsigned(NFSV3WRITE_FILESYNC); Perhaps the hack in the client can be improved slightly by using the same logic as here -- only converting to FILESYNC if the server said UNSTABLE. I don't know if other states can actually happen. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Nov 19 20:19: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 96B97106566C; Sat, 19 Nov 2011 20:19:25 +0000 (UTC) (envelope-from florian@wagner-flo.net) Received: from umbracor.wagner-flo.net (umbracor.wagner-flo.net [213.165.81.202]) by mx1.freebsd.org (Postfix) with ESMTP id 561858FC12; Sat, 19 Nov 2011 20:19:25 +0000 (UTC) Received: from naclador.mos32.de (ppp-188-174-38-40.dynamic.mnet-online.de [188.174.38.40]) by umbracor.wagner-flo.net (Postfix) with ESMTPSA id EFE423C065B6; Sat, 19 Nov 2011 21:19:23 +0100 (CET) Date: Sat, 19 Nov 2011 21:19:21 +0100 From: Florian Wagner To: Andriy Gapon Message-ID: <20111119211921.7ffa9953@naclador.mos32.de> In-Reply-To: <4EB98E05.4070900@FreeBSD.org> References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/WIArBJPXjyaA459VtaNDFsT"; protocol="application/pgp-signature" Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config 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 Nov 2011 20:19:25 -0000 --Sig_/WIArBJPXjyaA459VtaNDFsT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > on 19/10/2011 19:21 Florian Wagner said the following: > >> [...] > >>=20 > >>> The only thing I was a bit confused by is that on the boot prompt > >>> only the pool and filename to be booted are printed. > >>=20 > >> Do you mean the (gpt)zfsboot prompt? > >=20 > > Yes. For a boot.config with "rpool:root/something:" it prints: > >=20 > > Booting from Hard Disk... /boot.config: rpool FreeBSD/x86 boot > > Default: rpool:/boot/zfsloader boot: >=20 >=20 > Thank you very much for your testing and reports! > Please see these additional changes: > http://people.freebsd.org/~avg/zfsboot.fixes.diff Thanks for the additional patch. It seems to be exactly what I'm looking for. Sadly your patches (tested with and without the latest one) seem to break booting on RAID-Z2 arrays. The prior test, for which I've reported success were using a VM with only a single disk. Today I tried the patched bootloader on my fileserver with a 6 disk RAID-Z2 array. That didn't go so well: Installing the modified gptzfsboot results in a blinking screen with turquoise-striped ASCII background and assorted characters in the foreground. Installing the modified zfsloader (but unmodified gptzfsboot) makes it unable to find its root dataset: BTX loader 1.00 BTX version is 1.02 [...] BIOS drive C: is disk0 BIOS drive D: is disk1 [...] FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.0 [...] ZFS: can't find dataset [LONG NUMBER] ZFS: can't map root filesystem to its name can't load 'kernel' Type '?' [...] OK lsdev cd devices: disk devices: disk0: BIOS drive C: disk0p1: FreeBSD boot disk0p2: FreeBSD ZFS disk0p3: FreeBSD ZFS disk1: BIOS drive D: disk1p1: FreeBSD boot disk1p2: FreeBSD ZFS disk1p3: FreeBSD ZFS pxe devices: zfs devices: zfs:root OK The output is from my test VM, where I've reproduced the problem. Setup is: - RAID-Z2 over the four partitions disk{0,1}p{2,3}. - Pool is simply called root. - root has bootfs property set to root/stable-8-r226381. - There is no boot.config on that dataset. A zfsloader built without your patches boots the system. Any more information I can provide? Regards Florian --Sig_/WIArBJPXjyaA459VtaNDFsT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7ID0oACgkQLvW/2gp2pPzlywCeM4SnOtb0WczOo2kKQ3Kws4h7 mdoAoJtVBcgw5AE2GYcundP7CmJVvhic =Eguv -----END PGP SIGNATURE----- --Sig_/WIArBJPXjyaA459VtaNDFsT--