From owner-freebsd-fs@FreeBSD.ORG Sun Oct 24 08:20:13 2010 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 9AB13106564A for ; Sun, 24 Oct 2010 08:20:13 +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 6FAB38FC17 for ; Sun, 24 Oct 2010 08:20:13 +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 o9O8KDDL086256 for ; Sun, 24 Oct 2010 08:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9O8KDrH086254; Sun, 24 Oct 2010 08:20:13 GMT (envelope-from gnats) Date: Sun, 24 Oct 2010 08:20:13 GMT Message-Id: <201010240820.o9O8KDrH086254@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/151648: [zfs] disk wait bug X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 08:20:13 -0000 The following reply was made to PR kern/151648; it has been noted by GNATS. From: Andriy Gapon To: Bartosz Nowicki Cc: bug-followup@freebsd.org Subject: Re: kern/151648: [zfs] disk wait bug Date: Sun, 24 Oct 2010 11:12:59 +0300 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 23/10/2010 18:43 Bartosz Nowicki said the following: > Dnia 23-10-2010 o 10:58:59 Andriy Gapon napisaÅ‚(a): > >> Please provide procstat -kk -a output. > > I would rather not reveal all processes (production OS, many user accounts), but > discovered that it's not only when using nginx. [snip] > If it isn't enough I will send full output. I believe that the threads you showed so far are "secondary victims". I think that there should be a primary victim that got stuck while holding some locks and now other threads get stuck on those locks. Could you please check in procstat -kk -a if there are any threads in zio_wait call. Also, you can send the full output to me privately. - -- Andriy Gapon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMw+qLAAoJEHSlLSemUf4vbmcH+gIQuRqqs/UQBmiYaIFQFMk0 BsmPxPxr0N8gI7s7m2wlumYxnLv8Yvi8+0h0+GwHvdpHzz8xGe5W9/FO3ONt9dc/ jCPzbGd9kMypHASTDKgsGowIg3q07TICjKkKquJ3eIxS4BItHMRYmjQLceYISXZ6 qkCzUIqyUWCkSa6Ja+0/8LbJvxAce+Fp5Msc/A8Fjls85QM81sSWqFWEGluYCbFN /SkGSIWJrOWEgLxiyMNyrlMgVHj3ASfaUwb9eN7VCcGQjVZwYSJ15gnHnjjSRpJ6 Osk69wk3Wowddm+vaacrijWrHCnN/+fJ83d3fVCeUvlQ/dADhfiM8wEm6AtarY8= =H+hR -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Sun Oct 24 17:40:58 2010 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 8B95A106566C; Sun, 24 Oct 2010 17:40:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 35EAB8FC26; Sun, 24 Oct 2010 17:40:57 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AA85A45F1F; Sun, 24 Oct 2010 19:40:55 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0E43A45E93; Sun, 24 Oct 2010 19:40:49 +0200 (CEST) Date: Sun, 24 Oct 2010 19:40:12 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Message-ID: <20101024174012.GH1742@garage.freebsd.pl> References: <201010240820.o9O8KDrH086254@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CNfT9TXqV7nd4cfk" Content-Disposition: inline In-Reply-To: <201010240820.o9O8KDrH086254@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/151648: [zfs] disk wait bug 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, 24 Oct 2010 17:40:58 -0000 --CNfT9TXqV7nd4cfk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 24, 2010 at 08:20:13AM +0000, Andriy Gapon wrote: > The following reply was made to PR kern/151648; it has been noted by GNAT= S. >=20 > From: Andriy Gapon > To: Bartosz Nowicki > Cc: bug-followup@freebsd.org > Subject: Re: kern/151648: [zfs] disk wait bug > Date: Sun, 24 Oct 2010 11:12:59 +0300 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > =20 > on 23/10/2010 18:43 Bartosz Nowicki said the following: > > Dnia 23-10-2010 o 10:58:59 Andriy Gapon napisa=C5=82= (a): > >=20 > >> Please provide procstat -kk -a output. > >=20 > > I would rather not reveal all processes (production OS, many user acco= unts), but > > discovered that it's not only when using nginx. > [snip] > > If it isn't enough I will send full output. > =20 > I believe that the threads you showed so far are "secondary victims". > I think that there should be a primary victim that got stuck while holdi= ng some > locks and now other threads get stuck on those locks. I agree. First we need to find what the thread which holds this vnode lock is doing. The best way to do that is recompiling the kernel with WITNESS and use DDB to figure this out. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --CNfT9TXqV7nd4cfk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzEb3sACgkQForvXbEpPzTHpQCeKNn8SWc6lnNFuNS/ApdWdxXc g0AAn1Qidn6QY5q21Vp01v8okVXVRws1 =0Pld -----END PGP SIGNATURE----- --CNfT9TXqV7nd4cfk-- From owner-freebsd-fs@FreeBSD.ORG Mon Oct 25 06:10:08 2010 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 589D7106566B for ; Mon, 25 Oct 2010 06:10: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 41A9F8FC15 for ; Mon, 25 Oct 2010 06:10: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 o9P6A8AA046675 for ; Mon, 25 Oct 2010 06:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9P6A8Ut046674; Mon, 25 Oct 2010 06:10:08 GMT (envelope-from gnats) Date: Mon, 25 Oct 2010 06:10:08 GMT Message-Id: <201010250610.o9P6A8Ut046674@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/151648: [zfs] disk wait bug X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 06:10:08 -0000 The following reply was made to PR kern/151648; it has been noted by GNATS. From: Andriy Gapon To: Bartosz Nowicki Cc: bug-followup@freebsd.org Subject: Re: kern/151648: [zfs] disk wait bug Date: Mon, 25 Oct 2010 09:02:31 +0300 on 24/10/2010 23:10 Bartosz Nowicki said the following: > Dnia 24-10-2010 o 10:12:59 Andriy Gapon napisaÅ‚(a): > >> I believe that the threads you showed so far are "secondary victims". >> I think that there should be a primary victim that got stuck while holding some >> locks and now other threads get stuck on those locks. >> >> Could you please check in procstat -kk -a if there are any threads in zio_wait >> call. Also, you can send the full output to me privately. > > Hi Andriy, > There are no threads in zio_wait state. Full output from procstat attached. Please try upgrading to a more recent version of stable/8, particularly you want revision r213924 from 2010-10-16. Please let us know if that helps. Thank you! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Oct 25 11:07:00 2010 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 E47921065709 for ; Mon, 25 Oct 2010 11:07:00 +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 ACBBE8FC14 for ; Mon, 25 Oct 2010 11:07: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 o9PB70A5088763 for ; Mon, 25 Oct 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9PB6xRj088761 for freebsd-fs@FreeBSD.org; Mon, 25 Oct 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Oct 2010 11:06:59 GMT Message-Id: <201010251106.o9PB6xRj088761@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, 25 Oct 2010 11:07:01 -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/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/151082 fs [zfs] [patch] sappend-flaged files on ZFS not working f kern/150910 fs [nfs] wsize=16384 on udp nfs mount unusable o kern/150796 fs [panic] [suj] [ufs] [softupdates] Panic on portbuild o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149855 fs [gvinum] growfs causes fsck to report errors in Filesy o kern/149495 fs [zfs] chflags sappend on zfs not working right o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/147292 fs [nfs] [patch] readahead missing in nfs client options o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c o kern/144458 fs [nfs] [patch] nfsd fails as a kld p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o 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/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135667 fs [lor] LORs causing ufs filesystem corruption on XEN Do o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp f kern/115645 fs [ffs] [snapshots] [panic] lockmgr: thread 0xc4c00d80, o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o bin/94635 fs snapinfo(8)/libufs only works for disk-backed filesyst o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/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/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 211 problems total. From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 01:15:21 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0AA581065697; Tue, 26 Oct 2010 01:15:21 +0000 (UTC) Date: Tue, 26 Oct 2010 01:15:21 +0000 From: Alexander Best To: freebsd-fs@freebsd.org Message-ID: <20101026011521.GA53390@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline Subject: two ata(4) issues 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, 26 Oct 2010 01:15:21 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, 1) ata(4) doesn't seem to be linked to ar(4) (see attached patch) 2) sys/modules/ata/atacam doesn't build cheers. alex -- a13x --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Makefile_ar.4.diff" diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile index 7e5cdf1..617df32 100644 --- a/share/man/man4/Makefile +++ b/share/man/man4/Makefile @@ -505,7 +505,8 @@ MLINKS+=agp.4 agpgart.4 MLINKS+=ale.4 if_ale.4 MLINKS+=altq.4 ALTQ.4 MLINKS+=an.4 if_an.4 -MLINKS+=ata.4 acd.4 \ +MLINKS+=ata.4 ar.4 + ata.4 acd.4 \ ata.4 ad.4 \ ata.4 afd.4 \ ata.4 ast.4 --vkogqOf2sHV7VnPd-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 01:17:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6C373106566C; Tue, 26 Oct 2010 01:17:28 +0000 (UTC) Date: Tue, 26 Oct 2010 01:17:28 +0000 From: Alexander Best To: freebsd-fs@freebsd.org Message-ID: <20101026011728.GA53802@freebsd.org> References: <20101026011521.GA53390@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20101026011521.GA53390@freebsd.org> Subject: Re: two ata(4) issues 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, 26 Oct 2010 01:17:28 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue Oct 26 10, Alexander Best wrote: > hi there, > > 1) ata(4) doesn't seem to be linked to ar(4) (see attached patch) > 2) sys/modules/ata/atacam doesn't build > > cheers. > alex > > -- > a13x > diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile > index 7e5cdf1..617df32 100644 > --- a/share/man/man4/Makefile > +++ b/share/man/man4/Makefile > @@ -505,7 +505,8 @@ MLINKS+=agp.4 agpgart.4 > MLINKS+=ale.4 if_ale.4 > MLINKS+=altq.4 ALTQ.4 > MLINKS+=an.4 if_an.4 > -MLINKS+=ata.4 acd.4 \ > +MLINKS+=ata.4 ar.4 oops. little tipo. sorry for the noise. attached a new patch. ;) > + ata.4 acd.4 \ > ata.4 ad.4 \ > ata.4 afd.4 \ > ata.4 ast.4 -- a13x --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Makefile_ar.4.diff2" diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile index 7e5cdf1..e7d3dc7 100644 --- a/share/man/man4/Makefile +++ b/share/man/man4/Makefile @@ -505,7 +505,8 @@ MLINKS+=agp.4 agpgart.4 MLINKS+=ale.4 if_ale.4 MLINKS+=altq.4 ALTQ.4 MLINKS+=an.4 if_an.4 -MLINKS+=ata.4 acd.4 \ +MLINKS+=ata.4 ar.4 \ + ata.4 acd.4 \ ata.4 ad.4 \ ata.4 afd.4 \ ata.4 ast.4 --vtzGhvizbBRQ85DL-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 09:36:48 2010 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 E03E4106566C; Tue, 26 Oct 2010 09:36:48 +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 B6ACE8FC14; Tue, 26 Oct 2010 09:36:48 +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 o9Q9amFb028226; Tue, 26 Oct 2010 09:36:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9Q9amfR028222; Tue, 26 Oct 2010 09:36:48 GMT (envelope-from linimon) Date: Tue, 26 Oct 2010 09:36:48 GMT Message-Id: <201010260936.o9Q9amfR028222@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/149208: mksnap_ffs(8) hang/deadlock 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, 26 Oct 2010 09:36:49 -0000 Synopsis: mksnap_ffs(8) hang/deadlock Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 26 09:36:31 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149208 From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 11:27:15 2010 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 4FD62106566C; Wed, 27 Oct 2010 11:27:15 +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 264188FC17; Wed, 27 Oct 2010 11:27:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9RBRF5Z068737; Wed, 27 Oct 2010 11:27:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RBRFHn068733; Wed, 27 Oct 2010 11:27:15 GMT (envelope-from linimon) Date: Wed, 27 Oct 2010 11:27:15 GMT Message-Id: <201010271127.o9RBRFHn068733@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/151326: [nfs] nfs exports fail if netgroups contain duplicate entries 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, 27 Oct 2010 11:27:15 -0000 Old Synopsis: nfs exports fail if netgroups contain duplicate entries New Synopsis: [nfs] nfs exports fail if netgroups contain duplicate entries Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 27 11:26:54 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=151326 From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 16:19:28 2010 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 807F21065673; Wed, 27 Oct 2010 16:19:28 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 574468FC14; Wed, 27 Oct 2010 16:19:28 +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 o9RGJSRU070395; Wed, 27 Oct 2010 16:19:28 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RGJQIU070389; Wed, 27 Oct 2010 16:19:26 GMT (envelope-from jh) Date: Wed, 27 Oct 2010 16:19:26 GMT Message-Id: <201010271619.o9RGJQIU070389@freefall.freebsd.org> To: nowak@xpam.de, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/147292: [nfs] [patch] readahead missing in nfs client options filter list 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, 27 Oct 2010 16:19:28 -0000 Synopsis: [nfs] [patch] readahead missing in nfs client options filter list State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Wed Oct 27 16:19:26 UTC 2010 State-Changed-Why: Duplicate of 151321. Fixed in head (r214418). http://www.freebsd.org/cgi/query-pr.cgi?pr=147292 From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 18:11:32 2010 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 BA1D8106566C; Wed, 27 Oct 2010 18:11:32 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 909938FC0A; Wed, 27 Oct 2010 18:11:32 +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 o9RIBWW5092914; Wed, 27 Oct 2010 18:11:32 GMT (envelope-from rmacklem@freefall.freebsd.org) Received: (from rmacklem@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RIBWU4092910; Wed, 27 Oct 2010 18:11:32 GMT (envelope-from rmacklem) Date: Wed, 27 Oct 2010 18:11:32 GMT Message-Id: <201010271811.o9RIBWU4092910@freefall.freebsd.org> To: rs@bytecamp.net, rmacklem@FreeBSD.org, freebsd-fs@FreeBSD.org From: rmacklem@FreeBSD.org Cc: Subject: Re: kern/150910: [nfs] wsize=16384 on udp nfs mount unusable 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, 27 Oct 2010 18:11:32 -0000 Synopsis: [nfs] wsize=16384 on udp nfs mount unusable State-Changed-From-To: feedback->closed State-Changed-By: rmacklem State-Changed-When: Wed Oct 27 18:09:10 UTC 2010 State-Changed-Why: The fix has now been committed to stable/8. http://www.freebsd.org/cgi/query-pr.cgi?pr=150910 From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 21:33:46 2010 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 AE020106566C; Wed, 27 Oct 2010 21:33:46 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 822D58FC12; Wed, 27 Oct 2010 21:33:46 +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 o9RLXkEt098841; Wed, 27 Oct 2010 21:33:46 GMT (envelope-from rmacklem@freefall.freebsd.org) Received: (from rmacklem@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RLXkIX098837; Wed, 27 Oct 2010 21:33:46 GMT (envelope-from rmacklem) Date: Wed, 27 Oct 2010 21:33:46 GMT Message-Id: <201010272133.o9RLXkIX098837@freefall.freebsd.org> To: danny@cs.huji.ac.il, rmacklem@FreeBSD.org, freebsd-fs@FreeBSD.org From: rmacklem@FreeBSD.org Cc: Subject: Re: kern/139363: [nfs] diskless root nfs mount from non FreeBSD server broken 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, 27 Oct 2010 21:33:46 -0000 Synopsis: [nfs] diskless root nfs mount from non FreeBSD server broken State-Changed-From-To: open->closed State-Changed-By: rmacklem State-Changed-When: Wed Oct 27 21:30:49 UTC 2010 State-Changed-Why: Fixed by the commits r212716 and r212717 to stable/8, which made pxeboot use NFSv3 instead of NFSv2. http://www.freebsd.org/cgi/query-pr.cgi?pr=139363 From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 06:16:59 2010 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 9E2B4106564A; Thu, 28 Oct 2010 06:16:59 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 07C588FC13; Thu, 28 Oct 2010 06:16:58 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBLUI-000Ekh-E8; Thu, 28 Oct 2010 09:57:26 +0400 From: "Alexander Zagrebin" To: , Date: Thu, 28 Oct 2010 09:57:22 +0400 Message-ID: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Act2ZPxUz6rRUJtETk+Jz39oDL6cGA== Cc: Subject: 8.1-STABLE: zfs and sendfile: problem still exists 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, 28 Oct 2010 06:16:59 -0000 Hi! I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. When accessing a file at first time the transfer speed is too low, but on following attempts the transfer speed is normal. How to repeat: $ dd if=/dev/random of=/tmp/test bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) $ sudo env LC_ALL=C /usr/libexec/ftpd -D The first attempt to fetch file: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted The transfer rate is too low (approx. 120 kBps), but any subsequent attempts are success: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 42 MBps $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 47 MBps ... To repeat it is enough to copy a file and to try again: $ cp /tmp/test /tmp/test1 $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 2% of 100 MB 119 kBps 13m50s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 47 MBps ...and again: $ cp /tmp/test1 /tmp/test2 $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 47 MBps I've tried ftpd and nginx with "sendfile on". The behavior is the same. After disabling using sendfile in nginx ("sendfile off") the problem has gone. -- Alexander Zagrebin From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 12:17:03 2010 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 D08EE106564A; Thu, 28 Oct 2010 12:17:03 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 78BEF8FC14; Thu, 28 Oct 2010 12:17:03 +0000 (UTC) Received: by qwe4 with SMTP id 4so1840551qwe.13 for ; Thu, 28 Oct 2010 05:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=kM/l8AEjmhelmQu15QgMip5TK6UY+HiKvc9qx3lXDPc=; b=f7jAGwOZkGPFoxHZoCRMSsza6dC69+Z7uEutyXPWGQS6VpzCGpmzKGsuiAeTLL88P0 kNmImo3LVJm2uY4u2Z1xD6OcCD2itvBaNYVjP7FG27MpXE0RJDs+BeTShrBXxKRSwejb Ua8SYpriSDBQFp+rMpWn2huHkWLJikuMaW4kw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=gQgFsxgxIcvmcL2D4dQ7t+Kp9nWdmxAmERT6Bn3E0FePeNUk2ia38z9ENfJRACoQ8m iv65AD5VwnAXFIs6nGMUabptTdlvbRf9T6RbUhRUSkJ1472tDBbNnLhWdYRM0+ggDDKF mtPudMtgA5LimwY2MA4fPNYYPRYy/E2ReG7nA= Received: by 10.224.191.129 with SMTP id dm1mr4629929qab.31.1288266631758; Thu, 28 Oct 2010 04:50:31 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Thu, 28 Oct 2010 04:49:51 -0700 (PDT) From: Ivan Voras Date: Thu, 28 Oct 2010 13:49:51 +0200 X-Google-Sender-Auth: EVLlA8M3IfGK7LHvYVjJKQwUI1k Message-ID: To: FreeBSD-Current , freebsd-fs , kris@pcbsd.org, Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Cc: Subject: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 28 Oct 2010 12:17:04 -0000 Hello, After a discussion in arch@, it looks like there are many developers interested in having fusefs in the tree but no VFS experts with the time to fix the remaining bugs and basically make it stable enough to commit to the base tree. Fusefs is the Linux-developed userland filesystem interface which is fairly popular in the wild, especially with the "sshfs" module which allows mounting of generic ssh/sftp directories in a very easy way. Among other filesystems developed for fuse there are some cluster file systems, some crypto file systems and helper file systems used by Gnome and such environments. The initial FreeBSD reimplementation of the kernel module (the userland utlities and libraries don't require complicated porting) was was developed in one of the very early Google Summer of Code projects (2005) and is now in a bit unusual situation: 1) it *is* popular, as reports about its breakage arrive pretty soon after it breaks (i.e. due to mainline kernel changes) 2) it is currently available as a port but it is practically unmaintained. The source code archive is from 2008 and the port contains a dozen patches to be applied to it to make it work on recent systems 3) it is also not exactly rock stable, though this has improved with the above patches; Currently, with sshfs, it is good enough to: - survive blogbench runs - survive fsx runs with arguments "-W -R -L", i.e. no mmaped operations, no file size altering / truncate operations There have been claims it also corrupts kernel memory. Basically, this is a call for help in working on fusefs. There are several developers and users willing to do testing and such but no available developers with their hands in the guts of VFS to squash the buried bugs. Fusefs might be especially relevant to desktop users and as such to PC-BSD developers, so I'm cc-ing Kris in case he has a comment. Is anyone interested? References: http://permalink.gmane.org/gmane.os.freebsd.architechture/13623 http://fuse.sourceforge.net/ http://fuse4bsd.creo.hu/ http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/fusefs-kmod/ http://old.nabble.com/forum/Search.jtp?forum=6572&local=y&query=fusefs http://old.nabble.com/forum/Search.jtp?forum=6610&local=y&query=fusefs From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 14:16:10 2010 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 7D811106566B; Thu, 28 Oct 2010 14:16:10 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id ABEC58FC08; Thu, 28 Oct 2010 14:16:09 +0000 (UTC) Received: by ewy28 with SMTP id 28so1046278ewy.13 for ; Thu, 28 Oct 2010 07:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=DyVPbGVWks5vtZP72aYNvnancL9RjH+TMSTeokne+gk=; b=uuudB8hECOTe0ocyVC5xnXiUk2v1Pas9t4zlxdxveD10/3oIX4Bv4PJF6WT2nJPaS/ gPX6T8K+2CN3izKkQQOhmw4MSSiJ1SGt3xtN6RqLT51SWg8+R7aP08ANca6q6vZs+G29 zk27MG9qiOmn9us/iMANh0nwsuVKW7rzB7q4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=btUQPgUXGzPFA0i48AOwnihPE63W75rETmHzje27eYnACKb8XVFI8vSUrwLcOllt5Z ZuCTuq8xyh9jjVAHDFUlbprnj5XCFPD02gUIsV9QhMhGGbNta/RXkknB5l3Ut2496b1j 9/TNHFgl1lbUDddsyYYVppondhbIYCivRVwGg= Received: by 10.14.29.14 with SMTP id h14mr729696eea.36.1288275367282; Thu, 28 Oct 2010 07:16:07 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id b52sm827222eei.7.2010.10.28.07.16.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 07:16:05 -0700 (PDT) Date: Thu, 28 Oct 2010 17:15:59 +0300 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20101028141559.GA2291@tops> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs , FreeBSD-Current , kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 28 Oct 2010 14:16:10 -0000 On (28/10/2010 13:49), Ivan Voras wrote: > Hello, > > After a discussion in arch@, it looks like there are many developers > interested in having fusefs in the tree but no VFS experts with the > time to fix the remaining bugs and basically make it stable enough to > commit to the base tree. > > Fusefs is the Linux-developed userland filesystem interface which is > fairly popular in the wild, especially with the "sshfs" module which > allows mounting of generic ssh/sftp directories in a very easy way. > Among other filesystems developed for fuse there are some cluster file > systems, some crypto file systems and helper file systems used by > Gnome and such environments. The initial FreeBSD reimplementation of > the kernel module (the userland utlities and libraries don't require > complicated porting) was was developed in one of the very early Google > Summer of Code projects (2005) and is now in a bit unusual situation: > > 1) it *is* popular, as reports about its breakage arrive pretty soon > after it breaks (i.e. due to mainline kernel changes) > > 2) it is currently available as a port but it is practically > unmaintained. The source code archive is from 2008 and the port > contains a dozen patches to be applied to it to make it work on recent > systems > > 3) it is also not exactly rock stable, though this has improved with > the above patches; > > Currently, with sshfs, it is good enough to: > > - survive blogbench runs > - survive fsx runs with arguments "-W -R -L", i.e. no mmaped > operations, no file size altering / truncate operations > > There have been claims it also corrupts kernel memory. > > Basically, this is a call for help in working on fusefs. There are > several developers and users willing to do testing and such but no > available developers with their hands in the guts of VFS to squash the > buried bugs. Fusefs might be especially relevant to desktop users and > as such to PC-BSD developers, so I'm cc-ing Kris in case he has a > comment. > > Is anyone interested? Hi Ivan, I didn't reply to thread on @current as it seemed to me that decision was to keep it as it is until someone steps in to maintain it. I'd agree that "sshfs" is most wanted feature, but fuse_sshfs implementation is broken at best. It doesn't even have notion on inode numbers. It returns all directory entries with d_file=0, the same way st_ino=0. To make it actually work (dirent's with d_file=0 considered empty placeholders by FreeBSD VFS and libc) librefuse fills it with arbitrary numbers. To make long story short stuff like 'cd ..' works for you only because your sh and/or filemanager keeps full path on its own. Lots of other things using VOP_VPTOCNP are also broken. In this particular case puffs_sshfs looks much more promising, although it's explicitly marked as incomplete and buggy. The same applies to vast majority of fuse filesystems. Ignoring it is probably the easiest way to solve the problem, but I'd expect future userlevel filesystem implementation to comply to our VFS. Absence of mmap support is a real show stopper. It's also broken in puffs, and doesn't pass fsx tests. (I've once started implementing it but lost interest in userlevel filesystems after digging deeper into it.) On the other hand adding it to fuse shouldn't be very hard, it's just a question of free time. To sum it up. My personal opinion is that we'd better go with puffs-style approach. Implement userspace-kernel protocol that is as much close to our VFS as possible, and implement proper wrapper like librefuse (which is ok, but looks more like sketch than ready to use library). What I don't like about puffs is that is basically ignores locking serializing request from kernel. I'd suggest we ask a person with skills in network filesystems: locking, caching and all related issues, and improve existing puffs infrastructure accordingly (that includes inode numbers problem I've mentioned before). NFS4 might have interesting ideas. Probably Rick Macklem could express his opinion on this regard. Besides as far as I know OpenAFS has user-kernel interface and implements filesystem at userspace. Sun or Apple have reimplemented fuse in their own, although initial version was based on FreeBSD fuse port. It might be worth checking before moving any further with fuse. > > References: > > http://permalink.gmane.org/gmane.os.freebsd.architechture/13623 > http://fuse.sourceforge.net/ > http://fuse4bsd.creo.hu/ > http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/fusefs-kmod/ > http://old.nabble.com/forum/Search.jtp?forum=6572&local=y&query=fusefs > http://old.nabble.com/forum/Search.jtp?forum=6610&local=y&query=fusefs From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 18:42:19 2010 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 73B5F106566B for ; Thu, 28 Oct 2010 18:42:19 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 441078FC0A for ; Thu, 28 Oct 2010 18:42:16 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id o9SH8h4X021048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Oct 2010 19:08:43 +0200 Received: from [192.168.100.171] (173.Red-83-63-160.staticIP.rima-tde.net [83.63.160.173]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o9SH8fNu027448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 19:08:42 +0200 Message-ID: <4CC9AE18.2090101@entel.upc.edu> Date: Thu, 28 Oct 2010 19:08:40 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Thunderbird/3.1.5 MIME-Version: 1.0 To: FreeBSD-Current References: In-Reply-To: X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Thu, 28 Oct 2010 19:08:43 +0200 (CEST) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs , kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 28 Oct 2010 18:42:19 -0000 Al 28/10/10 13:49, En/na Ivan Voras ha escrit: > 1) it *is* popular, as reports about its breakage arrive pretty soon > after it breaks (i.e. due to mainline kernel changes) > > 2) it is currently available as a port but it is practically > unmaintained. The source code archive is from 2008 and the port > contains a dozen patches to be applied to it to make it work on recent > systems > > 3) it is also not exactly rock stable, though this has improved with > the above patches; > > Currently, with sshfs, it is good enough to: > > - survive blogbench runs > - survive fsx runs with arguments "-W -R -L", i.e. no mmaped > operations, no file size altering / truncate operations > > There have been claims it also corrupts kernel memory. > > Basically, this is a call for help in working on fusefs. There are > several developers and users willing to do testing and such but no > available developers with their hands in the guts of VFS to squash the > buried bugs. Fusefs might be especially relevant to desktop users and > as such to PC-BSD developers, so I'm cc-ing Kris in case he has a > comment. > > Is anyone interested? > Hello, I don't know whether fusefs-{kmod|libs} is the best option or if it would be better to work with puffs (and friend). It is my understanding that puffs brings the librefuse library which was written to bring a compatibility layer, so any fs written for fuse could be used (with some additional work) with puffs (please, correct me if I'm wrong). I also know that puffs is not multithreaded and so that means any failure in any filesystem using puffs will mean a bottleneck for the whole system, not to mention the performance loss we may "achieve" (just kidding) when being used by different filesystems in user space. And it seems that puffs is closer to the kernel structures than current fusefs. So it is not an easy choice and I don't which one I would pick. Anyhow, I don't have the skills yet to write code, but I have the will to learn vfs internals and help finding bugs. Any option you take will be good for me. So you can count on me :) Best regards, Gustau From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 20:25:20 2010 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 354351065679; Thu, 28 Oct 2010 20:25:20 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C4DF28FC20; Thu, 28 Oct 2010 20:25:19 +0000 (UTC) Received: by qyk2 with SMTP id 2so1285442qyk.13 for ; Thu, 28 Oct 2010 13:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Bzkf3ARGBw6BQeK6ofKhtnm5vlXG+LEv8brH8ak7QZc=; b=nYol1W4pmK+8yLuaINDoiNVaVPK7KebeiHYOdenkO7B71CMviIBT1nuFWyrPmucj3P eHd0NgH5g61f761NJ3R1Flo7l55BHBexyn9IQ5R9szGlpqSjYdBXWBS0txOqkji+xoI5 k/+0V/TzPSvn2w1vSxNWDTXO117+/jhfBZr6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=SpgY+3qJ3xDvqT1VwbUWwUGPXmeAriGUK4UFZT7aO+SYp9Jlbytsy+ljkjSqcacCbb CZfUrOv7nQYbPEqUYSKzBNhCUZzKYJjTgdWFYIcUHNPlpKQulkaSESaAbjUNbZ4UTsH1 +SmNIfLFcZiWslETi9eQa1VG1Ogj3fhWhhQY8= Received: by 10.224.75.134 with SMTP id y6mr3971718qaj.265.1288297518892; Thu, 28 Oct 2010 13:25:18 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Thu, 28 Oct 2010 13:24:37 -0700 (PDT) In-Reply-To: <20101028141559.GA2291@tops> References: <20101028141559.GA2291@tops> From: Ivan Voras Date: Thu, 28 Oct 2010 22:24:37 +0200 X-Google-Sender-Auth: KSDnvwdJ0oSoXf9MJl0fnspCh9M Message-ID: To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs , FreeBSD-Current , kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 28 Oct 2010 20:25:20 -0000 On 28 October 2010 16:15, Gleb Kurtsou wrote: > I'd agree that "sshfs" is most wanted feature, but fuse_sshfs > implementation is broken at best. It doesn't even have notion on inode > numbers. It returns all directory entries with d_file=3D0, the same way > st_ino=3D0. To make it actually work (dirent's with d_file=3D0 considered > empty placeholders by FreeBSD VFS and libc) librefuse fills it with > arbitrary numbers. To make long story short stuff like 'cd ..' works for > you only because your sh and/or filemanager keeps full path on its own. > Lots of other things using VOP_VPTOCNP are also broken. In this > particular case puffs_sshfs looks much more promising, although it's > explicitly marked as incomplete and buggy. The same applies to vast > majority of fuse filesystems. Ignoring it is probably the easiest way to > solve the problem, but I'd expect future userlevel filesystem > implementation to comply to our VFS. For these fuse-sshfs problems, how many are the problem of sshfs (the userland code), the FUSE API (because it's designed for Linux) and the fuse4bsd kernel module (because it's unfinished and buggy)? > Absence of mmap support is a real show stopper. It's also broken in > puffs, and doesn't pass fsx tests. (I've once started implementing it > but lost interest in userlevel filesystems after digging deeper into > it.) On the other hand adding it to fuse shouldn't be very hard, it's > just a question of free time. > > To sum it up. My personal opinion is that we'd better go with > puffs-style approach. Implement userspace-kernel protocol that is as > much close to our VFS as possible, and implement proper wrapper like > librefuse (which is ok, but looks more like sketch than ready to use > library). =C2=A0What I don't like about puffs is that is basically ignore= s > locking serializing request from kernel. I'm trying to avoid dispersal of effort. Basically, I won't be convinced to support puffs until someone who knows (possibly you if you are up to it) demonstrates that the refuse API is stable enough and practically 100% compatible with FUSE - some of their file systems look fit for serious use and "99%" isn't very much when talking about OS stability. On the other hand, if a developer suddenly appears and says "I will make puffs+refuse work" I will support him completely and I will stop crusading for fuse because having puffs is better than nothing. :) From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 21:56:28 2010 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 753941065674; Thu, 28 Oct 2010 21:56:28 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D87A8FC16; Thu, 28 Oct 2010 21:56:28 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o9SLuRGT005238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Oct 2010 14:56:28 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 83C2E1CC45; Thu, 28 Oct 2010 14:56:27 -0700 (PDT) To: Ivan Voras In-reply-to: Your message of "Thu, 28 Oct 2010 22:24:37 +0200." Date: Thu, 28 Oct 2010 14:56:27 -0700 From: "Kevin Oberman" Message-Id: <20101028215627.83C2E1CC45@ptavv.es.net> Cc: freebsd-fs , FreeBSD-Current , kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 28 Oct 2010 21:56:28 -0000 > From: Ivan Voras > Date: Thu, 28 Oct 2010 22:24:37 +0200 > Sender: owner-freebsd-current@freebsd.org > > On 28 October 2010 16:15, Gleb Kurtsou wrote: > > > I'd agree that "sshfs" is most wanted feature, but fuse_sshfs > > implementation is broken at best. It doesn't even have notion on inode > > numbers. It returns all directory entries with d_file=0, the same way > > st_ino=0. To make it actually work (dirent's with d_file=0 considered > > empty placeholders by FreeBSD VFS and libc) librefuse fills it with > > arbitrary numbers. To make long story short stuff like 'cd ..' works for > > you only because your sh and/or filemanager keeps full path on its own. > > Lots of other things using VOP_VPTOCNP are also broken. In this > > particular case puffs_sshfs looks much more promising, although it's > > explicitly marked as incomplete and buggy. The same applies to vast > > majority of fuse filesystems. Ignoring it is probably the easiest way to > > solve the problem, but I'd expect future userlevel filesystem > > implementation to comply to our VFS. > > For these fuse-sshfs problems, how many are the problem of sshfs (the > userland code), the FUSE API (because it's designed for Linux) and the > fuse4bsd kernel module (because it's unfinished and buggy)? > > > Absence of mmap support is a real show stopper. It's also broken in > > puffs, and doesn't pass fsx tests. (I've once started implementing it > > but lost interest in userlevel filesystems after digging deeper into > > it.) On the other hand adding it to fuse shouldn't be very hard, it's > > just a question of free time. > > > > To sum it up. My personal opinion is that we'd better go with > > puffs-style approach. Implement userspace-kernel protocol that is as > > much close to our VFS as possible, and implement proper wrapper like > > librefuse (which is ok, but looks more like sketch than ready to use > > library).  What I don't like about puffs is that is basically ignores > > locking serializing request from kernel. > > I'm trying to avoid dispersal of effort. Basically, I won't be > convinced to support puffs until someone who knows (possibly you if > you are up to it) demonstrates that the refuse API is stable enough > and practically 100% compatible with FUSE - some of their file systems > look fit for serious use and "99%" isn't very much when talking about > OS stability. > > On the other hand, if a developer suddenly appears and says "I will > make puffs+refuse work" I will support him completely and I will stop > crusading for fuse because having puffs is better than nothing. :) While support for sshfs may be important, I find ntfs-3g more important and both of these pale when compared to the gvfs-fuse-daemon in Gnome. It's just than I doubt most Gnome users even realize that it's there. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 21:58:09 2010 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 19EC1106567A; Thu, 28 Oct 2010 21:58:09 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC7D8FC1A; Thu, 28 Oct 2010 21:58:07 +0000 (UTC) Received: by eyb7 with SMTP id 7so1520195eyb.13 for ; Thu, 28 Oct 2010 14:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=U6Mw2QYZt6m+eFE4LH7geEsxzVJg460qdYJFPWZ5sNw=; b=ptvgfGBMvPImxKgwo6pkZ9CAIBZBvQd+6K9mdSpSn7JnypYIXcYzYHk2VO5VZgU0kb BHcco2PaCxzlSqLaoBI1+vdsSWnHNeYtGnzEIGdPHe72f7jG9BbPaCmE9wK/8Y027V36 zdHu9147vw4aOHsEki+QEZTnQfG3NspF0d6Xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=QRHUyE0YLgQXkGxk7gcv3tj4sG4MWIOfQVVhYjGtAEyRQI7ghd9/WTRBX4fEEbKEtu HQiXcsnF6QaJgjAbpgZZeIFWZChHpbmtcu8HG6StLv9f4P7HeBsdxVi0DBsck6MwIhjc 5ed9EBb7alBVPDIiIXMbwJ6DlJuAZ3EPkP9wQ= Received: by 10.14.127.139 with SMTP id d11mr3780434eei.42.1288303087098; Thu, 28 Oct 2010 14:58:07 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id x54sm1168342eeh.23.2010.10.28.14.58.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 14:58:06 -0700 (PDT) Date: Fri, 29 Oct 2010 00:57:59 +0300 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20101028215759.GA6779@tops> References: <20101028141559.GA2291@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs , FreeBSD-Current , kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 28 Oct 2010 21:58:09 -0000 On (28/10/2010 22:24), Ivan Voras wrote: > On 28 October 2010 16:15, Gleb Kurtsou wrote: > > > I'd agree that "sshfs" is most wanted feature, but fuse_sshfs > > implementation is broken at best. It doesn't even have notion on inode > > numbers. It returns all directory entries with d_file=0, the same way > > st_ino=0. To make it actually work (dirent's with d_file=0 considered > > empty placeholders by FreeBSD VFS and libc) librefuse fills it with > > arbitrary numbers. To make long story short stuff like 'cd ..' works for > > you only because your sh and/or filemanager keeps full path on its own. > > Lots of other things using VOP_VPTOCNP are also broken. In this > > particular case puffs_sshfs looks much more promising, although it's > > explicitly marked as incomplete and buggy. The same applies to vast > > majority of fuse filesystems. Ignoring it is probably the easiest way to > > solve the problem, but I'd expect future userlevel filesystem > > implementation to comply to our VFS. > > For these fuse-sshfs problems, how many are the problem of sshfs (the > userland code), the FUSE API (because it's designed for Linux) and the > fuse4bsd kernel module (because it's unfinished and buggy)? These are sshfs problems, and the real problem is that user level filesystems are of much lower quality than kernel level. Writing good filesystems in userspace shouldn't be much easier than writing kernel one (not counting fancy language of choice and ntfs-3g-like use of binary drivers). All the kernel restrictions and requirements are still there nor puffs, nor fuse do black magic for you. > > Absence of mmap support is a real show stopper. It's also broken in > > puffs, and doesn't pass fsx tests. (I've once started implementing it > > but lost interest in userlevel filesystems after digging deeper into > > it.) On the other hand adding it to fuse shouldn't be very hard, it's > > just a question of free time. > > > > To sum it up. My personal opinion is that we'd better go with > > puffs-style approach. Implement userspace-kernel protocol that is as > > much close to our VFS as possible, and implement proper wrapper like > > librefuse (which is ok, but looks more like sketch than ready to use > > library).  What I don't like about puffs is that is basically ignores > > locking serializing request from kernel. > > I'm trying to avoid dispersal of effort. Basically, I won't be > convinced to support puffs until someone who knows (possibly you if > you are up to it) demonstrates that the refuse API is stable enough > and practically 100% compatible with FUSE - No-no, I'm not convincing you to choose puffs. It's too immature. I just like the approach. > some of their file systems > look fit for serious use and "99%" isn't very much when talking about > OS stability. That's why I'm so sceptical about fuse, puffs, and entire concept in general. Is fuse really that stable on linux? Do people use it on production servers? > On the other hand, if a developer suddenly appears and says "I will > make puffs+refuse work" I will support him completely and I will stop > crusading for fuse because having puffs is better than nothing. :) From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 22:19:42 2010 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 360F11065674; Thu, 28 Oct 2010 22:19:42 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C79278FC27; Thu, 28 Oct 2010 22:19:40 +0000 (UTC) Received: by qyk2 with SMTP id 2so1384398qyk.13 for ; Thu, 28 Oct 2010 15:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=l8CguAfySEUmyswq7/c0QtzBSvx1W2JZaQTlStSmpz0=; b=uMonlFHOiO8tKkfMfQ+Hp8aKx7rvyfbYCpKaD1tTu0M1xj+Yohy59cPrW42cwEf8HL ox4qS+Ct5obMBWHK8dSb7b6vCgUpFD9W0v7ZLO5szShGcU2IRSuAnVRDLkFVqht2F+sU YpEuqvsp58ahXnPG7FShq63l690c3qj05ZNS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=AbEeNLZbHCwOZEb66DYgXBpvG2yxBGjykthqK0WeU3pbcIL++202+YdaOGS1kjRGMp tp+yUyWcn0PSq2+Rf5xNXv8Lf3v9YAl+hmJvAGtEb3XTECvSpTYZ9umWpaALH5SI/vjb zwGNXbQ0S7iTF82pOuA/vCvPGGIahHlDyLRCk= Received: by 10.229.80.194 with SMTP id u2mr2370784qck.49.1288304379522; Thu, 28 Oct 2010 15:19:39 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Thu, 28 Oct 2010 15:18:58 -0700 (PDT) In-Reply-To: <20101028215759.GA6779@tops> References: <20101028141559.GA2291@tops> <20101028215759.GA6779@tops> From: Ivan Voras Date: Fri, 29 Oct 2010 00:18:58 +0200 X-Google-Sender-Auth: nSwenp_Z4y5ad7ijHHIf0oY2MJU Message-ID: To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs , FreeBSD-Current Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 28 Oct 2010 22:19:42 -0000 On 28 October 2010 23:57, Gleb Kurtsou wrote: > On (28/10/2010 22:24), Ivan Voras wrote: >> On 28 October 2010 16:15, Gleb Kurtsou wrote: >> >> > I'd agree that "sshfs" is most wanted feature, but fuse_sshfs >> > implementation is broken at best. It doesn't even have notion on inode >> > numbers. It returns all directory entries with d_file=0, the same way >> > st_ino=0. To make it actually work (dirent's with d_file=0 considered >> > empty placeholders by FreeBSD VFS and libc) librefuse fills it with >> > arbitrary numbers. To make long story short stuff like 'cd ..' works for >> > you only because your sh and/or filemanager keeps full path on its own. >> > Lots of other things using VOP_VPTOCNP are also broken. In this >> > particular case puffs_sshfs looks much more promising, although it's >> > explicitly marked as incomplete and buggy. The same applies to vast >> > majority of fuse filesystems. Ignoring it is probably the easiest way to >> > solve the problem, but I'd expect future userlevel filesystem >> > implementation to comply to our VFS. >> >> For these fuse-sshfs problems, how many are the problem of sshfs (the >> userland code), the FUSE API (because it's designed for Linux) and the >> fuse4bsd kernel module (because it's unfinished and buggy)? > > These are sshfs problems, and the real problem is that user level This is good news, since userland is easier to fix. > filesystems are of much lower quality than kernel level. Writing good I wouldn't be that harsh - surely it's just a matter of general code quality whether in userland or kernel; there are a lot more userland file systems because the barrier to entry is lower. > filesystems in userspace shouldn't be much easier than writing kernel > one (not counting fancy language of choice and ntfs-3g-like use of > binary drivers). All the kernel restrictions and requirements are still > there nor puffs, nor fuse do black magic for you. I mostly agree - but as such it is not an argument for or against either puffs or fusefs. > That's why I'm so sceptical about fuse, puffs, and entire concept in > general. Is fuse really that stable on linux? Do people use it on > production servers? Here's a random sample of user comments and activity indicators I've googled in a few minutes: http://www.gluster.org/gluster-users/ http://www.persistentfs.com/#comments http://code.google.com/p/encfs/updates/list http://sourceforge.net/apps/trac/gfarm/report/1 These are the type of file systems which interest me, there are certainly others. From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 23:10:23 2010 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 AAB201065670; Thu, 28 Oct 2010 23:10:23 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE948FC0C; Thu, 28 Oct 2010 23:10:23 +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 o9SNAN0H024657; Thu, 28 Oct 2010 23:10:23 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9SNAN0N024623; Thu, 28 Oct 2010 23:10:23 GMT (envelope-from arundel) Date: Thu, 28 Oct 2010 23:10:23 GMT Message-Id: <201010282310.o9SNAN0N024623@freefall.freebsd.org> To: rui@ruilopes.com, arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/57088: [cam] [patch] for a possible fd leak in libcam.c 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, 28 Oct 2010 23:10:23 -0000 Synopsis: [cam] [patch] for a possible fd leak in libcam.c State-Changed-From-To: suspended->open State-Changed-By: arundel State-Changed-When: Thu Oct 28 22:27:36 UTC 2010 State-Changed-Why: The fd leak was fixed in r158171. The possible buffer overruns however still exist. I'll submit a patch shortly (against HEAD), which will turn all sprintf(3) calls in connection with cam_errbuf to snprintf(3) calls. Although this might not be necessary in all cases, it should however improve overall robustness of camlib.c. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: arundel Responsible-Changed-When: Thu Oct 28 22:27:36 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=57088 From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 23:30:16 2010 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 2590F1065670 for ; Thu, 28 Oct 2010 23:30:16 +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 8FF9A8FC19 for ; Thu, 28 Oct 2010 23:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9SNUFTM043477 for ; Thu, 28 Oct 2010 23:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9SNUFis043474; Thu, 28 Oct 2010 23:30:15 GMT (envelope-from gnats) Date: Thu, 28 Oct 2010 23:30:15 GMT Message-Id: <201010282330.o9SNUFis043474@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Alexander Best Cc: Subject: Re: bin/57088: [cam] [patch] for a possible fd leak in libcam.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 23:30:16 -0000 The following reply was made to PR bin/57088; it has been noted by GNATS. From: Alexander Best To: bug-followup@freebsd.org Cc: Subject: Re: bin/57088: [cam] [patch] for a possible fd leak in libcam.c Date: Thu, 28 Oct 2010 23:12:23 +0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline this is the patch i was refering to in my previous note. cheers. alex -- a13x --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="camlib.c.diff" diff --git a/lib/libcam/camlib.c b/lib/libcam/camlib.c index 47ca384..ed2d31b 100644 --- a/lib/libcam/camlib.c +++ b/lib/libcam/camlib.c @@ -121,7 +121,8 @@ cam_get_device(const char *path, char *dev_name, int devnamelen, int *unit) if (path == NULL) { - sprintf(cam_errbuf, "%s: device pathname was NULL", func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: device pathname was NULL", func_name); return(-1); } @@ -143,7 +144,8 @@ cam_get_device(const char *path, char *dev_name, int devnamelen, int *unit) } if (*tmpstr == '\0') { - sprintf(cam_errbuf, "%s: no text after slash", func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: no text after slash", func_name); free(newpath); return(-1); } @@ -170,9 +172,9 @@ cam_get_device(const char *path, char *dev_name, int devnamelen, int *unit) * If we only have 1, we don't have a valid device name. */ if (strlen(tmpstr) < 2) { - sprintf(cam_errbuf, - "%s: must have both device name and unit number", - func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: must have both device name and unit number", + func_name); free(newpath); return(-1); } @@ -182,9 +184,9 @@ cam_get_device(const char *path, char *dev_name, int devnamelen, int *unit) * has probably given us all numbers. Point out the error. */ if (isdigit(*tmpstr)) { - sprintf(cam_errbuf, - "%s: device name cannot begin with a number", - func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: device name cannot begin with a number", + func_name); free(newpath); return(-1); } @@ -195,8 +197,8 @@ cam_get_device(const char *path, char *dev_name, int devnamelen, int *unit) * or he gave us a device name/number format we don't recognize. */ if (!isdigit(tmpstr[strlen(tmpstr) - 1])) { - sprintf(cam_errbuf, "%s: unable to find device unit number", - func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: unable to find device unit number", func_name); free(newpath); return(-1); } @@ -324,8 +326,9 @@ cam_open_btl(path_id_t path_id, target_id_t target_id, lun_id_t target_lun, PERIPH_MATCH_LUN | PERIPH_MATCH_NAME; if (ioctl(fd, CAMIOCOMMAND, &ccb) == -1) { - sprintf(cam_errbuf, "%s: CAMIOCOMMAND ioctl failed\n" - "%s: %s", func_name, func_name, strerror(errno)); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: CAMIOCOMMAND ioctl failed\n" + "%s: %s", func_name, func_name, strerror(errno)); goto btl_bailout; } @@ -335,23 +338,26 @@ cam_open_btl(path_id_t path_id, target_id_t target_id, lun_id_t target_lun, if ((ccb.ccb_h.status != CAM_REQ_CMP) || ((ccb.cdm.status != CAM_DEV_MATCH_LAST) && (ccb.cdm.status != CAM_DEV_MATCH_MORE))) { - sprintf(cam_errbuf, "%s: CAM error %#x, CDM error %d " - "returned from XPT_DEV_MATCH ccb", func_name, - ccb.ccb_h.status, ccb.cdm.status); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: CAM error %#x, CDM error %d " + "returned from XPT_DEV_MATCH ccb", func_name, + ccb.ccb_h.status, ccb.cdm.status); goto btl_bailout; } if (ccb.cdm.status == CAM_DEV_MATCH_MORE) { - sprintf(cam_errbuf, "%s: CDM reported more than one" - " passthrough device at %d:%d:%d!!\n", - func_name, path_id, target_id, target_lun); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: CDM reported more than one" + " passthrough device at %d:%d:%d!!\n", + func_name, path_id, target_id, target_lun); goto btl_bailout; } if (ccb.cdm.num_matches == 0) { - sprintf(cam_errbuf, "%s: no passthrough device found at" - " %d:%d:%d", func_name, path_id, target_id, - target_lun); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: no passthrough device found at" + " %d:%d:%d", func_name, path_id, target_id, + target_lun); goto btl_bailout; } @@ -372,8 +378,9 @@ cam_open_btl(path_id_t path_id, target_id_t target_id, lun_id_t target_lun, break; /* NOTREACHED */ } default: - sprintf(cam_errbuf, "%s: asked for a peripheral match, but" - " got a bus or device match", func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: asked for a peripheral match, but" + " got a bus or device match", func_name); goto btl_bailout; break; /* NOTREACHED */ } @@ -446,7 +453,7 @@ cam_lookup_pass(const char *dev_name, int unit, int flags, "your kernel\n%s: or %s%d doesn't exist", func_name, func_name, dev_name, unit); } - snprintf(cam_errbuf, sizeof(cam_errbuf), + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, "%s: CAMGETPASSTHRU ioctl failed\n" "%s: %s%s", func_name, func_name, strerror(errno), (errno == ENOENT) ? tmpstr : ""); @@ -464,8 +471,9 @@ cam_lookup_pass(const char *dev_name, int unit, int flags, * the device the user gave us. */ if (ccb.cgdl.status == CAM_GDEVLIST_ERROR) { - sprintf(cam_errbuf, "%s: device %s%d does not exist!", - func_name, dev_name, unit); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: device %s%d does not exist!", + func_name, dev_name, unit); return(NULL); } @@ -495,9 +503,10 @@ cam_real_open_device(const char *path, int flags, struct cam_device *device, if (device == NULL) { if ((device = (struct cam_device *)malloc( sizeof(struct cam_device))) == NULL) { - sprintf(cam_errbuf, "%s: device structure malloc" - " failed\n%s: %s", func_name, func_name, - strerror(errno)); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: device structure malloc" + " failed\n%s: %s", func_name, func_name, + strerror(errno)); return(NULL); } device->fd = -1; @@ -553,8 +562,9 @@ cam_real_open_device(const char *path, int flags, struct cam_device *device, * because we just opened it above. The only way this * ioctl can fail is if the ccb size is wrong. */ - sprintf(cam_errbuf, "%s: CAMGETPASSTHRU ioctl failed\n" - "%s: %s", func_name, func_name, strerror(errno)); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: CAMGETPASSTHRU ioctl failed\n" + "%s: %s", func_name, func_name, strerror(errno)); goto crod_bailout; } @@ -565,8 +575,8 @@ cam_real_open_device(const char *path, int flags, struct cam_device *device, * the device the user gave us. */ if (ccb.cgdl.status == CAM_GDEVLIST_ERROR) { - sprintf(cam_errbuf, "%s: passthrough device does not exist!", - func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: passthrough device does not exist!", func_name); goto crod_bailout; } @@ -579,8 +589,9 @@ cam_real_open_device(const char *path, int flags, struct cam_device *device, ccb.ccb_h.func_code = XPT_PATH_INQ; if (ioctl(fd, CAMIOCOMMAND, &ccb) == -1) { - sprintf(cam_errbuf, "%s: Path Inquiry CCB failed\n" - "%s: %s", func_name, func_name, strerror(errno)); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: Path Inquiry CCB failed\n" + "%s: %s", func_name, func_name, strerror(errno)); goto crod_bailout; } strlcpy(device->sim_name, ccb.cpi.dev_name, sizeof(device->sim_name)); @@ -593,8 +604,9 @@ cam_real_open_device(const char *path, int flags, struct cam_device *device, */ ccb.ccb_h.func_code = XPT_GDEV_TYPE; if (ioctl(fd, CAMIOCOMMAND, &ccb) == -1) { - sprintf(cam_errbuf, "%s: Get Device Type CCB failed\n" - "%s: %s", func_name, func_name, strerror(errno)); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: Get Device Type CCB failed\n" + "%s: %s", func_name, func_name, strerror(errno)); goto crod_bailout; } device->pd_type = SID_TYPE(&ccb.cgd.inq_data); @@ -616,8 +628,9 @@ cam_real_open_device(const char *path, int flags, struct cam_device *device, ccb.cts.type = CTS_TYPE_CURRENT_SETTINGS; if (ioctl(fd, CAMIOCOMMAND, &ccb) == -1) { - sprintf(cam_errbuf, "%s: Get Transfer Settings CCB failed\n" - "%s: %s", func_name, func_name, strerror(errno)); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: Get Transfer Settings CCB failed\n" + "%s: %s", func_name, func_name, strerror(errno)); goto crod_bailout; } if (ccb.cts.protocol == XPORT_SPI) { @@ -696,7 +709,8 @@ cam_device_dup(struct cam_device *device) struct cam_device *newdev; if (device == NULL) { - sprintf(cam_errbuf, "%s: device is NULL", func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: device is NULL", func_name); return(NULL); } @@ -721,14 +735,14 @@ cam_device_copy(struct cam_device *src, struct cam_device *dst) char *func_name = "cam_device_copy"; if (src == NULL) { - sprintf(cam_errbuf, "%s: source device struct was NULL", - func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: source device struct was NULL", func_name); return; } if (dst == NULL) { - sprintf(cam_errbuf, "%s: destination device struct was NULL", - func_name); + snprintf(cam_errbuf, CAM_ERRBUF_SIZE, + "%s: destination device struct was NULL", func_name); return; } --WIyZ46R2i8wDzkSu-- From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 01:28:38 2010 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 145181065673 for ; Fri, 29 Oct 2010 01:28:38 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id AD15F8FC08 for ; Fri, 29 Oct 2010 01:28:37 +0000 (UTC) X-AuditID: 12074423-b7bd0ae000000a00-16-4cca23444987 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id EF.47.02560.4432ACC4; Thu, 28 Oct 2010 21:28:36 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o9T1SaW0001601; Thu, 28 Oct 2010 21:28:36 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o9T1SYVt026597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Oct 2010 21:28:35 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o9T1SWaj003602; Thu, 28 Oct 2010 21:28:32 -0400 (EDT) Date: Thu, 28 Oct 2010 21:28:32 -0400 (EDT) From: Benjamin Kaduk To: Gleb Kurtsou In-Reply-To: <20101028141559.GA2291@tops> Message-ID: References: <20101028141559.GA2291@tops> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: freebsd-fs , FreeBSD-Current , kris@pcbsd.org Subject: Re: Fixing and importing the fusefs kernel module - any VFS-savvy takers? 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, 29 Oct 2010 01:28:38 -0000 On Thu, 28 Oct 2010, Gleb Kurtsou wrote: > Besides as far as I know OpenAFS has user-kernel interface and > implements filesystem at userspace. Sun or Apple have reimplemented fuse The filesystem portions of OpenAFS are implemented in-kernel. Userspace utilities are for manipulating and querying attributes that are not easily exposed through the VFS layer. -Ben Kaduk From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 08:17:27 2010 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 C6057106566B; Fri, 29 Oct 2010 08:17:27 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB5A8FC0A; Fri, 29 Oct 2010 08:17:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9T8HRB5024996; Fri, 29 Oct 2010 08:17:27 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9T8HRb2024988; Fri, 29 Oct 2010 08:17:27 GMT (envelope-from jh) Date: Fri, 29 Oct 2010 08:17:27 GMT Message-Id: <201010290817.o9T8HRb2024988@freefall.freebsd.org> To: dpk@dpk.net, jh@FreeBSD.org, freebsd-fs@FreeBSD.org, jh@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/84589: [2TB] 5.4-STABLE unresponsive during background fsck 2TB partition 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, 29 Oct 2010 08:17:27 -0000 Synopsis: [2TB] 5.4-STABLE unresponsive during background fsck 2TB partition State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Oct 29 08:15:25 UTC 2010 State-Changed-Why: Is this still a problem for you? r184934 might have improved the snapshot creation on large file systems. Responsible-Changed-From-To: freebsd-fs->jh Responsible-Changed-By: jh Responsible-Changed-When: Fri Oct 29 08:15:25 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=84589 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 08:19:11 2010 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 E331F1065672; Fri, 29 Oct 2010 08:19:11 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B8F538FC13; Fri, 29 Oct 2010 08:19: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 o9T8JBjC025781; Fri, 29 Oct 2010 08:19:11 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9T8JBPa025777; Fri, 29 Oct 2010 08:19:11 GMT (envelope-from jh) Date: Fri, 29 Oct 2010 08:19:11 GMT Message-Id: <201010290819.o9T8JBPa025777@freefall.freebsd.org> To: mshurst@engmail.uwaterloo.ca, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/85326: [smbfs] [panic] saving a file via samba to an overquota account crashes system 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, 29 Oct 2010 08:19:12 -0000 Synopsis: [smbfs] [panic] saving a file via samba to an overquota account crashes system State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Fri Oct 29 08:19:11 UTC 2010 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=85326 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 08:29:25 2010 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 5D6EE1065674; Fri, 29 Oct 2010 08:29:25 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 337C88FC18; Fri, 29 Oct 2010 08:29:25 +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 o9T8TPBX036301; Fri, 29 Oct 2010 08:29:25 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9T8TORR036297; Fri, 29 Oct 2010 08:29:24 GMT (envelope-from jh) Date: Fri, 29 Oct 2010 08:29:24 GMT Message-Id: <201010290829.o9T8TORR036297@freefall.freebsd.org> To: sime@logos.hr, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/91568: [ufs] [panic] writing to UFS/softupdates DVD media in DVD-ROM drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 08:29:25 -0000 Synopsis: [ufs] [panic] writing to UFS/softupdates DVD media in DVD-ROM drive State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Oct 29 08:29:24 UTC 2010 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=91568 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 09:47:38 2010 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 E2D55106564A; Fri, 29 Oct 2010 09:47:38 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 984148FC0A; Fri, 29 Oct 2010 09:47:38 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBksW-0008qe-FF; Fri, 29 Oct 2010 13:04:04 +0400 Date: Fri, 29 Oct 2010 13:04:17 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101029090417.GA17537@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 29 Oct 2010 09:47:39 -0000 On Thu, Oct 28, 2010 at 09:57:22AM +0400, Alexander Zagrebin wrote: > Hi! > > I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. > When accessing a file at first time the transfer speed is too low, but > on following attempts the transfer speed is normal. ... > I've tried ftpd and nginx with "sendfile on". The behavior is the same. > After disabling using sendfile in nginx ("sendfile off") the problem has > gone. Yep, this problem exists. You may workaround it via bumping up net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm only one page (4K). I.e. if you have a file with size 512K, sendfile make calls freebsd_zfs_read 128 times. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 12:35:05 2010 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 C3F571065673; Fri, 29 Oct 2010 12:35:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DD3298FC1D; Fri, 29 Oct 2010 12:35:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA04851; Fri, 29 Oct 2010 15:35:00 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCABF73.8070707@icyb.net.ua> Date: Fri, 29 Oct 2010 15:34:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alexander Zagrebin References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> In-Reply-To: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 29 Oct 2010 12:35:05 -0000 on 28/10/2010 08:57 Alexander Zagrebin said the following: > Hi! > > I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. Which svn revision, just in case? > When accessing a file at first time the transfer speed is too low, but > on following attempts the transfer speed is normal. > > How to repeat: > > $ dd if=/dev/random of=/tmp/test bs=1m count=100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) > $ sudo env LC_ALL=C /usr/libexec/ftpd -D > > The first attempt to fetch file: > > $ fetch -o /dev/null ftp://localhost/tmp/test > /dev/null 1% of 100 MB 118 kBps > 14m07s^C > fetch: transfer interrupted > > The transfer rate is too low (approx. 120 kBps), but any subsequent attempts > are success: > > $ fetch -o /dev/null ftp://localhost/tmp/test > /dev/null 100% of 100 MB 42 MBps > $ fetch -o /dev/null ftp://localhost/tmp/test > /dev/null 100% of 100 MB 47 MBps Can you do an experiment with the same structure but sendfile excluded? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 12:36:28 2010 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 AAD58106567A; Fri, 29 Oct 2010 12:36:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A8AF18FC08; Fri, 29 Oct 2010 12:36:27 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA04897; Fri, 29 Oct 2010 15:36:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCABFC2.3040701@icyb.net.ua> Date: Fri, 29 Oct 2010 15:36:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> In-Reply-To: <20101029090417.GA17537@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 29 Oct 2010 12:36:28 -0000 on 29/10/2010 12:04 Artemiev Igor said the following: > Yep, this problem exists. You may workaround it via bumping up > net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have > made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm > only one page (4K). I.e. if you have a file with size 512K, sendfile make > calls freebsd_zfs_read 128 times. What svn revision of FreeBSD source tree did you test? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 12:53:41 2010 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 5EFD0106564A for ; Fri, 29 Oct 2010 12:53:41 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from srv3.ultra-secure.de (mail.ultra-secure.de [62.146.9.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9C06D8FC0C for ; Fri, 29 Oct 2010 12:53:40 +0000 (UTC) Received: (qmail 6186 invoked by uid 80); 29 Oct 2010 12:26:58 -0000 Received: from 212.71.117.70 (SquirrelMail authenticated user rainer@ultra-secure.de) by webmail.ultra-secure.de with HTTP; Fri, 29 Oct 2010 14:26:58 +0200 Message-ID: Date: Fri, 29 Oct 2010 14:26:58 +0200 From: rainer@ultra-secure.de To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 12:53:41 -0000 Hi, is it possible to somehow get all the MFCs for ZFS-stuff that went into STABLE to compile in RELENG_8_1? I tried (as suggested by someone) to just copy over the cddl-src-tree, but that did not work: In file included from /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:50: /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/misc.h:51: error: conflicting types for 'utsname' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:522: error: previous declaration of 'utsname' was here In file included from /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:51: /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h:467: error: expected declaration specifiers or '...' before 'zfs_userquota_prop_t' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:60: error: expected declaration specifiers or '...' before 'zfs_userquota_prop_t' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: In function 'zfs_valid_proplist': /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:829: error: 'zfs_userquota_prop_t' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:829: error: (Each undeclared identifier is reported only once /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:829: error: for each function it appears in.) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:829: error: expected ';' before 'uqtype' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:836: error: 'uqtype' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:836: warning: passing argument 4 of 'userquota_propname_decode' makes integer from pointer without a cast /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:836: warning: passing argument 5 of 'userquota_propname_decode' makes pointer from integer without a cast /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:836: error: too many arguments to function 'userquota_propname_decode' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:845: error: 'ZFS_PROP_USERQUOTA' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:846: error: 'ZFS_PROP_GROUPQUOTA' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:882: error: 'zfs_userquota_prop_prefixes' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: At top level: /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2103: error: expected declaration specifiers or '...' before 'zfs_userquota_prop_t' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: In function 'userquota_propname_decode': /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2105: error: 'zfs_userquota_prop_t' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2105: error: expected ';' before 'type' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2113: error: 'type' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2113: error: 'ZFS_NUM_USERQUOTA_PROPS' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2114: error: 'zfs_userquota_prop_prefixes' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2120: error: 'typep' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2122: error: 'ZFS_PROP_USERQUOTA' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2123: error: 'ZFS_PROP_USERUSED' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: At top level: /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2226: error: expected declaration specifiers or '...' before 'zfs_userquota_prop_t' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: In function 'zfs_prop_get_userquota_common': /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2235: error: 'typep' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2235: warning: passing argument 4 of 'userquota_propname_decode' makes integer from pointer without a cast /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2235: warning: passing argument 5 of 'userquota_propname_decode' makes pointer from integer without a cast /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2235: error: too many arguments to function 'userquota_propname_decode' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2240: error: 'ZFS_IOC_USERSPACE_ONE' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: In function 'zfs_prop_get_userquota_int': /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2252: error: 'zfs_userquota_prop_t' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2252: error: expected ';' before 'type' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2255: error: 'type' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2255: error: too many arguments to function 'zfs_prop_get_userquota_common' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: In function 'zfs_prop_get_userquota': /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2264: error: 'zfs_userquota_prop_t' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2264: error: expected ';' before 'type' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2267: error: 'type' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2267: error: too many arguments to function 'zfs_prop_get_userquota_common' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2275: error: 'ZFS_PROP_USERQUOTA' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:2275: error: 'ZFS_PROP_GROUPQUOTA' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: At top level: /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4141: error: expected declaration specifiers or '...' before 'zfs_userquota_prop_t' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c: In function 'zfs_userspace': /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4146: error: 'zfs_useracct_t' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4146: error: expected ';' before 'buf' /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4150: error: 'type' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4151: error: 'buf' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4155: error: 'zua' undeclared (first use in this function) /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4158: error: 'ZFS_IOC_USERSPACE_MANY' undeclared (first use in this function) *** Error code 1 Does that actually make sense? Or should we just upgrade to STABLE and live with the problems? ;-) Best Regards, Rainer From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 13:20:15 2010 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 6A0221065693 for ; Fri, 29 Oct 2010 13:20:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 958848FC0A for ; Fri, 29 Oct 2010 13:20:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA05655; Fri, 29 Oct 2010 16:19:59 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCAC9FF.5020207@icyb.net.ua> Date: Fri, 29 Oct 2010 16:19:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: rainer@ultra-secure.de References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:20:15 -0000 on 29/10/2010 15:26 rainer@ultra-secure.de said the following: > Does that actually make sense? > Or should we just upgrade to STABLE and live with the problems? > ;-) What problems? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 13:44:09 2010 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 407AA106566B for ; Fri, 29 Oct 2010 13:44:09 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from srv3.ultra-secure.de (mail.ultra-secure.de [62.146.9.10]) by mx1.freebsd.org (Postfix) with ESMTP id 80B348FC12 for ; Fri, 29 Oct 2010 13:44:08 +0000 (UTC) Received: (qmail 66045 invoked by uid 80); 29 Oct 2010 13:44:07 -0000 Received: from 212.71.117.70 (SquirrelMail authenticated user rainer@ultra-secure.de) by webmail.ultra-secure.de with HTTP; Fri, 29 Oct 2010 15:44:07 +0200 Message-ID: In-Reply-To: <4CCAC9FF.5020207@icyb.net.ua> References: <4CCAC9FF.5020207@icyb.net.ua> Date: Fri, 29 Oct 2010 15:44:07 +0200 From: rainer@ultra-secure.de To: "Andriy Gapon" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-fs@freebsd.org Subject: Re: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:44:09 -0000 > on 29/10/2010 15:26 rainer@ultra-secure.de said the following: >> Does that actually make sense? >> Or should we just upgrade to STABLE and live with the problems? >> ;-) > > What problems? > > -- > Andriy Gapon > I don't know. If all was good, we wouldn't have to wait until January for RELEASE, right? ;-) Seriously, though, we have a policy to only install a release if it's called RELEASE. Rainer From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 13:48:36 2010 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 3645A1065670 for ; Fri, 29 Oct 2010 13:48:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 806B48FC12 for ; Fri, 29 Oct 2010 13:48:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA06139; Fri, 29 Oct 2010 16:48:31 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCAD0AF.8080707@icyb.net.ua> Date: Fri, 29 Oct 2010 16:48:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: rainer@ultra-secure.de References: <4CCAC9FF.5020207@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:48:36 -0000 on 29/10/2010 16:44 rainer@ultra-secure.de said the following: >> on 29/10/2010 15:26 rainer@ultra-secure.de said the following: >>> Does that actually make sense? >>> Or should we just upgrade to STABLE and live with the problems? >>> ;-) >> >> What problems? > > I don't know. > If all was good, we wouldn't have to wait until January for RELEASE, right? > ;-) Releases are produced based on time policy (e.g. every half a year), we are not waiting for anything in particular. > Seriously, though, we have a policy to only install a release if it's > called RELEASE. Even if you seriously mangle half a source tree by hand? - This is in regard to your original question. IMO, stable branch is the best release. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 14:24:16 2010 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 08604106566C for ; Fri, 29 Oct 2010 14:24:16 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id C2C678FC16 for ; Fri, 29 Oct 2010 14:24:15 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 19F31B175F for ; Fri, 29 Oct 2010 16:24:13 +0200 (CEST) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2010 16:24:08 +0200 Message-Id: <64465C89-C68B-4436-8937-0D1D49F49BEA@lassitu.de> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: zfs destroy: cannot destroy 'foo': dataset already exists 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, 29 Oct 2010 14:24:16 -0000 I just came across an issue which appears to (have been) be triggered by = a bug: When trying to incrementally push snapshots with zfs send/recv, I = encountered a snapshot on the target fs which zfs recv complained about. = I was unable to remove the snapshot with zfs destroy. Also, trying to = recursively destroying the whole fs failed: zfs send | zfs recv error: cannot restore to tank/jail/gilb.zs64.net@201010130334: destination = already exists # zfs destroy tank/jail/gilb.zs64.net@201010130034 cannot destroy 'tank/jail/gilb.zs64.net@201010130034': dataset already = exists # zfs destroy -r tank/jail/gilb.zs64.net cannot destroy 'tank/jail/gilb.zs64.net@201010130034': dataset already = exists I came across this post, which helped me recover: http://www.openg.info/entry/destroy-zfs-snapshot-dataset-exists # zdb -d tank | grep % Dataset tank/jail/gilb.zs64.net/%201010130334 [ZPL], ID 5218, cr_txg = 3560162, 8.60G, 323647 objects # zfs destroy tank/jail/gilb.zs64.net/%201010130334 cannot open 'tank/jail/gilb.zs64.net/%201010130334': dataset does not = exist # zfs destroy -r tank/jail/gilb.zs64.net # The post references a Solaris bug CR 6860996. I could not immediately = determine whether this has been ported yet. This is on 8-stable from sept. 21. # zpool status pool: tank state: ONLINE status: The pool is formatted using an older on-disk format. The pool = can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ad4s1d ONLINE 0 0 0 errors: No known data errors Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 14:36:41 2010 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 EC7C11065672 for ; Fri, 29 Oct 2010 14:36:41 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from srv3.ultra-secure.de (mail.ultra-secure.de [62.146.9.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3962A8FC14 for ; Fri, 29 Oct 2010 14:36:40 +0000 (UTC) Received: (qmail 7031 invoked by uid 80); 29 Oct 2010 14:36:40 -0000 Received: from 212.71.117.70 (SquirrelMail authenticated user rainer@ultra-secure.de) by webmail.ultra-secure.de with HTTP; Fri, 29 Oct 2010 16:36:40 +0200 Message-ID: <1b1fd7c51699466c5acaf68516d01c6e.squirrel@webmail.ultra-secure.de> In-Reply-To: <4CCAD0AF.8080707@icyb.net.ua> References: <4CCAC9FF.5020207@icyb.net.ua> <4CCAD0AF.8080707@icyb.net.ua> Date: Fri, 29 Oct 2010 16:36:40 +0200 From: rainer@ultra-secure.de To: "Andriy Gapon" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-fs@freebsd.org Subject: Re: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:36:42 -0000 > on 29/10/2010 16:44 rainer@ultra-secure.de said the following: >>> on 29/10/2010 15:26 rainer@ultra-secure.de said the following: >>>> Does that actually make sense? >>>> Or should we just upgrade to STABLE and live with the problems? >>>> ;-) >>> >>> What problems? >> >> I don't know. >> If all was good, we wouldn't have to wait until January for RELEASE, >> right? >> ;-) > > Releases are produced based on time policy (e.g. every half a year), we > are not > waiting for anything in particular. Good to hear. >> Seriously, though, we have a policy to only install a release if it's >> called RELEASE. > > Even if you seriously mangle half a source tree by hand? - This is in > regard to > your original question. Yes, this concern is valid. > IMO, stable branch is the best release. Thanks for your input. Best Regards, Rainer From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 14:42:05 2010 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 6EF76106566B; Fri, 29 Oct 2010 14:42:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 871C98FC08; Fri, 29 Oct 2010 14:42:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA07090; Fri, 29 Oct 2010 17:41:59 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCADD37.7000306@icyb.net.ua> Date: Fri, 29 Oct 2010 17:41:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> In-Reply-To: <4CCABFC2.3040701@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 29 Oct 2010 14:42:05 -0000 on 29/10/2010 15:36 Andriy Gapon said the following: > on 29/10/2010 12:04 Artemiev Igor said the following: >> Yep, this problem exists. You may workaround it via bumping up >> net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have >> made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm >> only one page (4K). I.e. if you have a file with size 512K, sendfile make >> calls freebsd_zfs_read 128 times. > > What svn revision of FreeBSD source tree did you test? > Ah, I think I see what's going on. Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. Currently ZFS would read a whole FS block into ARC, but populate only one page with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from ARC data. So, e.g. zpool iostat would show that there are only few actual reads from a pool. The rest of the time must be spent churning over the data already in ARC and doing page-per-VOP_READ copies from it. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 15:25:51 2010 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 C0E01106566B; Fri, 29 Oct 2010 15:25:51 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 75C858FC0C; Fri, 29 Oct 2010 15:25:51 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBqpx-000FAn-TK; Fri, 29 Oct 2010 19:25:50 +0400 Date: Fri, 29 Oct 2010 19:26:02 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101029152602.GA18613@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCADD37.7000306@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 29 Oct 2010 15:25:51 -0000 On Fri, Oct 29, 2010 at 05:41:59PM +0300, Andriy Gapon wrote: > What svn revision of FreeBSD source tree did you test? r213936. Revision seems a little old. > Ah, I think I see what's going on. > Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS > mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. > Currently ZFS would read a whole FS block into ARC, but populate only one page > with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from > ARC data. > So, e.g. zpool iostat would show that there are only few actual reads from a pool. > The rest of the time must be spent churning over the data already in ARC and > doing page-per-VOP_READ copies from it. I can test it, but what allocflags? VM_ALLOC_RETRY|VM_ALLOC_NORMAL? From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 15:57:08 2010 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 1CF861065672 for ; Fri, 29 Oct 2010 15:57:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9054A8FC12 for ; Fri, 29 Oct 2010 15:57:07 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9TFuojM069943; Fri, 29 Oct 2010 17:57:06 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9TFuo15069942; Fri, 29 Oct 2010 17:56:50 +0200 (CEST) (envelope-from olli) Date: Fri, 29 Oct 2010 17:56:50 +0200 (CEST) Message-Id: <201010291556.o9TFuo15069942@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, rainer@ultra-secure.de In-Reply-To: X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Fri, 29 Oct 2010 17:57:06 +0200 (CEST) Cc: Subject: Re: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, rainer@ultra-secure.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:57:08 -0000 rainer@ultra-secure.de wrote: > is it possible to somehow get all the MFCs for ZFS-stuff that went into > STABLE to compile in RELENG_8_1? > I tried (as suggested by someone) to just copy over the cddl-src-tree, but > that did not work: > > [142 lines of error messages] RELENG_8 (a.k.a. 8/stable) will most certainly be more stable than trying to cross-breed major parts of the source tree from different branches. Best regards Oliver (who never used a "-RELEASE" in ~ 15 years of FreeBSD, except for testing purposes or for inital installs from CD/DVD which where then updated to -stable promptly.) -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 16:06:11 2010 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 78325106564A; Fri, 29 Oct 2010 16:06:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 973988FC1B; Fri, 29 Oct 2010 16:06:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07885; Fri, 29 Oct 2010 19:06:03 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCAF0EB.4080001@icyb.net.ua> Date: Fri, 29 Oct 2010 19:06:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> In-Reply-To: <20101029152602.GA18613@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 29 Oct 2010 16:06:11 -0000 on 29/10/2010 18:26 Artemiev Igor said the following: > On Fri, Oct 29, 2010 at 05:41:59PM +0300, Andriy Gapon wrote: > >> What svn revision of FreeBSD source tree did you test? > > r213936. Revision seems a little old. > >> Ah, I think I see what's going on. >> Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS >> mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. >> Currently ZFS would read a whole FS block into ARC, but populate only one page >> with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from >> ARC data. >> So, e.g. zpool iostat would show that there are only few actual reads from a pool. >> The rest of the time must be spent churning over the data already in ARC and >> doing page-per-VOP_READ copies from it. > I can test it, but what allocflags? VM_ALLOC_RETRY|VM_ALLOC_NORMAL? Probably yes, but have to be careful there. First, do vm_page_grab only for UIO_NOCOPY case. Second, the first page is already "shared busy" after vm_page_io_start() call in kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a deadlock. I think that it may be good to separate UIO_NOCOPY/sendfile case from mappedread into a function of its own. P.S. doing VOP_GETPAGES instead of vn_rdwr() in kern_sendfile() might be a better idea still. But there are some additional details to that, e.g. a mount/fs flag to tell which mechanism is preferred. Because, as I've been told, vn_rdwr() has better performance than VOP_GETPAGES. Although, I don't understand why it could/should be that way. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 16:17:07 2010 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 ACF08106566C for ; Fri, 29 Oct 2010 16:17:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 583CC8FC08 for ; Fri, 29 Oct 2010 16:17:06 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id QgGf1f0030vyq2s53gH7zN; Fri, 29 Oct 2010 16:17:07 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta05.westchester.pa.mail.comcast.net with comcast id QgH61f0083LrwQ23RgH6Gp; Fri, 29 Oct 2010 16:17:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F00B09B422; Fri, 29 Oct 2010 09:17:04 -0700 (PDT) Date: Fri, 29 Oct 2010 09:17:04 -0700 From: Jeremy Chadwick To: freebsd-fs@FreeBSD.ORG, rainer@ultra-secure.de Message-ID: <20101029161704.GA81450@icarus.home.lan> References: <201010291556.o9TFuo15069942@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010291556.o9TFuo15069942@lurza.secnetix.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:17:07 -0000 On Fri, Oct 29, 2010 at 05:56:50PM +0200, Oliver Fromme wrote: > rainer@ultra-secure.de wrote: > > is it possible to somehow get all the MFCs for ZFS-stuff that went into > > STABLE to compile in RELENG_8_1? > > I tried (as suggested by someone) to just copy over the cddl-src-tree, but > > that did not work: > > > > [142 lines of error messages] > > RELENG_8 (a.k.a. 8/stable) will most certainly be more stable > than trying to cross-breed major parts of the source tree from > different branches. > > Best regards > Oliver > (who never used a "-RELEASE" in ~ 15 years of FreeBSD, except > for testing purposes or for inital installs from CD/DVD which > where then updated to -stable promptly.) It might not be worth much, but my opinions follow that of Oliver and Andriy. We haven't run -RELEASE branches on any of our production servers since the early 4.x days, nor have I run such at home. I do the exact same thing as Oliver. I recently described the reasoning to someone on a forum who asked for my advice as to whether or not he should follow/use RELENG_8, in anticipation of RELENG_8_2 (8.2-RELEASE), with his main focus being ZFS. I always assume users want overall stability/reliability *in addition* to support for bugs they encounter -- and you will encounter them. Here's a snippet of what I wrote: = The most common response on freebsd-stable to someone running -RELEASE = is "can you please try RELENG_8 instead?" The RELENG_x_y branches I've = never followed because the instant you encounter a bug you have to wait = until the next -RELEASE to experience the fix; the only things = backported are major (as in widespread) kernel panics or security = issues. Years of experience has shown me that 90% of the time a "bug" = is going to be something less severe than those two, but still severe = enough to cause major anxiety ("How the heck am I going to fix this? = Can I work around it? Oh god, rolling back to 7.x?!") and make you = wonder what you're going to do about it (feeling of helplessness, = etc.). Just follow the -STABLE branch and watch commits and/or = follow the mailing lists. The last half of the above should (hopefully) hit home. You should run whatever branch (or OS for that matter!) works best for you and your situation, but I get better overall support (both from developers and the community) running RELENG_x and not -RELEASE. "But isn't -STABLE 'riskier' than -RELEASE?" Yes. But nothing forces you to update your src tree. If you do csup one day, rebuild world/kernel, and find you're encountering a problem, it's painless to roll back to a previous date with csup: look at the "date=" option which you can use in your supfiles. I've had to use this quite a few times over the years. Of course, I csup once a day, sometimes more than that. I also follow commits as best as I can. I'm a bit more OCD than your average system administrator -- but that comes from past experiences where being lax and expecting a server to "manage itself" (turn it on, don't touch it for 7 million days, e.g. negligence) resulted in Bad Things(tm). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 17:50:55 2010 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 68DC61065670; Fri, 29 Oct 2010 17:50:55 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 12BB78FC0A; Fri, 29 Oct 2010 17:50:54 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBt6L-000HYZ-O5; Fri, 29 Oct 2010 21:50:53 +0400 Date: Fri, 29 Oct 2010 21:51:05 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101029175105.GB18613@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCAF0EB.4080001@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 29 Oct 2010 17:50:55 -0000 On Fri, Oct 29, 2010 at 07:06:03PM +0300, Andriy Gapon wrote: > Probably yes, but have to be careful there. > First, do vm_page_grab only for UIO_NOCOPY case. > Second, the first page is already "shared busy" after vm_page_io_start() call in > kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a deadlock. RELENG_8 doesn`t have VM_ALLOC_IGN_SBUSY, it appeared only in HEAD. Can you review this patch, Whether correctly I have understood? (didnt test it yet) --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2010-10-29 18:18:23.921078337 +0200 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-10-29 19:23:48.142513084 +0200 @@ -449,7 +449,7 @@ int bytes = MIN(PAGESIZE - off, len); again: - if ((m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && + if (uio->uio_segflg != UIO_NOCOPY && (m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && vm_page_is_valid(m, off, bytes)) { if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; @@ -464,7 +464,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -472,11 +472,9 @@ * but it pessimize performance of sendfile/UFS, that's * why I handle this special case in ZFS code. */ - KASSERT(off == 0, - ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) - goto again; - vm_page_busy(m); + if((m = vm_page_lookup(obj, OFF_TO_IDX(start))) == NULL || !vm_page_is_valid(m, off, bytes)) + m = vm_page_grab(obj, OFF_TO_IDX(start), VM_ALLOC_NORMAL|VM_ALLOC_RETRY); + VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 18:44:33 2010 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 A4F8D106566B for ; Fri, 29 Oct 2010 18:44:33 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 652768FC20 for ; Fri, 29 Oct 2010 18:44:33 +0000 (UTC) Received: by yxl31 with SMTP id 31so2330223yxl.13 for ; Fri, 29 Oct 2010 11:44:32 -0700 (PDT) Received: by 10.42.155.67 with SMTP id t3mr2549639icw.438.1288376305490; Fri, 29 Oct 2010 11:18:25 -0700 (PDT) Received: from wawanesa.iciti.ca (CPE0080c8f208a5-CM001371173cf8.cpe.net.cable.rogers.com [99.246.61.82]) by mx.google.com with ESMTPS id gy41sm3940636ibb.11.2010.10.29.11.18.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 11:18:24 -0700 (PDT) Message-ID: <4CCB0FDF.3020206@bellanet.org> Date: Fri, 29 Oct 2010 14:18:07 -0400 From: Graham Todd User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100919 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <201010291556.o9TFuo15069942@lurza.secnetix.de> <20101029161704.GA81450@icarus.home.lan> In-Reply-To: <20101029161704.GA81450@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG Subject: Re: 8.1-RELEASE and cddl-sources from STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 18:44:33 -0000 On 10/29/10 12:17, Jeremy Chadwick wrote: > On Fri, Oct 29, 2010 at 05:56:50PM +0200, Oliver Fromme wrote: >> rainer@ultra-secure.de wrote: >> > is it possible to somehow get all the MFCs for ZFS-stuff that went into >> > STABLE to compile in RELENG_8_1? >> > I tried (as suggested by someone) to just copy over the cddl-src-tree, but >> > that did not work: >> > >> > [142 lines of error messages] >> >> RELENG_8 (a.k.a. 8/stable) will most certainly be more stable >> than trying to cross-breed major parts of the source tree from >> different branches. >> >> Best regards >> Oliver >> (who never used a "-RELEASE" in ~ 15 years of FreeBSD, except >> for testing purposes or for inital installs from CD/DVD which >> where then updated to -stable promptly.) > > It might not be worth much, but my opinions follow that of Oliver and > Andriy. We haven't run -RELEASE branches on any of our production > servers since the early 4.x days, nor have I run such at home. I do the > exact same thing as Oliver. > > I recently described the reasoning to someone on a forum who asked for > my advice as to whether or not he should follow/use RELENG_8, in > anticipation of RELENG_8_2 (8.2-RELEASE), with his main focus being ZFS. > I always assume users want overall stability/reliability *in addition* > to support for bugs they encounter -- and you will encounter them. > Here's a snippet of what I wrote: > > = The most common response on freebsd-stable to someone running -RELEASE > = is "can you please try RELENG_8 instead?" The RELENG_x_y branches I've > = never followed because the instant you encounter a bug you have to wait > = until the next -RELEASE to experience the fix; the only things > = backported are major (as in widespread) kernel panics or security > = issues. Years of experience has shown me that 90% of the time a "bug" > = is going to be something less severe than those two, but still severe > = enough to cause major anxiety ("How the heck am I going to fix this? > = Can I work around it? Oh god, rolling back to 7.x?!") and make you > = wonder what you're going to do about it (feeling of helplessness, > = etc.). Just follow the -STABLE branch and watch commits and/or > = follow the mailing lists. > > The last half of the above should (hopefully) hit home. > > You should run whatever branch (or OS for that matter!) works best for > you and your situation, but I get better overall support (both from > developers and the community) running RELENG_x and not -RELEASE. > > "But isn't -STABLE 'riskier' than -RELEASE?" Yes. But nothing forces > you to update your src tree. If you do csup one day, rebuild > world/kernel, and find you're encountering a problem, it's painless to > roll back to a previous date with csup: look at the "date=" option which > you can use in your supfiles. I've had to use this quite a few times > over the years. > > Of course, I csup once a day, sometimes more than that. I also follow > commits as best as I can. I'm a bit more OCD than your average system > administrator -- but that comes from past experiences where being lax > and expecting a server to "manage itself" (turn it on, don't touch it > for 7 million days, e.g. negligence) resulted in Bad Things(tm). Do your see a role for binary updates with freebsd-update (a binary RELEASE only tool)? Does the frequent csuping method and tracking commits to STABLE approach work well with the sorts of change management reporting requirements and "ITIL compliant" (ugh) policies sometimes imposed by faceless committees? Actually this is sort of OT and more of a general sysadmin question but I'm curious what other sysadmins do when they do their work. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 19:46:40 2010 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 0F1AF1065670; Fri, 29 Oct 2010 19:46:40 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D8A978FC08; Fri, 29 Oct 2010 19:46:39 +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 o9TJkdix020919; Fri, 29 Oct 2010 19:46:39 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9TJkdwT020915; Fri, 29 Oct 2010 19:46:39 GMT (envelope-from arundel) Date: Fri, 29 Oct 2010 19:46:39 GMT Message-Id: <201010291946.o9TJkdwT020915@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/57088: [cam] [patch] for a possible fd leak in libcam.c 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, 29 Oct 2010 19:46:40 -0000 Synopsis: [cam] [patch] for a possible fd leak in libcam.c Responsible-Changed-From-To: freebsd-fs->freebsd-scsi Responsible-Changed-By: arundel Responsible-Changed-When: Fri Oct 29 19:44:28 UTC 2010 Responsible-Changed-Why: Freebsd-scsi@ seems better suited for this PR than freebsd-fs@. Thanks to Jaakko Heinonen for pointing this out. ;) http://www.freebsd.org/cgi/query-pr.cgi?pr=57088 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 20:24:03 2010 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 2AE6C1065670 for ; Fri, 29 Oct 2010 20:24:03 +0000 (UTC) (envelope-from appdebgr@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC9C28FC15 for ; Fri, 29 Oct 2010 20:24:02 +0000 (UTC) Received: by qwg8 with SMTP id 8so1429602qwg.13 for ; Fri, 29 Oct 2010 13:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=PlT4GJjfxh//kdsAxPMdauLfHZNp3ConPAKk6ueY0N4=; b=aMuf7THh1bTff4wpgaSRTK8piTSmpRqZ5vh50wmnBwiduYoOwWpZ9iSS4go8Bn5nag R5r09M/Wzy4O2W+sE8Bw689YsGCNVORy0bsntFvbbN16hFRojyysC/2AtDgITzR/XPfv Eg5umcPoArT8bB1iNpE+J28RxVAG65jKbyolY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=I5NVup0/vIsO/ZoCTYED8RcMH1MQIDGM+wJNKU6A1+zL/mXft9htO2z2+Cu6uSZRNh eYfwcFTVj+5XWPx16V/8kdFMNPOWAlNTt3oc+jkreI6tf87QKJRb8tv8iCsh6U4mueMw upwYC5ers7qA35N9t3Bmvf+Rf9GN2f8bKXsU0= MIME-Version: 1.0 Received: by 10.229.224.79 with SMTP id in15mr7141488qcb.219.1288382018188; Fri, 29 Oct 2010 12:53:38 -0700 (PDT) Received: by 10.229.28.7 with HTTP; Fri, 29 Oct 2010 12:53:38 -0700 (PDT) Date: Fri, 29 Oct 2010 22:53:38 +0300 Message-ID: From: App Deb To: freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: How to run ZFS Test Suite (ztest)? 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, 29 Oct 2010 20:24:03 -0000 Attempting to run it on 8.1-R drops the error: %ztest Assertion failed: (abstime > 0), file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 309. Abort (core dumped) Thanks. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 29 22:35:10 2010 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 B4B8C106564A for ; Fri, 29 Oct 2010 22:35:10 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 23C6C8FC1A for ; Fri, 29 Oct 2010 22:35:09 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.4) with ESMTP id o9TMZ5o7090916 for ; Sat, 30 Oct 2010 01:35:05 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4CCB4C07.9070105@ukr.net> Date: Sat, 30 Oct 2010 01:34:47 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: How to run ZFS Test Suite (ztest)? 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, 29 Oct 2010 22:35:10 -0000 29.10.2010 22:53, App Deb пишет: > Attempting to run it on 8.1-R drops the error: > > %ztest > Assertion failed: (abstime > 0), file > /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, > line 309. > Abort (core dumped) > +1 # ztest -V -p tank 5 vdevs, 7 datasets, 23 threads, 300 seconds... Assertion failed: (abstime > 0), file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 311. Abort (core dumped) -- Vladislav V. Prodan VVP24-UANIC +38[067]4584408 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 07:53:44 2010 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 C60181065674; Sat, 30 Oct 2010 07:53:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D895C8FC18; Sat, 30 Oct 2010 07:53:43 +0000 (UTC) Received: from porto.topspin.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 KAA18202; Sat, 30 Oct 2010 10:53:38 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6Ft-000J3E-Kv; Sat, 30 Oct 2010 10:53:37 +0300 Message-ID: <4CCBCF00.2030904@icyb.net.ua> Date: Sat, 30 Oct 2010 10:53:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> In-Reply-To: <4CCADD37.7000306@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 07:53:45 -0000 on 29/10/2010 17:41 Andriy Gapon said the following: > on 29/10/2010 15:36 Andriy Gapon said the following: >> on 29/10/2010 12:04 Artemiev Igor said the following: >>> Yep, this problem exists. You may workaround it via bumping up >>> net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have >>> made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm >>> only one page (4K). I.e. if you have a file with size 512K, sendfile make >>> calls freebsd_zfs_read 128 times. >> >> What svn revision of FreeBSD source tree did you test? >> > > Ah, I think I see what's going on. > Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS > mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. > Currently ZFS would read a whole FS block into ARC, but populate only one page > with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from > ARC data. > So, e.g. zpool iostat would show that there are only few actual reads from a pool. > The rest of the time must be spent churning over the data already in ARC and > doing page-per-VOP_READ copies from it. Hmm, I investigated the issue some more and now I wouldn't put all the blame on ZFS. Indeed, perhaps ZFS is very inefficient here, perhaps it does extra looping and extra copying. However those operations should not lead to such a significant slowdown, but mostly to an increased CPU usage. So, it looks that sendfile spends most of the time in sbwait(). Of course, "erratic" behavior of ZFS does contribute to that. It's this code in kern_sendfile that gets triggered by ZFS: if (pg->valid && vm_page_is_valid(pg, pgoff, xfsize)) VM_OBJECT_UNLOCK(obj); else if (m != NULL) error = EAGAIN; /* send what we already got */ else ... Essentially, data is not only read from ZFS page by page, but it is also mostly sent with page-sized chunk at a time. P.S. just stating the obvious, kind of :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 08:16:10 2010 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 E41921065673; Sat, 30 Oct 2010 08:16:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EBDA98FC1F; Sat, 30 Oct 2010 08:16:08 +0000 (UTC) Received: from porto.topspin.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 LAA18380; Sat, 30 Oct 2010 11:16:04 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6bc-000J4e-Ad; Sat, 30 Oct 2010 11:16:04 +0300 Message-ID: <4CCBD443.7010305@icyb.net.ua> Date: Sat, 30 Oct 2010 11:16:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> In-Reply-To: <20101029175105.GB18613@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 08:16:10 -0000 on 29/10/2010 20:51 Artemiev Igor said the following: > On Fri, Oct 29, 2010 at 07:06:03PM +0300, Andriy Gapon wrote: >> Probably yes, but have to be careful there. >> First, do vm_page_grab only for UIO_NOCOPY case. >> Second, the first page is already "shared busy" after vm_page_io_start() call in >> kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a deadlock. > > RELENG_8 doesn`t have VM_ALLOC_IGN_SBUSY, it appeared only in HEAD. > Can you review this patch, Whether correctly I have understood? (didnt test it yet) > > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2010-10-29 18:18:23.921078337 +0200 > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-10-29 19:23:48.142513084 +0200 > @@ -449,7 +449,7 @@ > int bytes = MIN(PAGESIZE - off, len); > > again: > - if ((m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && > + if (uio->uio_segflg != UIO_NOCOPY && (m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && > vm_page_is_valid(m, off, bytes)) { > if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > @@ -464,7 +464,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -472,11 +472,9 @@ > * but it pessimize performance of sendfile/UFS, that's > * why I handle this special case in ZFS code. > */ > - KASSERT(off == 0, > - ("unexpected offset in mappedread for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > - goto again; > - vm_page_busy(m); > + if((m = vm_page_lookup(obj, OFF_TO_IDX(start))) == NULL || !vm_page_is_valid(m, off, bytes)) > + m = vm_page_grab(obj, OFF_TO_IDX(start), VM_ALLOC_NORMAL|VM_ALLOC_RETRY); > + > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { > error = dmu_read_uio(os, zp->z_id, uio, Or maybe something like the following? It looks a little bit cleaner to me, but still is not perfect, as I have not handled unnecessary busy-ing of the pages where something more lightweight could have sufficed (e.g. wiring and shared busying). Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -476,6 +477,16 @@ ("unexpected offset in mappedread for sendfile")); if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } vm_page_busy(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 08:16:51 2010 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 C2CAC1065674; Sat, 30 Oct 2010 08:16:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D57618FC19; Sat, 30 Oct 2010 08:16:50 +0000 (UTC) Received: from porto.topspin.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 LAA18390; Sat, 30 Oct 2010 11:16:47 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6cI-000J4l-TR; Sat, 30 Oct 2010 11:16:46 +0300 Message-ID: <4CCBD46E.9030200@icyb.net.ua> Date: Sat, 30 Oct 2010 11:16:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> In-Reply-To: <4CCBD443.7010305@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 08:16:51 -0000 on 30/10/2010 11:16 Andriy Gapon said the following: > Or maybe something like the following? > It looks a little bit cleaner to me, but still is not perfect, as I have not > handled unnecessary busy-ing of the pages where something more lightweight could > have sufficed (e.g. wiring and shared busying). Note: I have only compile tested the patch. > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =================================================================== > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -476,6 +477,16 @@ > ("unexpected offset in mappedread for sendfile")); > if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > + if (m == NULL) { > + m = vm_page_alloc(obj, OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); > + if (m == NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } > vm_page_busy(m); > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { > > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 08:25:11 2010 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 C6D5D1065670; Sat, 30 Oct 2010 08:25:11 +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 DA2458FC19; Sat, 30 Oct 2010 08:25:10 +0000 (UTC) Received: from porto.topspin.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 LAA18465; Sat, 30 Oct 2010 11:25:06 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6kM-000J5V-5p; Sat, 30 Oct 2010 11:25:06 +0300 Message-ID: <4CCBD661.3000204@freebsd.org> Date: Sat, 30 Oct 2010 11:25:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> In-Reply-To: <4CCBD46E.9030200@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 08:25:11 -0000 on 30/10/2010 11:16 Andriy Gapon said the following: > on 30/10/2010 11:16 Andriy Gapon said the following: >> Or maybe something like the following? >> It looks a little bit cleaner to me, but still is not perfect, as I have not >> handled unnecessary busy-ing of the pages where something more lightweight could >> have sufficed (e.g. wiring and shared busying). > > Note: I have only compile tested the patch. Missed one NULL check. Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,8 +475,18 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } vm_page_busy(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 09:53:01 2010 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 21DC9106566B; Sat, 30 Oct 2010 09:53:01 +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 317CA8FC0C; Sat, 30 Oct 2010 09:52:59 +0000 (UTC) Received: from porto.topspin.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 MAA19288; Sat, 30 Oct 2010 12:52:56 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC87M-000JBJ-Dx; Sat, 30 Oct 2010 12:52:56 +0300 Message-ID: <4CCBEAF6.2030408@freebsd.org> Date: Sat, 30 Oct 2010 12:52:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> In-Reply-To: <4CCBD661.3000204@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 09:53:01 -0000 Heh, next try. Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } else { + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + } + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,7 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; - vm_page_wakeup(m); + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); if (error == 0) { uio->uio_resid -= bytes; uio->uio_offset += bytes; -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 09:54:16 2010 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 C48D21065670; Sat, 30 Oct 2010 09:54:16 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4C58FC1E; Sat, 30 Oct 2010 09:54:16 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PC88c-0007UR-Cg; Sat, 30 Oct 2010 13:54:14 +0400 Date: Sat, 30 Oct 2010 13:54:25 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030095425.GA79691@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCBD661.3000204@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 09:54:16 -0000 On Sat, Oct 30, 2010 at 11:25:05AM +0300, Andriy Gapon wrote: > > Note: I have only compile tested the patch. > > Missed one NULL check. > > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =================================================================== > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -474,8 +475,18 @@ > */ > KASSERT(off == 0, > ("unexpected offset in mappedread for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > + if (m == NULL) { > + m = vm_page_alloc(obj, OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); > + if (m == NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } > vm_page_busy(m); > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { Ok, i tested this patch. It worked :) freebsd_zfs_read now calls (file_size/MAXBSIZE) times. Thanks! From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 10:12:44 2010 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 C85F3106564A; Sat, 30 Oct 2010 10:12:44 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1D18FC13; Sat, 30 Oct 2010 10:12:44 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PC8QV-0007nb-Av; Sat, 30 Oct 2010 14:12:43 +0400 Date: Sat, 30 Oct 2010 14:12:54 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030101254.GB79691@two.kliksys.ru> References: <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCBEAF6.2030408@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 10:12:44 -0000 On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > Heh, next try. Got a panic, "vm_page_unwire: invalid wire count: 0" From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 10:33:05 2010 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 7860E106564A; Sat, 30 Oct 2010 10:33:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7AF8FC0A; Sat, 30 Oct 2010 10:33:04 +0000 (UTC) Received: from porto.topspin.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 NAA19683; Sat, 30 Oct 2010 13:33:01 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC8k8-000JE4-SC; Sat, 30 Oct 2010 13:33:00 +0300 Message-ID: <4CCBF45C.4080208@icyb.net.ua> Date: Sat, 30 Oct 2010 13:33:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artemiev Igor References: <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> In-Reply-To: <20101030101254.GB79691@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 10:33:05 -0000 on 30/10/2010 13:12 Artemiev Igor said the following: > On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > >> Heh, next try. > > Got a panic, "vm_page_unwire: invalid wire count: 0" Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm_page_alloc): Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_WIRE | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } else { + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + } + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,7 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; - vm_page_wakeup(m); + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); if (error == 0) { uio->uio_resid -= bytes; uio->uio_offset += bytes; -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 11:25:10 2010 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 30000106566C; Sat, 30 Oct 2010 11:25:10 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id DA32D8FC18; Sat, 30 Oct 2010 11:25:09 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PC9Ya-0008zL-SL; Sat, 30 Oct 2010 15:25:08 +0400 Date: Sat, 30 Oct 2010 15:25:20 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030112520.GD79691@two.kliksys.ru> References: <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCBF45C.4080208@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 11:25:10 -0000 On Sat, Oct 30, 2010 at 01:33:00PM +0300, Andriy Gapon wrote: > on 30/10/2010 13:12 Artemiev Igor said the following: > > On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > > > >> Heh, next try. > > > > Got a panic, "vm_page_unwire: invalid wire count: 0" > > Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm_page_alloc): Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, therefore i slightly modified your patch: --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2010-10-30 11:56:41.621138440 +0200 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-10-30 12:49:32.858692096 +0200 @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,6 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); vm_page_wakeup(m); if (error == 0) { uio->uio_resid -= bytes; From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 14:44:01 2010 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 8D3C71065780; Sat, 30 Oct 2010 14:44:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 95BD48FC17; Sat, 30 Oct 2010 14:44:00 +0000 (UTC) Received: from porto.topspin.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 RAA22200; Sat, 30 Oct 2010 17:43:55 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCCew-000JUj-KC; Sat, 30 Oct 2010 17:43:54 +0300 Message-ID: <4CCC2F2A.7020809@icyb.net.ua> Date: Sat, 30 Oct 2010 17:43:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artemiev Igor References: <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> In-Reply-To: <20101030112520.GD79691@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 14:44:01 -0000 on 30/10/2010 14:25 Artemiev Igor said the following: > On Sat, Oct 30, 2010 at 01:33:00PM +0300, Andriy Gapon wrote: >> on 30/10/2010 13:12 Artemiev Igor said the following: >>> On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: >>> >>>> Heh, next try. >>> >>> Got a panic, "vm_page_unwire: invalid wire count: 0" >> >> Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm_page_alloc): > > Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, therefore i slightly modified your patch: I apologize for my haste, it should have been VM_ALLOC_WIRED. Here is a corrected patch: Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_WIRED | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } else { + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + } + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,7 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; - vm_page_wakeup(m); + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); if (error == 0) { uio->uio_resid -= bytes; uio->uio_offset += bytes; -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 15:59:55 2010 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 AE245106566C for ; Sat, 30 Oct 2010 15:59:55 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-h31.telenor.se (smtprelay-h31.telenor.se [213.150.131.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6AADB8FC13 for ; Sat, 30 Oct 2010 15:59:54 +0000 (UTC) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 16C20E8CCF for ; Sat, 30 Oct 2010 17:36:12 +0200 (CEST) X-SENDER-IP: [85.225.7.221] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkQANXXy0xV4QfdPGdsb2JhbAAHk0aOBgEBAQE1vEWFRASKVA X-IronPort-AV: E=Sophos;i="4.58,265,1286143200"; d="scan'208";a="1686282967" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb4.telenor.se with ESMTP; 30 Oct 2010 17:36:12 +0200 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Oct 2010 17:36:12 +0200 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: ZFS inresponsive. 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, 30 Oct 2010 15:59:55 -0000 I accidentally aborted a zfs send mid-tranfer. Now the receiveing side cant do anything with the affected filesystem. = both zfs list and zfs destroy hangs. How can I fix this? I can list other filesystems without a problem but a = general list or any command concerning the one the got broken in transer hangs the zfs command. Thanks. -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 16:00:11 2010 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 4693F1065672 for ; Sat, 30 Oct 2010 16:00:11 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-h32.telenor.se (smtprelay-h32.telenor.se [213.150.131.5]) by mx1.freebsd.org (Postfix) with ESMTP id EA7F98FC08 for ; Sat, 30 Oct 2010 16:00:10 +0000 (UTC) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-h32.telenor.se (Postfix) with ESMTP id 72892E897A for ; Sat, 30 Oct 2010 17:38:32 +0200 (CEST) X-SENDER-IP: [85.225.7.221] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkQAPPYy0xV4QfdPGdsb2JhbAAHk0eOBgEBAQE1vEOFRASKVA X-IronPort-AV: E=Sophos;i="4.58,265,1286143200"; d="scan'208";a="1686283187" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb4.telenor.se with ESMTP; 30 Oct 2010 17:38:32 +0200 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Oct 2010 17:38:31 +0200 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Raid + zfs performace. 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, 30 Oct 2010 16:00:11 -0000 Hi I have a question about raid and zfs. I Have a hardware-raid running. A = mirror thats the only storage in my zfs pool. Im going to add another mirror to the machine and my question is, what is the best = option performace-wise? Is it to add the other mirror to the same pool or create another = separate pool for that mirror?=20 Btw. Today my disk are quite saturated r/w wise. -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 16:02:56 2010 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 1841D1065672; Sat, 30 Oct 2010 16:02:56 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id B8C498FC0C; Sat, 30 Oct 2010 16:02:54 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PCDtI-0007Ed-Jd; Sat, 30 Oct 2010 20:02:48 +0400 From: "Alexander Zagrebin" To: "'Andriy Gapon'" References: <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua><4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org><4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua><20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> Date: Sat, 30 Oct 2010 20:02:48 +0400 Keywords: freebsd-stable Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <4CCC2F2A.7020809@icyb.net.ua> Thread-Index: Act4QSnRQ3vtTkc7S9uXBhrhQGUa3QACAn3w Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 16:02:56 -0000 > >> Oh, thank you for testing - forgot another piece > (VM_ALLOC_WIRE for vm_page_alloc): > > > > Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, > therefore i slightly modified your patch: > > I apologize for my haste, it should have been VM_ALLOC_WIRED. > Here is a corrected patch: > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =================================================================== > --- > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > (revision 214318) > +++ > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > (working copy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make > sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -474,9 +475,23 @@ > */ > KASSERT(off == 0, > ("unexpected offset in mappedread > for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > + if (m != NULL && > vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > - vm_page_busy(m); > + if (m == NULL) { > + m = vm_page_alloc(obj, > OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | > VM_ALLOC_WIRED | VM_ALLOC_NORMAL); > + if (m == NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } else { > + vm_page_lock_queues(); > + vm_page_wire(m); > + vm_page_unlock_queues(); > + } > + vm_page_io_start(m); > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { > error = dmu_read_uio(os, zp->z_id, uio, > @@ -494,7 +509,10 @@ > VM_OBJECT_LOCK(obj); > if (error == 0) > m->valid = VM_PAGE_BITS_ALL; > - vm_page_wakeup(m); > + vm_page_io_finish(m); > + vm_page_lock_queues(); > + vm_page_unwire(m, 0); > + vm_page_unlock_queues(); > if (error == 0) { > uio->uio_resid -= bytes; > uio->uio_offset += bytes; > Big thanks to Andriy, Igor and all who has paid attention to this problem. I've tried this patch on the test system running under VirtualBox, and it seems that it solves the problem. I'll try to test this patch in real conditions today. -- Alexander Zagrebin From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 17:57:15 2010 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 0D2C2106566B for ; Sat, 30 Oct 2010 17:57:15 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-b12.telenor.se (smtprelay-b12.telenor.se [62.127.194.21]) by mx1.freebsd.org (Postfix) with ESMTP id BAB108FC16 for ; Sat, 30 Oct 2010 17:57:14 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id 5F6CCE8D31 for ; Sat, 30 Oct 2010 19:57:13 +0200 (CEST) X-SENDER-IP: [85.225.7.221] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkWAML5y0xV4QfdPGdsb2JhbAAHh1OZewEBAQE1vTOFRASKVA X-IronPort-AV: E=Sophos;i="4.58,265,1286143200"; d="scan'208";a="144923868" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb2.telenor.se with ESMTP; 30 Oct 2010 19:56:57 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: Date: Sat, 30 Oct 2010 19:56:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> References: To: Sean X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 17:57:15 -0000 On 30 okt 2010, at 19.39, Sean wrote: >> I have a question about raid and zfs. I Have a hardware-raid running. >> A mirror thats the only storage in my zfs pool. Im going to >> add another mirror to the machine and my question is, what is the = best option performace-wise? >=20 > The best performance option is to get rid of the hardware-raid, and > present each disc to ZFS in a JBOD fashion. Ok. RIght now thats not an option. I have a da0 device thats a = hardware-raid mirror. and it is currently the only device in the only pool on the machine. >=20 >> Is it to add the other mirror to the same pool or create another = separate pool for that mirror? >> Btw. Today my disk are quite saturated r/w wise. >=20 > RAID functionality only exists within the context of a single pool. > You don't create a new pool and then try to mirror the two pools. You > add the storage to an existing pool, unless you have a reason to start > a new pool. When I already have a mirror, I like to add new mirror > sets. It's the equivalent of a RAID 10 scenario. Yes I know. I thought maybe because the existing pool is kind of r/w saturated it = should be better to create a new independent pool for the new drives. In that way the = heavy activity=20 would not "spread" to the new drives. Now you presented me with a third option. So you think I should skip to = create a new hardware-raid mirror and instead use two single drives and add = these as a mirror to the existing pool? How will zfs handle howswap of these = drives? I've seen a few crashes due to ata-detach in other systems. >=20 > -Sean >=20 From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 18:23:49 2010 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 16345106564A for ; Sat, 30 Oct 2010 18:23:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id EC7778FC14 for ; Sat, 30 Oct 2010 18:23:48 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta13.emeryville.ca.mail.comcast.net with comcast id R5ZK1f0031afHeLAD6Pof8; Sat, 30 Oct 2010 18:23:48 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta17.emeryville.ca.mail.comcast.net with comcast id R6Pm1f00G3LrwQ28d6Pn6X; Sat, 30 Oct 2010 18:23:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA45A9B422; Sat, 30 Oct 2010 11:23:46 -0700 (PDT) Date: Sat, 30 Oct 2010 11:23:46 -0700 From: Jeremy Chadwick To: Peter =?iso-8859-1?Q?Ankerst=E5l?= Message-ID: <20101030182346.GA61519@icarus.home.lan> References: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 18:23:49 -0000 On Sat, Oct 30, 2010 at 07:56:56PM +0200, Peter Ankerstål wrote: > > > On 30 okt 2010, at 19.39, Sean wrote: > > >> I have a question about raid and zfs. I Have a hardware-raid running. > >> A mirror thats the only storage in my zfs pool. Im going to > >> add another mirror to the machine and my question is, what is the best option performace-wise? > > > > The best performance option is to get rid of the hardware-raid, and > > present each disc to ZFS in a JBOD fashion. > > Ok. RIght now thats not an option. I have a da0 device thats a hardware-raid mirror. and it is currently > the only device in the only pool on the machine. > > > > >> Is it to add the other mirror to the same pool or create another separate pool for that mirror? > >> Btw. Today my disk are quite saturated r/w wise. > > > > RAID functionality only exists within the context of a single pool. > > You don't create a new pool and then try to mirror the two pools. You > > add the storage to an existing pool, unless you have a reason to start > > a new pool. When I already have a mirror, I like to add new mirror > > sets. It's the equivalent of a RAID 10 scenario. > > Yes I know. > I thought maybe because the existing pool is kind of r/w saturated it should be better > to create a new independent pool for the new drives. In that way the heavy activity > would not "spread" to the new drives. > > Now you presented me with a third option. So you think I should skip to create > a new hardware-raid mirror and instead use two single drives and add these as > a mirror to the existing pool? How will zfs handle howswap of these drives? > I've seen a few crashes due to ata-detach in other systems. As stated previously: ideally you should turn off all RAID capabilities on the controller itself and just use JBOD + let FreeBSD deal with the RAID'ing (in this case, ZFS). I realise you can't do this for the current hardware RAID'd "da0" mirror. I also understand the reason you might have done this. I too would trust a hardware RAID controller to handle booting from a mirror more than the FreeBSD bootstraps. (I choose not to deal with things like gptzfsboot, zfsloader, etc. etc. -- these should all just become part of the standard bootstraps and stop requiring people to jump through hoops to achieve such capabilities) As for hot-swapping of drives: there are well-established procedures for this sort of thing. I blogged about it[1] not too long ago, with real-world server hardware. I think it will address your concerns, since I spent the time to document *everything*, including all output. What confuses me about your statement is that you're talking about "ata-detach" when your drives are appearing as daX, which implies use of CAM. Are you talking about hot-swapping failing on a completely different system which was using ata(4) without AHCI? If so, I'm not surprised. You need AHCI to achieve this. Finally, you should be aware that there are two AHCI "methods" implemented in FreeBSD: ataahci.ko and ahci.ko. ataahci is the older of the two and uses ata(4). ahci.ko is the newer of the two and is significantly better, since it makes use of CAM, and thus provides performance improvements and handles hot-swapping a lot better (IMHO). ahci.ko "trumps" ataahci.ko (meaning if your kernel includes ataahci and you do "load ahci" from loader or loader.conf, ahci.ko will be used instead). Be aware that ahci.ko disks appear as adaX (this is not a typo). [1]: http://koitsu.wordpress.com/2010/07/22/freebsd-and-zfs-hot-swapping-sata-disks-with-ahci/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 18:34:57 2010 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 634CE1065697 for ; Sat, 30 Oct 2010 18:34:57 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-h31.telenor.se (smtprelay-h31.telenor.se [213.150.131.4]) by mx1.freebsd.org (Postfix) with ESMTP id E01A18FC1B for ; Sat, 30 Oct 2010 18:34:56 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id A9A3DE8BDF for ; Sat, 30 Oct 2010 20:34:55 +0200 (CEST) X-SENDER-IP: [85.225.7.221] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwQAPcBzExV4QfdPGdsb2JhbAAHoU4BAQEBNb01hUQEilQ X-IronPort-AV: E=Sophos;i="4.58,265,1286143200"; d="scan'208";a="144928831" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb2.telenor.se with ESMTP; 30 Oct 2010 20:34:55 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <20101030182346.GA61519@icarus.home.lan> Date: Sat, 30 Oct 2010 20:34:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34DA1356-9622-43C0-BA41-61E4A14C6533@pean.org> References: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> <20101030182346.GA61519@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 18:34:57 -0000 On 30 okt 2010, at 20.23, Jeremy Chadwick wrote: > On Sat, Oct 30, 2010 at 07:56:56PM +0200, Peter Ankerst=E5l wrote: >>=20 >>=20 >> On 30 okt 2010, at 19.39, Sean wrote: >>=20 >>>> I have a question about raid and zfs. I Have a hardware-raid = running. >>>> A mirror thats the only storage in my zfs pool. Im going to >>>> add another mirror to the machine and my question is, what is the = best option performace-wise? >>>=20 >>> The best performance option is to get rid of the hardware-raid, and >>> present each disc to ZFS in a JBOD fashion. >>=20 >> Ok. RIght now thats not an option. I have a da0 device thats a = hardware-raid mirror. and it is currently >> the only device in the only pool on the machine. >>=20 >>>=20 >>>> Is it to add the other mirror to the same pool or create another = separate pool for that mirror? >>>> Btw. Today my disk are quite saturated r/w wise. >>>=20 >>> RAID functionality only exists within the context of a single pool. >>> You don't create a new pool and then try to mirror the two pools. = You >>> add the storage to an existing pool, unless you have a reason to = start >>> a new pool. When I already have a mirror, I like to add new mirror >>> sets. It's the equivalent of a RAID 10 scenario. >>=20 >> Yes I know. >> I thought maybe because the existing pool is kind of r/w saturated it = should be better >> to create a new independent pool for the new drives. In that way the = heavy activity=20 >> would not "spread" to the new drives. >>=20 >> Now you presented me with a third option. So you think I should skip = to create >> a new hardware-raid mirror and instead use two single drives and add = these as >> a mirror to the existing pool? How will zfs handle howswap of these = drives? >> I've seen a few crashes due to ata-detach in other systems. >=20 > As stated previously: ideally you should turn off all RAID = capabilities > on the controller itself and just use JBOD + let FreeBSD deal with the > RAID'ing (in this case, ZFS). >=20 > I realise you can't do this for the current hardware RAID'd "da0" > mirror. I also understand the reason you might have done this. I too > would trust a hardware RAID controller to handle booting from a mirror > more than the FreeBSD bootstraps. (I choose not to deal with things > like gptzfsboot, zfsloader, etc. etc. -- these should all just become > part of the standard bootstraps and stop requiring people to jump > through hoops to achieve such capabilities) >=20 Yes. > As for hot-swapping of drives: there are well-established procedures = for > this sort of thing. I blogged about it[1] not too long ago, with > real-world server hardware. I think it will address your concerns, > since I spent the time to document *everything*, including all output. >=20 > What confuses me about your statement is that you're talking about > "ata-detach" when your drives are appearing as daX, which implies use = of > CAM. Are you talking about hot-swapping failing on a completely > different system which was using ata(4) without AHCI? If so, I'm not > surprised. You need AHCI to achieve this. Yes, that was another machine. >=20 > Finally, you should be aware that there are two AHCI "methods" > implemented in FreeBSD: ataahci.ko and ahci.ko. ataahci is the older = of > the two and uses ata(4). ahci.ko is the newer of the two and is > significantly better, since it makes use of CAM, and thus provides > performance improvements and handles hot-swapping a lot better (IMHO). > ahci.ko "trumps" ataahci.ko (meaning if your kernel includes ataahci = and > you do "load ahci" from loader or loader.conf, ahci.ko will be used > instead). Be aware that ahci.ko disks appear as adaX (this is not a > typo). >=20 > [1]: = http://koitsu.wordpress.com/2010/07/22/freebsd-and-zfs-hot-swapping-sata-d= isks-with-ahci/ >=20 > --=20 > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | >=20 >=20 From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 18:35:29 2010 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 242171065696 for ; Sat, 30 Oct 2010 18:35:29 +0000 (UTC) (envelope-from sean@ttys0.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id B4DCE8FC1B for ; Sat, 30 Oct 2010 18:35:28 +0000 (UTC) Received: by eyb7 with SMTP id 7so2332409eyb.13 for ; Sat, 30 Oct 2010 11:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.112.133 with SMTP id w5mr653603ebp.96.1288462176550; Sat, 30 Oct 2010 11:09:36 -0700 (PDT) Received: by 10.14.127.4 with HTTP; Sat, 30 Oct 2010 11:09:36 -0700 (PDT) In-Reply-To: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> References: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> Date: Sat, 30 Oct 2010 14:09:36 -0400 Message-ID: From: Sean To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 18:35:29 -0000 > I thought maybe because the existing pool is kind of r/w saturated > it should be better to create a new independent pool for the new > drives. In that way the heavy activity would not "spread" to the > new drives. You're trying to be smarter than ZFS. It's a common syndrome, usually brought about from years of experience dealing with "dumb" filesystems. If you create a new independent pool, then you are guaranteeing that your current r/w saturated pool will stay that way, unless you manually migrate data off of that pool. If you add storage to that pool, then you are providing that pool additional resource that ZFS can then manage. > Now you presented me with a third option. So you think I should skip to create > a new hardware-raid mirror and instead use two single drives and add these as > a mirror to the existing pool? If you're going to keep the hardware raid, then setting up a new hardware raid of two drives, and then striping da1 with da0 via zfs is a viable option. It's just another spin on the RAID 10 idea. > How will zfs handle howswap of these drives? ZFS doesn't know about your drives, because you hardware raid them. If you set up the second hardware raid mirror as a striped drive in the pool, and you then lose both drives within a single hardware raid mirror set, you'll be in the drink. But that's the case with any RAID 10 scenario. > I've seen a few crashes due to ata-detach in other systems. That's not a ZFS issue, that's a driver/support issue with the controller. -Sean From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 18:38:07 2010 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 9DB4B106564A for ; Sat, 30 Oct 2010 18:38:07 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by mx1.freebsd.org (Postfix) with ESMTP id 279528FC08 for ; Sat, 30 Oct 2010 18:38:06 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id D69C4E8DDF for ; Sat, 30 Oct 2010 20:38:05 +0200 (CEST) X-SENDER-IP: [85.225.7.221] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkWAOgCzExV4QfdPGdsb2JhbAAHh1OZewEBAQE1vTaFRASKVA X-IronPort-AV: E=Sophos;i="4.58,265,1286143200"; d="scan'208";a="146018338" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb1.telenor.se with ESMTP; 30 Oct 2010 20:38:05 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: Date: Sat, 30 Oct 2010 20:38:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> To: Sean X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 18:38:07 -0000 On 30 okt 2010, at 20.09, Sean wrote: >> I thought maybe because the existing pool is kind of r/w saturated >> it should be better to create a new independent pool for the new >> drives. In that way the heavy activity would not "spread" to the >> new drives. >=20 > You're trying to be smarter than ZFS. It's a common syndrome, usually > brought about from years of experience dealing with "dumb" > filesystems. If you create a new independent pool, then you are > guaranteeing that your current r/w saturated pool will stay that way, > unless you manually migrate data off of that pool. If you add storage > to that pool, then you are providing that pool additional resource > that ZFS can then manage. >=20 >> Now you presented me with a third option. So you think I should skip = to create >> a new hardware-raid mirror and instead use two single drives and add = these as >> a mirror to the existing pool? >=20 > If you're going to keep the hardware raid, then setting up a new > hardware raid of two drives, and then striping da1 with da0 via zfs is > a viable option. It's just another spin on the RAID 10 idea. Ok. I think I'll go with this option for this machine. In the future I = would probably use a small SSD for booting and then use zfs for all raid-solutions.=20 >=20 >> How will zfs handle howswap of these drives? >=20 > ZFS doesn't know about your drives, because you hardware raid them. If > you set up the second hardware raid mirror as a striped drive in the > pool, and you then lose both drives within a single hardware raid > mirror set, you'll be in the drink. But that's the case with any RAID > 10 scenario. >=20 >> I've seen a few crashes due to ata-detach in other systems. >=20 > That's not a ZFS issue, that's a driver/support issue with the = controller. >=20 > -Sean >=20 From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 19:01:11 2010 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 7A450106566C; Sat, 30 Oct 2010 19:01:11 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 22BA88FC28; Sat, 30 Oct 2010 19:01:11 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PCGft-000GSz-GV; Sat, 30 Oct 2010 23:01:09 +0400 Date: Sat, 30 Oct 2010 23:01:20 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030190120.GA80301@two.kliksys.ru> References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCC2F2A.7020809@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Rspamd-Flag: YES X-Spam_score: 36050387444074.7 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 19:01:11 -0000 On Sat, Oct 30, 2010 at 05:43:54PM +0300, Andriy Gapon wrote: > I apologize for my haste, it should have been VM_ALLOC_WIRED. Ok, applied and tested under some load(~1200 active connections, outgoing ~80MB/s). Patch work as expected and i has noted no side effects. Just one question - should grow Active memory counter, if some pages is "hot"(during multiple sendfile on one file)? From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 19:13:43 2010 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 99D82106564A for ; Sat, 30 Oct 2010 19:13:43 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-h32.telenor.se (smtprelay-h32.telenor.se [213.150.131.5]) by mx1.freebsd.org (Postfix) with ESMTP id 510628FC13 for ; Sat, 30 Oct 2010 19:13:42 +0000 (UTC) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-h32.telenor.se (Postfix) with ESMTP id 03034E88C5 for ; Sat, 30 Oct 2010 21:13:41 +0200 (CEST) X-SENDER-IP: [85.225.7.221] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwQAFYLzExV4QfdPGdsb2JhbAAHoU8BAQEBNb08hUQEiWVv X-IronPort-AV: E=Sophos;i="4.58,265,1286143200"; d="scan'208";a="1686308438" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb4.telenor.se with ESMTP; 30 Oct 2010 21:13:41 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: Date: Sat, 30 Oct 2010 21:13:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> To: Sean X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 19:13:43 -0000 >=20 >=20 >> Now you presented me with a third option. So you think I should skip = to create >> a new hardware-raid mirror and instead use two single drives and add = these as >> a mirror to the existing pool? >=20 > If you're going to keep the hardware raid, then setting up a new > hardware raid of two drives, and then striping da1 with da0 via zfs is > a viable option. It's just another spin on the RAID 10 idea. >=20 Sorry to ask again but I'm still not sure what you think is the best = solution when=20 comparing adding the two new drives as a zfs mirror like: pool da0 mirror da1 da2 or making a hardware mirror da1 and adding that one=20 pool=20 da0 da1 And by the way. you guys seem zfs-shifty. Do you have any ideas about my = other problem i posted to the list? = (http://lists.freebsd.org/pipermail/freebsd-fs/2010-October/009922.html) Thanks! From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 20:11:48 2010 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 CDC481065675 for ; Sat, 30 Oct 2010 20:11:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id AEA258FC12 for ; Sat, 30 Oct 2010 20:11:48 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta08.emeryville.ca.mail.comcast.net with comcast id R88t1f0021wfjNsA88Bouw; Sat, 30 Oct 2010 20:11:48 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta23.emeryville.ca.mail.comcast.net with comcast id R8Bn1f0013LrwQ28j8Bngy; Sat, 30 Oct 2010 20:11:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E76899B422; Sat, 30 Oct 2010 13:11:46 -0700 (PDT) Date: Sat, 30 Oct 2010 13:11:46 -0700 From: Jeremy Chadwick To: Peter =?iso-8859-1?Q?Ankerst=E5l?= Message-ID: <20101030201146.GA63194@icarus.home.lan> References: <86693036-9351-4303-BADA-C99F7A4C375C@pean.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 20:11:49 -0000 On Sat, Oct 30, 2010 at 09:13:41PM +0200, Peter Ankerstål wrote: > > > > > >> Now you presented me with a third option. So you think I should skip to create > >> a new hardware-raid mirror and instead use two single drives and add these as > >> a mirror to the existing pool? > > > > If you're going to keep the hardware raid, then setting up a new > > hardware raid of two drives, and then striping da1 with da0 via zfs is > > a viable option. It's just another spin on the RAID 10 idea. > > > Sorry to ask again but I'm still not sure what you think is the best solution when > comparing adding the two new drives as a zfs mirror like: > pool > da0 > mirror > da1 > da2 > > or making a hardware mirror da1 and adding that one > > pool > da0 > da1 The answer is "it depends", and I can't authoritatively act as your system administrator since I don't have any familiarity with what it is your systems are doing and so on. That's your job. :-) You'd need to disclose exactly: - What hardware RAID controller you're using and all of its capabilities, including if it has cache and a BBU, - Full details of the workload on the machine and what the majority of I/O consists of, - What exact OS you're running (uname -a please) and how much physical RAM the system has. If you really want to answer your own question, I would recommend at least performing benchmarks (bonnie++ might suffice) with both setups. And don't forget that if you use ZFS you'll need to perform some minor loader.conf tuning, and expect to adjust values depending on workload/environment. > And by the way. you guys seem zfs-shifty. Language barrier detected! :-) "ZFS-shifty" could mean either "you're ZFS advocates (fans of ZFS and recommend using it over anything else)", or "you're timid when it comes to/afraid of ZFS". I think you meant the first one, but I'm not certain. If so: believe it or not, I'm not much of a FreeBSD ZFS advocate. There are issues that keep appearing on the mailing lists (-stable and -fs), and each incident has to be handled individually. There are definitely stability issues (we just experienced one ourselves which was major[1]; it's been fixed in RELENG_8 since mid-October) which are still getting hammered out. My logic is this, and this is just one man's opinion: - If you need absolute stability, don't have time or the desire to tinker with new technology (or have 100% mission-critical services in use), stick with using UFS + softupdates. - If filesystem administrative simplicity is needed over everything else, ZFS is an excellent choice. - If you want ZFS and need absolute rock-solid performance, stability, and It Should Just Work(tm), run Solaris 10 or OpenSolaris. - If you're going to use ZFS on FreeBSD, you need to run RELENG_8, and should almost certainly be running amd64, and have at least 4GB RAM. > Do you have any ideas about my other problem i posted to the list? > (http://lists.freebsd.org/pipermail/freebsd-fs/2010-October/009922.html) Nope, I don't. I don't use ZFS send/recv nor snapshot capability. I do keep seeing problems reported with both of these on the lists, but again, they have to be handled on a per-case basis. [1]: http://lists.freebsd.org/pipermail/freebsd-fs/2010-October/thread.html#9687 ("Locked up processes after upgrade to ZFS v15") -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 20:17:12 2010 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 E004A1065672 for ; Sat, 30 Oct 2010 20:17:12 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 81A1B8FC0C for ; Sat, 30 Oct 2010 20:17:12 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o9UKH8qU053270; Sat, 30 Oct 2010 15:17:09 -0500 (CDT) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=TjRjf1d9k33nj5OHffyemhHyvidM6XMXcv8CG9BAw3OqfCMPHPLpdgJuqKhxz3pK6 P8ZDX87rW64wFESOGxl6qR4xLx33rSq1Sq3AFhmc60Afs5ur0M5GLpuRL55ZKGP5qQl hjdlQ+niYgFWxgC9lODtAUeXdbeyArJyU5k2XKE= Message-ID: <4CCC7D44.4080704@jrv.org> Date: Sat, 30 Oct 2010 15:17:08 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Raid + zfs performace. 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, 30 Oct 2010 20:17:13 -0000 Peter Ankerst=E5l wrote: > I have a question about raid and zfs. I Have a hardware-raid running. A= mirror thats the only storage in my zfs pool. Im going to > add another mirror to the machine and my question is, what is the best = option performace-wise? > Is it to add the other mirror to the same pool or create another separa= te pool for that mirror?=20 > Btw. Today my disk are quite saturated r/w wise. You should see if your disks are evenly saturated with reads & writes, or heavily reads with few writes etc. Whether the new mirror should be added to the existing pool or placed in a new pool depends on your unstated goals: do you want to reduce existing I/O saturation or add storage that does not compete with existing I/O traffic? If you are concerned about recovery scenarios then it is better to put the RAID controller in JBOD mode using ZFS for a number of reasons: 1. When you replace a disk ZFS only rebuilds the areas of the disk that are used. The RAID controller must rebuild the entire disk, resulting in extra I/O. 2. If a failure is not in the disk but rather somewhere else - perhaps a disconnected cable - then ZFS can quickly rebuild the disk when reconnected, often very quickly. Last year I accidentally yanked out the cable to an enclosure with 4 2TB disks (each in a different mirror), and when I reconnected the enclosure ZFS took about *two seconds* to rebuild everything. A RAID controller would have had to rebuild all 8 TB= =2E 3. With ZFS the different disks in a mirror need not be on the same controller. For a while I ran one "side" of each mirror on an LSI SAS controller using the mpt driver and other "side" of each mirror on a 3124 SATA controller using the siis driver. With hardware RAID you've generally got the RAID controller and device driver as single points of failure. ZFS mirrors can be many-way mirrors. I have not tested this but it seems likely ZFS load balances reads in a mirror. If the I/O load is heavily slanted towards reads then adding more "ways" to the mirror might add performance as well as redundancy. From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 23:37:44 2010 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 55947106566B; Sat, 30 Oct 2010 23:37:44 +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 DD8438FC0C; Sat, 30 Oct 2010 23:37:43 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9UNbddd045480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Oct 2010 02:37:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9UNbdiO068739; Sun, 31 Oct 2010 02:37:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9UNbdbY068737; Sun, 31 Oct 2010 02:37:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Oct 2010 02:37:39 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101030233739.GE2392@deviant.kiev.zoral.com.ua> References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H0CA2egUVSYJgt8C" Content-Disposition: inline In-Reply-To: <4CCC2F2A.7020809@icyb.net.ua> 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.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 30 Oct 2010 23:37:44 -0000 --H0CA2egUVSYJgt8C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 30, 2010 at 05:43:54PM +0300, Andriy Gapon wrote: > on 30/10/2010 14:25 Artemiev Igor said the following: > > On Sat, Oct 30, 2010 at 01:33:00PM +0300, Andriy Gapon wrote: > >> on 30/10/2010 13:12 Artemiev Igor said the following: > >>> On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > >>> > >>>> Heh, next try. > >>> > >>> Got a panic, "vm_page_unwire: invalid wire count: 0" > >> > >> Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm= _page_alloc): > >=20 > > Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, therefore i sli= ghtly modified your patch: >=20 > I apologize for my haste, it should have been VM_ALLOC_WIRED. > Here is a corrected patch: > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision = 214318) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working c= opy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include >=20 > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m !=3D NULL && uio->uio_segflg =3D=3D UIO_NOCOPY) { > + } else if (uio->uio_segflg =3D=3D UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -474,9 +475,23 @@ > */ > KASSERT(off =3D=3D 0, > ("unexpected offset in mappedread for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > + if (m !=3D NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > - vm_page_busy(m); > + if (m =3D=3D NULL) { > + m =3D vm_page_alloc(obj, OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | VM_ALLOC_WIRED | VM_ALLOC_NORMAL); > + if (m =3D=3D NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } else { > + vm_page_lock_queues(); > + vm_page_wire(m); > + vm_page_unlock_queues(); > + } > + vm_page_io_start(m); Why wiring the page if it is busied ? --H0CA2egUVSYJgt8C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzMrEIACgkQC3+MBN1Mb4jzjACgpf/B2jMS6qDaPNXeiZh9PsB8 srcAoOonoQX11nzARvxoXtKXWY7UVVJu =DbNN -----END PGP SIGNATURE----- --H0CA2egUVSYJgt8C--