From owner-freebsd-fs@FreeBSD.ORG Sun Oct 6 12:00:32 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8D8DC581 for ; Sun, 6 Oct 2013 12:00:32 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 703DC26A7 for ; Sun, 6 Oct 2013 12:00:31 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VSn0g-0007i7-Ov for freebsd-fs@freebsd.org; Sun, 06 Oct 2013 05:00:30 -0700 Date: Sun, 6 Oct 2013 05:00:30 -0700 (PDT) From: Beeblebrox To: freebsd-fs@freebsd.org Message-ID: <1381060830753-5849397.post@n5.nabble.com> In-Reply-To: <524EEE40.5060208@gmail.com> References: <1380880223590-5848720.post@n5.nabble.com> <524EEE40.5060208@gmail.com> Subject: Questions re swap-on-zfs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 12:00:32 -0000 @Volodymyr: Thanks for #4 - I implemented those per your suggestion but already had checksum=off anyway. For #2, I have seen "pri= for fstab settings in linux how-to's. Does pri= not work in FreeBSD, or does it not work for ZFS? I mean, why "nope"? Regards. ----- FreeBSD-9.2-stable_amd64_root-on-zfs_clang-only-world -- View this message in context: http://freebsd.1045724.n5.nabble.com/Questions-re-swap-on-zfs-tp5848720p5849397.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Sun Oct 6 12:38:59 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E72C016D for ; Sun, 6 Oct 2013 12:38:59 +0000 (UTC) (envelope-from hal@elizium.za.net) Received: from squishy.elizium.za.net (squishy.elizium.za.net [80.68.90.178]) by mx1.freebsd.org (Postfix) with ESMTP id AE075280C for ; Sun, 6 Oct 2013 12:38:59 +0000 (UTC) Received: from sludge.elizium.za.net (sludge.elizium.za.net [196.41.137.247]) by squishy.elizium.za.net (Postfix) with ESMTPSA id 236678120; Sun, 6 Oct 2013 14:32:59 +0200 (SAST) Date: Sun, 6 Oct 2013 14:33:50 +0200 From: Hugo Lombard To: Beeblebrox Subject: Re: Questions re swap-on-zfs Message-ID: <20131006123350.GJ3287@sludge.elizium.za.net> References: <1380880223590-5848720.post@n5.nabble.com> <524EEE40.5060208@gmail.com> <1381060830753-5849397.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1381060830753-5849397.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 12:39:00 -0000 On Sun, Oct 06, 2013 at 05:00:30AM -0700, Beeblebrox wrote: > > For #2, I have seen "pri= for fstab settings in linux how-to's. > Does pri= not work in FreeBSD, or does it not work for ZFS? I mean, why > "nope"? > swapon(8), first paragraph: The swapon, swapoff and swapctl utilities are used to control swap devices in the system. At boot time all swap entries in /etc/fstab are added automatically when the system goes multi-user. Swap devices use a fixed interleave; the maximum number of devices is specified by the ker- nel configuration option NSWAPDEV, which is typically set to 4. There is no priority mechanism. ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ -- Hugo Lombard .___. (o,o) /) ) ---"-"--- From owner-freebsd-fs@FreeBSD.ORG Sun Oct 6 19:31:34 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 78923D9A for ; Sun, 6 Oct 2013 19:31:34 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 388012BC9 for ; Sun, 6 Oct 2013 19:31:34 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id p13so3146026vbe.33 for ; Sun, 06 Oct 2013 12:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gut189SxLzn9fudRGgpHH2vl4AsFmyBEStmT7Dn4QDY=; b=auWMNvih4qzz0oit8r9yn0aKCzy0jcpbZegzJtIfj5Dwm3/9OamzhTQqMCqK5eXbTT kQLWALip18lyIO2wmVd7JkSkPg8/fUxHElPatEl6X2afG2VMRMeEclA65duX61fvQizR njKkkqPp3hKDRSIRhGa1n5Grd+4JZji3OpKxmM5EClC/E3wWwHI9aCNLUyUrtz9AnD3Q XW4oNmU3J4vEwetnDgxm5mUXDnkQetf+xWyFKB6Eyv7rWtlnr0OtDeJUvgrGBukcO/YI uCAEGvnL5MG16w5oFxmdotNRC8gBwhXNU30i2q75wacujpJi3W3dG3yx+mwHzTe3d6bx UdUA== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr2138271vcb.16.1381087893280; Sun, 06 Oct 2013 12:31:33 -0700 (PDT) Received: by 10.220.30.130 with HTTP; Sun, 6 Oct 2013 12:31:33 -0700 (PDT) In-Reply-To: <1381005634317-5849247.post@n5.nabble.com> References: <1380880223590-5848720.post@n5.nabble.com> <524EEE40.5060208@gmail.com> <1381005634317-5849247.post@n5.nabble.com> Date: Sun, 6 Oct 2013 15:31:33 -0400 Message-ID: Subject: Re: Questions re swap-on-zfs From: Zaphod Beeblebrox To: Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 19:31:34 -0000 On Sat, Oct 5, 2013 at 4:40 PM, Beeblebrox wrote: > @ Zaphod Beeblebrox-2 > >> I have partition for swap and a partition for ZFS on each drive. This > >> has the additional bonus of > making swap effectively faster on a 2 drive system (2 swap partitions). > > That's what I have, with the difference that one of the swaps is on the ZFS > pool. So I have 2 swaps as well, but want to minimise usage of swap-on-SSD > so as to prevent SSD fatigue for the swap area. > Well... to be fair, swap on ZFS will deliver you twice the read speed, but only 1x the write speed of the comparable swap on two drives. That said, TRIM support for SWAP would be spiffy! > BTW, I'm the only legitimate President of the Galaxy. Just remember that, > "Left Brain" > (http://hitchhikers.wikia.com/wiki/Zaphod_Beeblebrox?action=edit§ion=1 > ) > You don't appear to have the blessings of Google to back your claim, so who would believe you? From owner-freebsd-fs@FreeBSD.ORG Mon Oct 7 11:06:44 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 896DF849 for ; Mon, 7 Oct 2013 11:06:44 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 757CA2832 for ; Mon, 7 Oct 2013 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r97B6irL077689 for ; Mon, 7 Oct 2013 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r97B6h4T077687 for freebsd-fs@FreeBSD.org; Mon, 7 Oct 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Oct 2013 11:06:43 GMT Message-Id: <201310071106.r97B6h4T077687@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:06:44 -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/182570 fs [zfs] [patch] ZFS panic in receive o kern/181966 fs [zfs] Kernel panic in ZFS I/O: solaris assert: BP_EQUA o kern/181834 fs [nfs] amd mounting NFS directories can drive a dead-lo o kern/181565 fs [swap] Problem with vnode-backed swap space. o kern/181377 fs [zfs] zfs recv causes an inconsistant pool o kern/181281 fs [msdosfs] stack trace after successfull 'umount /mnt' o kern/181082 fs [fuse] [ntfs] Write to mounted NTFS filesystem using F o kern/180979 fs [netsmb][patch]: Fix large files handling o kern/180876 fs [zfs] [hast] ZFS with trim,bio_flush or bio_delete loc o kern/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS s kern/178467 fs [zfs] [request] Optimized Checksum Code for ZFS o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178387 fs [zfs] [patch] sparse files performance improvements o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/145750 fs [unionfs] [hang] unionfs locks the machine s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/67326 fs [msdosfs] crash after attempt to mount write protected o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t o kern/9619 fs [nfs] Restarting mountd kills existing mounts 335 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Oct 7 15:39:32 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E6A1FFB9 for ; Mon, 7 Oct 2013 15:39:32 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews08.kpnxchange.com (cpsmtpb-ews08.kpnxchange.com [213.75.39.13]) by mx1.freebsd.org (Postfix) with ESMTP id 833122BEE for ; Mon, 7 Oct 2013 15:39:31 +0000 (UTC) Received: from cpsps-ews01.kpnxchange.com ([10.94.84.168]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 7 Oct 2013 17:38:21 +0200 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 7 Oct 2013 17:38:21 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 7 Oct 2013 17:38:21 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 872896F3 for ; Mon, 7 Oct 2013 17:38:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: Questions re swap-on-zfs References: <1380880223590-5848720.post@n5.nabble.com> <524EEE40.5060208@gmail.com> <1381060830753-5849397.post@n5.nabble.com> <20131006123350.GJ3287@sludge.elizium.za.net> Date: Mon, 07 Oct 2013 17:38:20 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20131006123350.GJ3287@sludge.elizium.za.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 07 Oct 2013 15:38:22.0091 (UTC) FILETIME=[41158DB0:01CEC373] X-RcptDomain: freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:39:33 -0000 On Sun, 06 Oct 2013 14:33:50 +0200, Hugo Lombard wrote: > On Sun, Oct 06, 2013 at 05:00:30AM -0700, Beeblebrox wrote: >> >> For #2, I have seen "pri= for fstab settings in linux >> how-to's. >> Does pri= not work in FreeBSD, or does it not work for ZFS? I mean, why >> "nope"? >> > > swapon(8), first paragraph: > > The swapon, swapoff and swapctl utilities are used to control swap > devices in the system. At boot time all swap entries in /etc/fstab are > added automatically when the system goes multi-user. Swap devices use > a > fixed interleave; the maximum number of devices is specified by the > ker- > nel configuration option NSWAPDEV, which is typically set to 4. There > is > no priority mechanism. > ^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^ > You could use ccd(4) to concatenate two disks and use that as swap. That would give the functionality of your 'prio' option. Ronald. From owner-freebsd-fs@FreeBSD.ORG Mon Oct 7 17:25:24 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5938FE1; Mon, 7 Oct 2013 17:25:24 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61C632381; Mon, 7 Oct 2013 17:25:24 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id jx11so3794754veb.7 for ; Mon, 07 Oct 2013 10:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=77/FGlPtJQikkCNyMtJj5PGGj3kDDBVKXvfteIN4PFw=; b=K3QXpGYPoIhKtwElQDiSPcbxPOgLHVlj647bqPOF+qzli7E0Jgm3lijpw6wTPW2P73 TsDXckVaUYyBaRieOA370Govn568XKf2kvpk0BzapVhXSwwrmHRev41LFh5UeUIguSOh 6O/uhtt50FXEgyk8GahQ7tdSQOUriwp7m8Kg7FJ2QjZ+E1K9rQxOM6Jx5pMnHZfqykwI pMfYeNnNG8TzNpYSAa1Jz4j8kWA6YFJr3YBABPJB9PpreErhKtc06WDf1Nc2EDmwqMgJ B9t2c8r8Gz+GcEudBytg+GhbHaFVkMCQ5KKtd15IIXca6he4UBQWVFFHJu1RTbIrShcl QZgA== MIME-Version: 1.0 X-Received: by 10.220.110.6 with SMTP id l6mr831498vcp.28.1381166723442; Mon, 07 Oct 2013 10:25:23 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Mon, 7 Oct 2013 10:25:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 19:25:23 +0200 X-Google-Sender-Auth: cEoomBk3YXNvobK7q4CgSDta6XQ Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:25:24 -0000 On Wed, Aug 28, 2013 at 3:56 PM, Ivan Voras wrote: > Hi, > > Prodded by davide@, I'd like to collect opinions about raising the > vfs.ufs.dirhash_reclaimage sysctl from 5 to 60, committed at: > > http://svnweb.freebsd.org/changeset/base/254986 > > What it does: > > Used in lowmem handler at > http://fxr.watson.org/fxr/source/ufs/ufs/ufs_dirhash.c#L1247 when > determining which cache entries to evict; it skips (keeps in the cache) > entries which are younger than this number of seconds. This lowmem > handler only frees up to 10% of the dirhash cache at a time. > I don't think this is correct. The first loop scans over the whole ufsdirhash_list and there's nothing that sets the cap to 10%. It might happen that UFS is unused for some minutes and you'll end up with all the cache free'd. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-fs@FreeBSD.ORG Mon Oct 7 17:34:27 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CE9C57C; Mon, 7 Oct 2013 17:34:27 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E951244B; Mon, 7 Oct 2013 17:34:26 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id hv10so2981185vcb.8 for ; Mon, 07 Oct 2013 10:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vwvLFqEb9U3hPhbAAIAXI33/t4DokjslzkbwD0tEOEE=; b=B5D5qdgZjOLI4OvC4CfkONMBr1HebyTvBJN677fjR3J3rsr856MBtJAcRSywS4z+jW xdlksiBjabW1pa/ea99ZCpjb6goYfU+FwLTzWaTwgFLs3g5fkeD6UWm6db/7qL8lah7L xGhszWNNx3agaqjcqDKdK9v/ejtTGnG6iGEEmp6EHkWQq1cIRj44OEuy6Qcdmn4AKTO3 kKBJbdGYpR305Ks/245FGjbVRRh9cWfNrJVzdB5x5dZiwINplxwj35dxBkTyTA6XZniu JEQzSV9c03/LGcaemMvS9Vf87E1QR7rfSMa5cjLjLOKoeuQm3KHy0EbsiXH/W+cXCLjo r18A== MIME-Version: 1.0 X-Received: by 10.221.44.136 with SMTP id ug8mr27375118vcb.13.1381167265028; Mon, 07 Oct 2013 10:34:25 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Mon, 7 Oct 2013 10:34:24 -0700 (PDT) In-Reply-To: <201309031507.33098.jhb@freebsd.org> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> Date: Mon, 7 Oct 2013 19:34:24 +0200 X-Google-Sender-Auth: JQDCy-MSqtcuvUVwEdRZlUXTzvU Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , alc@freebsd.org, freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras , pho@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:34:27 -0000 > What would perhaps be better than a hardcoded reclaim age would be to use > an LRU-type approach and perhaps set a target percent to reclaim. That is, > suppose you were to reclaim the oldest 10% of hashes on each lowmem call > (and make the '10%' the tunable value). Then you will always make some amount > of progress in a low memory situation (and if the situation remains dire you > will eventually empty the entire cache), but the effective maximum age will > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > throws the entire thing out on the first lowmem event. The LRU-approach would > only throw the oldest 10% out on the first call, but eventually throw it all out > if the situation remains dire. > > -- > John Baldwin > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" I liked your idea more than what's available in HEAD right now and I implemented it. http://people.freebsd.org/~davide/review/ufs_direclaimage.diff I was unsure what kind of heuristic I should choose to select which (10% of) entries should be evicted so I just removed the first 10% ones from the head of the ufs_dirhash list (which should be the oldest). The code keeps rescanning the cache until 10% (or, the percentage set via SYSCTL) of the entry are freed, but probably we can discuss if this limit could be relaxed and just do a single scan over the list. Unfortunately I haven't a testcase to prove the effectiveness (or non-effectiveness) of the approach but I think either Ivan or Peter could be able to give it a spin, maybe. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-fs@FreeBSD.ORG Tue Oct 8 02:34:35 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90DB568A; Tue, 8 Oct 2013 02:34:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66C2D2914; Tue, 8 Oct 2013 02:34:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r982YZDZ035720; Tue, 8 Oct 2013 02:34:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r982YZkZ035719; Tue, 8 Oct 2013 02:34:35 GMT (envelope-from linimon) Date: Tue, 8 Oct 2013 02:34:35 GMT Message-Id: <201310080234.r982YZkZ035719@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/182536: [zfs] zfs deadlock X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 02:34:35 -0000 Old Synopsis: zfs deadlock New Synopsis: [zfs] zfs deadlock Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 8 02:34:26 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=182536 From owner-freebsd-fs@FreeBSD.ORG Tue Oct 8 06:20:01 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A67C7AAA for ; Tue, 8 Oct 2013 06:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78E022628 for ; Tue, 8 Oct 2013 06:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r986K1LQ085932 for ; Tue, 8 Oct 2013 06:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r986K1TZ085931; Tue, 8 Oct 2013 06:20:01 GMT (envelope-from gnats) Date: Tue, 8 Oct 2013 06:20:01 GMT Message-Id: <201310080620.r986K1TZ085931@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Andriy Gapon Subject: Re: kern/182536: [zfs] zfs deadlock X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 06:20:01 -0000 The following reply was made to PR kern/182536; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, harrison@glsan.com Cc: Subject: Re: kern/182536: [zfs] zfs deadlock Date: Tue, 08 Oct 2013 09:13:41 +0300 Please try to obtain a crashdump. Also, this page has some useful hints a number of which could be applicable here: https://wiki.freebsd.org/AvgZfsDeadlockDebug -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Oct 8 06:34:36 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7D6ADFE6 for ; Tue, 8 Oct 2013 06:34:36 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 337F72703 for ; Tue, 8 Oct 2013 06:34:35 +0000 (UTC) Received: (qmail 39690 invoked from network); 8 Oct 2013 06:34:34 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay02.pair.com with SMTP; 8 Oct 2013 06:34:34 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r986YXoK048149; Tue, 8 Oct 2013 08:34:33 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r986YXSb048148; Tue, 8 Oct 2013 08:34:33 +0200 (CEST) (envelope-from pho) Date: Tue, 8 Oct 2013 08:34:33 +0200 From: Peter Holm To: Davide Italiano Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <20131008063433.GA47506@x2.osted.lan> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kirk McKusick , alc@freebsd.org, freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 06:34:36 -0000 On Mon, Oct 07, 2013 at 07:34:24PM +0200, Davide Italiano wrote: > > What would perhaps be better than a hardcoded reclaim age would be to use > > an LRU-type approach and perhaps set a target percent to reclaim. That is, > > suppose you were to reclaim the oldest 10% of hashes on each lowmem call > > (and make the '10%' the tunable value). Then you will always make some amount > > of progress in a low memory situation (and if the situation remains dire you > > will eventually empty the entire cache), but the effective maximum age will > > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > > throws the entire thing out on the first lowmem event. The LRU-approach would > > only throw the oldest 10% out on the first call, but eventually throw it all out > > if the situation remains dire. > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > I liked your idea more than what's available in HEAD right now and I > implemented it. > http://people.freebsd.org/~davide/review/ufs_direclaimage.diff > I was unsure what kind of heuristic I should choose to select which > (10% of) entries should be evicted so I just removed the first 10% > ones from the head of the ufs_dirhash list (which should be the > oldest). > The code keeps rescanning the cache until 10% (or, the percentage set > via SYSCTL) of the entry are freed, but probably we can discuss if > this limit could be relaxed and just do a single scan over the list. > Unfortunately I haven't a testcase to prove the effectiveness (or > non-effectiveness) of the approach but I think either Ivan or Peter > could be able to give it a spin, maybe. > I gave this patch a spin for 12 hours without finding any problems. I can do more testing at a later time, if you want to. - Peter From owner-freebsd-fs@FreeBSD.ORG Tue Oct 8 11:25:56 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57789478; Tue, 8 Oct 2013 11:25:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AFF032A2A; Tue, 8 Oct 2013 11:25:55 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id x19so5791072qcw.16 for ; Tue, 08 Oct 2013 04:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GTkq7YZP3xrS5a8abx+BYxsqk9e0kg+3EXianFQwyTY=; b=C0bYUk3GX4uR1roZj6IxAQCtNz5xlZnyAbjguIBopr1UsQ14Z7B54dfyt1MHiaQVhe XIgT53Q9ID6c9w1B2cT3kJKPgExKOR9sGYSMst9tXuZTo1t8m+15m+gj9JmOuZ3vnET/ HIYde8haYlyYdtHkp9Pwm/7YbObzMl8Fe9rMsjppKgi4mswgXRj62lesZMNHoaMPAmnz O2eK3SWdQZinHlF7s2txEWVC8fYC2rKhpcV1ZFPiIGbG93SGEciM1EXe/M+/I246l+Mv UC/o5EN4awuluPKpVa1Cbs6yjW3KWSx1mc4jr78gDQdmsgJcekOy0GE/fGjmAJFgTGz5 bBxA== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr2957666qad.76.1381231554854; Tue, 08 Oct 2013 04:25:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 8 Oct 2013 04:25:54 -0700 (PDT) In-Reply-To: <20131008063433.GA47506@x2.osted.lan> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> Date: Tue, 8 Oct 2013 04:25:54 -0700 X-Google-Sender-Auth: wahWjwqMNpWYLAzRpvhNwymuofc Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Adrian Chadd To: Peter Holm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Davide Italiano , Kirk McKusick , Alan Cox , freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:25:56 -0000 Hi, Please try it out on a -10 VM with something RAM limited - say, 128mb w/ GENERIC. See how it behaves. I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not to break that before releng/10 is cut. thanks, -adrian On 7 October 2013 23:34, Peter Holm wrote: > On Mon, Oct 07, 2013 at 07:34:24PM +0200, Davide Italiano wrote: > > > What would perhaps be better than a hardcoded reclaim age would be to > use > > > an LRU-type approach and perhaps set a target percent to reclaim. > That is, > > > suppose you were to reclaim the oldest 10% of hashes on each lowmem > call > > > (and make the '10%' the tunable value). Then you will always make > some amount > > > of progress in a low memory situation (and if the situation remains > dire you > > > will eventually empty the entire cache), but the effective maximum age > will > > > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > > > throws the entire thing out on the first lowmem event. The > LRU-approach would > > > only throw the oldest 10% out on the first call, but eventually throw > it all out > > > if the situation remains dire. > > > > > > -- > > > John Baldwin > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > I liked your idea more than what's available in HEAD right now and I > > implemented it. > > http://people.freebsd.org/~davide/review/ufs_direclaimage.diff > > I was unsure what kind of heuristic I should choose to select which > > (10% of) entries should be evicted so I just removed the first 10% > > ones from the head of the ufs_dirhash list (which should be the > > oldest). > > The code keeps rescanning the cache until 10% (or, the percentage set > > via SYSCTL) of the entry are freed, but probably we can discuss if > > this limit could be relaxed and just do a single scan over the list. > > Unfortunately I haven't a testcase to prove the effectiveness (or > > non-effectiveness) of the approach but I think either Ivan or Peter > > could be able to give it a spin, maybe. > > > > I gave this patch a spin for 12 hours without finding any problems. > I can do more testing at a later time, if you want to. > > - Peter > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Tue Oct 8 11:33:00 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 70213ABF; Tue, 8 Oct 2013 11:33:00 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C489D2AD2; Tue, 8 Oct 2013 11:32:59 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id e13so4242044vbg.31 for ; Tue, 08 Oct 2013 04:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OuHr7TWex/Sbadt7vrAlQRrC2ZPkTHCJis0MrkCsIBA=; b=T4onWRFk4+At0+tuuBRE2i1hM2AjKVhDBYeNXu45f7FK9EJZnrwOz/8Z08fscGFoj+ /MjIL2EumB5pfHQZD5HCw1jWVuJO69U3zeq3Pg+v+cPDI27e4tzJvoOBcXQGfbp1CMr+ v8zHA2IJAxmbL8OjSQB8FA5t9wm05ZAF/WdDsKt2RILsoH0NFj5DXXUKq8qZF8LpO8Jd TywhP0OByWyd1G3fjXvuSV0jZhwR8/B1nRvKG1J+YoMMLOqJe19aw/JdC+Tn79PsaGDT 5mOZ0HWPzH9P7c7YVmt5+YZ75bXqMoCz91B6+18O3KX/AQoZfa2qdYgLMe4QYigVt5Rd e/rQ== MIME-Version: 1.0 X-Received: by 10.220.188.66 with SMTP id cz2mr659434vcb.33.1381231978876; Tue, 08 Oct 2013 04:32:58 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 8 Oct 2013 04:32:58 -0700 (PDT) In-Reply-To: References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> Date: Tue, 8 Oct 2013 13:32:58 +0200 X-Google-Sender-Auth: 7APWatQsQOZLqatgZexpPWzu7rc Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , Alan Cox , freebsd-fs@freebsd.org, Ivan Voras , freebsd-hackers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:33:00 -0000 On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd wrote: > Hi, > Hi Adrian, > Please try it out on a -10 VM with something RAM limited - say, 128mb w/ > GENERIC. See how it behaves. > > I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not > to break that before releng/10 is cut. > > thanks, > > This is not supposed to hit 10-STABLE, at least not before proper review. This is the reason why it was proposed on mailing lists. Also, if you read the patch you'll end up with realizing this should behave better on low memory environment because it unconditionally cleans 10% of the cache every time. Previous changes in this area just did the opposite keeping a lot more of memory around. I hope this makes sense to you. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-fs@FreeBSD.ORG Tue Oct 8 11:38:20 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3610FEA0; Tue, 8 Oct 2013 11:38:20 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A5A02B43; Tue, 8 Oct 2013 11:38:19 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id lf11so3444604vcb.21 for ; Tue, 08 Oct 2013 04:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DtdxaSAVu0oktcCEgkGmYves7yulDyYjpWITeJaXbeU=; b=aUb8m80OAsbIfAHNx6JYjiGQXtJCkU8CFlUw8S0ryyUSdDrqaosHaH70oXm3er8dsA ab/TUk8B4IKMgdn3Sa2z35vBKF51YBEVCq0selTACiFNw1W1HwQb8pg7xY4FPJu10MEN Mi64i7HsxhJ1a20UDCA2HLnMzo0BXVimaXG7M/KrcHkWPFyJ27wcMZ8SPbOqv/yn3lfx NuCsED5JnweHDEJBRvj/TxdU9XvOQoxsyAVulDEkytqbBw1E51r5iZRUkxDV9mQsQn5g ziEPx7IGtVGlaa7JMt/0HQ6OeFBPBnklLafsZ2S4S4xh6ifSvxc3agoBTixQBDUCqftF 4DwQ== MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr685978vcb.5.1381232298597; Tue, 08 Oct 2013 04:38:18 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 8 Oct 2013 04:38:18 -0700 (PDT) In-Reply-To: References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> Date: Tue, 8 Oct 2013 13:38:18 +0200 X-Google-Sender-Auth: HazPPss71MrSAW3kYkcAXl1fkrA Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , Alan Cox , freebsd-fs@freebsd.org, Ivan Voras , freebsd-hackers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:38:20 -0000 On Tue, Oct 8, 2013 at 1:32 PM, Davide Italiano wrote: > On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd wrote: >> Hi, >> > > Hi Adrian, > >> Please try it out on a -10 VM with something RAM limited - say, 128mb w/ >> GENERIC. See how it behaves. >> >> I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not >> to break that before releng/10 is cut. >> >> thanks, >> >> > > This is not supposed to hit 10-STABLE, at least not before proper > review. This is the reason why it was proposed on mailing lists. Also, > if you read the patch you'll end up with realizing this should behave > better on low memory environment because it unconditionally cleans 10% > of the cache every time. Previous changes in this area just did the > opposite keeping a lot more of memory around. I hope this makes sense > to you. > > Thanks, > > -- > Davide > > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare Also, right now you can set up a value which indicates the percentage of memory you can reclaim. It's 10% by default, but we can discuss if this could be adjusted to a more reasonable default. Feel free to give your opinion. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-fs@FreeBSD.ORG Tue Oct 8 18:00:02 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF94C542 for ; Tue, 8 Oct 2013 18:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92B0F24A9 for ; Tue, 8 Oct 2013 18:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r98I01TL052844 for ; Tue, 8 Oct 2013 18:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r98I018m052843; Tue, 8 Oct 2013 18:00:01 GMT (envelope-from gnats) Date: Tue, 8 Oct 2013 18:00:01 GMT Message-Id: <201310081800.r98I018m052843@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Subject: Re: kern/121385: [unionfs] unionfs cross mount -> kernel panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:00:02 -0000 The following reply was made to PR kern/121385; it has been noted by GNATS. From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= To: bug-followup@freebsd.org, rick@wirelessleiden.nl Cc: Subject: Re: kern/121385: [unionfs] unionfs cross mount -> kernel panic Date: Tue, 8 Oct 2013 19:53:16 +0200 Hi, this problem is still reproductible on 10.0-ALPHA4. Regards, Olivier From owner-freebsd-fs@FreeBSD.ORG Wed Oct 9 14:40:49 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A2CE0575 for ; Wed, 9 Oct 2013 14:40:49 +0000 (UTC) (envelope-from piotr.kucharski@42.pl) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C02D2BE1 for ; Wed, 9 Oct 2013 14:40:48 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id c11so858581lbj.13 for ; Wed, 09 Oct 2013 07:40:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tX/k2qiGaKg5yqKxa5WeOgUwYvybOTHdeXsh005ddtQ=; b=h4wlruPhT6ylfgckMd2TUwSiZdJ+O7LMglf9jvld3HYY1x7D4hXERnVYNhpBJZWcYJ 7AQN9OWXH1KJpjhewHMPCWo4TBipG0D86LITgmWC7s8poxe0BEqab1A9ljjqTvTS6Jfo CTPeITGzN8BVqwoUgSfi0ksuzxR0GAuYUtFPsAlzO/KG2UOX8U3YdkwPXjTrWyLHh4qq vSRcNx7MZcftxAYAKBPIps6GP6YiLr35sun9uH4Q11Ivobzj88jdxde6i90/97xfpuOe q+sddE2j/uf0LAbColGcqUqyZS9MtGyLyMmzY3NS5bcUuQ4FyqgAMWl9BD0v+RAd6lPL 2NCQ== X-Gm-Message-State: ALoCoQkepAXIB4Ye0Tw51RYEVTQ6oi+hAIJ/0qOIUPL1Lcb3cr1VotUn7PWauywdtTPdqq0uGn7F X-Received: by 10.152.170.233 with SMTP id ap9mr318867lac.51.1381329160458; Wed, 09 Oct 2013 07:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.12.225 with HTTP; Wed, 9 Oct 2013 07:32:00 -0700 (PDT) X-Originating-IP: [2620:0:105f:a:dd4d:49f3:bbc8:d2be] In-Reply-To: References: From: Piotr Kucharski Date: Wed, 9 Oct 2013 16:32:00 +0200 Message-ID: Subject: Re: very slow zfs scrub To: Adam Vande More Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:40:49 -0000 I was checking on it infrequently and now, almost 3 years later, it seems to have been fixed. :) Scrub in progress for 50h, 6.86T scanned out of 11.6T at 40M/s, 34h43m to go, 0 repaired, 59.18% done. Each 0.01T varies in speed, from 5M/s (fortunately, very rare) to 85M/s, but average of 40M/s is good enough to let it finish (for the first time in this filesystem history! :>) I did not change hardware nor ggate setup, "only" FreeBSD got upgraded, now it is FreeBSD 9.1-STABLE #75 r251912 with no patches. Just informing so it does not scare people if they stumble upon this thread. :) On 19 May 2011 18:29, Piotr Kucharski wrote: > On Thu, Feb 24, 2011 at 21:00, Adam Vande More > wrote: > >> Wow! What does scrub do that it slows ggate drive almost to halt? > >> > >> What can I do to fix it? > > > > I think network latency is going to have huge impact on performance here. > > Have you tried any ggate or nic tuning? Would HAST be an option for > you? I > > think it has more performance thought put into it. > > > > Well, the network seems rather idle, host and client share the same > 1Gb LAN (not sure if the same switch, though) with <0.2ms rtt for 1k > packets in ping. When not scrubbing, sequential reads are > satisfactory. I'm inclined to think some read or write pattern of > scrub that is causing ggate to suck immensely. :/ > From owner-freebsd-fs@FreeBSD.ORG Wed Oct 9 17:09:59 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43DF25DA for ; Wed, 9 Oct 2013 17:09:59 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18A032643 for ; Wed, 9 Oct 2013 17:09:58 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id r10so1225352pdi.0 for ; Wed, 09 Oct 2013 10:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=plVm7EoTfGfM4DL8EQps41iRn5DmKDRQPIlj4i67HMo=; b=Co7idGovewXPeim8GJI1o6lJ+IJlyxhaJkzaSenab8Ake4r3DJB81a5L4mtrkO9ZGo yC4kLng8w0hOSC2tm9aLFNO+JaF1b78p9pVAJ48WIpCzPT1yZItknYuiyqm0iPvrc4st l6n6/dSxLZwohA9NwiSziGKcpWjWftsoRLpx4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=plVm7EoTfGfM4DL8EQps41iRn5DmKDRQPIlj4i67HMo=; b=OoNnpMWP+4QFC5e+r02KkHpURveXfRSsNOx4eh2MopOTRPBipRPn+/AMB1BvU+QFCG xd1zJU3xYc57fWYJwy0NDNpMnjWNZurhqCymmHdauX8w4XFgYrrfHM1UxV8bhcvTM/1K V4EhziVhS94ww103699qtJRjJCrJ6hAh83uu5fgGg0mcR9KLqFsLNzeBmMRhSa4YQ3CW 4p8vIw+qFI9rDJQyG3xs6rdPgix+EumNga/2tnQNqh31aSctLkjBqT3+tNj0y0ZiMX2U lMQzOMmU7PDNDwSu51D006Q2oziLsXFBuo9koi1rZSa6jXaQwSKNsxu9Sh9N/hxJq2p8 AvqA== X-Gm-Message-State: ALoCoQnKSkSkUMcXCfmsKFXAybXOYBcy/HR3NW3ln+2J+5vzmHqxMSeYp2fAD5cr1k0KD1PEiIT3 MIME-Version: 1.0 X-Received: by 10.69.0.103 with SMTP id ax7mr3024340pbd.188.1381338597566; Wed, 09 Oct 2013 10:09:57 -0700 (PDT) Received: by 10.70.80.40 with HTTP; Wed, 9 Oct 2013 10:09:57 -0700 (PDT) In-Reply-To: <20131009164942.GA1397@garage.freebsd.pl> References: <52557FB9.9090409@cos.ru> <525585F2.2010202@o2.pl> <20131009164942.GA1397@garage.freebsd.pl> Date: Wed, 9 Oct 2013 10:09:57 -0700 Message-ID: Subject: Re: [zfs] BSD ZFS vs. illumos ZFS From: Matthew Ahrens To: illumos-zfs , freebsd-fs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:09:59 -0000 On Wed, Oct 9, 2013 at 9:49 AM, Pawel Jakub Dawidek wrote= : > On Wed, Oct 09, 2013 at 06:36:02PM +0200, Radio m=C5=82odych bandyt=C3=B3= w wrote: > > > > Openzfs has a nice feature comparison: > > http://open-zfs.org/wiki/Features > > It clearly wasn't done by a FreeBSD person:) > > The features available only in FreeBSD: > - TRIM support (actually also in ZoL, AFAIK). > - Ability to boot from any ZFS pool (other platforms are limited to one > top-level vdev which can be either disk or a mirror (I hope that's > correct)). > - Quick listing when using options '-o name -s name' - it is at least > 100 times faster than alternatives. Very handy when there is huge > number of snapshots. > - ZFS-super-owner - allows regular users to perform file system > operations as root. This is possible when the file system was mounted > by the user, the user is owner of this file system (we force nosuid > option then). Used in FreeBSD netperf cluster, so regular users can > installworld (which set proper ownership of files) to their netbooted > datasets from a build machine. > > I'm sure I'm missing some. > > PS. Yes, I know I should just put it onto wiki, but if anyone has some > spare cycles I'd be grateful for doing it. > > I added it to the Talk page (http://www.open-zfs.org/wiki/Talk:Features). Would be great if someone from the FreeBSD community could take the time to verify, format and document these on the Features page. --matt From owner-freebsd-fs@FreeBSD.ORG Wed Oct 9 17:34:54 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 59603152 for ; Wed, 9 Oct 2013 17:34:54 +0000 (UTC) (envelope-from tim@cook.ms) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 178222836 for ; Wed, 9 Oct 2013 17:34:53 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id p13so756332vbe.33 for ; Wed, 09 Oct 2013 10:34:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=++HQ9qIEGH3he5QOUQR4HZh1NiRisd35k+yxFT2hVUk=; b=jOBKbuIZsMumV88rlbsJvxL8kZtRnjUybZVYYysqghOO2Wmy7md8lJFmDywLb3R429 jUH0QXvnVdEzZ1GuoSrVHm+S/bJV4GQoFhMjECNPDc7+fFgXiHQ1txSeqQdbkIWd9V2s j1oL0Pj5qeZMY8Xan3FfCDgenkqytAPyc41+pAvK33NFljmfba0ymoRb8bcn/635aNhk 05Z2B4M99ckSq8CeD7Ua8AavovyzWjQfn2oNQQJeGqI9V2pQJDs9MCjo8rlk8qIfWXAA Hm17fXVsvChGCjKUCWQdF4f/OXnbAZu6PKAqd5R4w4CJteoroWPWWeNMY6zu+EoXebEE Os8w== X-Gm-Message-State: ALoCoQmfEmz0O8+4fauZQThNPp9+O6chZVBy8M46fdRIOKYEd+RHjCZTkWyPMq8iX9PVStSdxxC4 X-Received: by 10.52.24.48 with SMTP id r16mr45880vdf.59.1381340086995; Wed, 09 Oct 2013 10:34:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.72.228 with HTTP; Wed, 9 Oct 2013 10:34:26 -0700 (PDT) In-Reply-To: References: <52557FB9.9090409@cos.ru> <525585F2.2010202@o2.pl> <20131009164942.GA1397@garage.freebsd.pl> From: Tim Cook Date: Wed, 9 Oct 2013 12:34:26 -0500 Message-ID: Subject: Re: [zfs] BSD ZFS vs. illumos ZFS To: "zfs@lists.illumos.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:34:54 -0000 On Wed, Oct 9, 2013 at 12:09 PM, Matthew Ahrens wrote= : > > > > On Wed, Oct 9, 2013 at 9:49 AM, Pawel Jakub Dawidek wrot= e: > >> On Wed, Oct 09, 2013 at 06:36:02PM +0200, Radio m=C5=82odych bandyt=C3= =B3w wrote: >> > >> > Openzfs has a nice feature comparison: >> > http://open-zfs.org/wiki/Features >> >> It clearly wasn't done by a FreeBSD person:) >> >> The features available only in FreeBSD: >> - TRIM support (actually also in ZoL, AFAIK). >> - Ability to boot from any ZFS pool (other platforms are limited to one >> top-level vdev which can be either disk or a mirror (I hope that's >> correct)). >> - Quick listing when using options '-o name -s name' - it is at least >> 100 times faster than alternatives. Very handy when there is huge >> number of snapshots. >> - ZFS-super-owner - allows regular users to perform file system >> operations as root. This is possible when the file system was mounted >> by the user, the user is owner of this file system (we force nosuid >> option then). Used in FreeBSD netperf cluster, so regular users can >> installworld (which set proper ownership of files) to their netbooted >> datasets from a build machine. >> >> I'm sure I'm missing some. >> >> PS. Yes, I know I should just put it onto wiki, but if anyone has some >> spare cycles I'd be grateful for doing it. >> >> > I added it to the Talk page (http://www.open-zfs.org/wiki/Talk:Features). > Would be great if someone from the FreeBSD community could take the time > to verify, format and document these on the Features page. > > --matt > > >From a downside perspective I beleive FreeBSD still has no solid block target stack. I believe SpectraLogic gave some code to the effort but it's not yet fully baked? There's also no ALUA support that I'm aware of - GEOM only supports active/passive pathing. >From the NAS side of things, FreeBSD has no concept of an in-kernel licensed CIFS stack, it relies on SAMBA. The one thing I would say on this front is it's likely to be less of a concern as SAMBA embraces SMB3. I don't see any way that the in-kernel stack in illumos is getting smb3 support unless there's work and money behind it I'm not aware of. I also don't believe FreeBSD has any support for nfsv4 or 4.1/pnfs. It's admittedly been a while since I've played with running it as a server so some or all of the above may have been addressed. I'll leave it to someone like Pawel to correct me where I'm wrong. --Tim From owner-freebsd-fs@FreeBSD.ORG Wed Oct 9 18:07:21 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA7B3BB4 for ; Wed, 9 Oct 2013 18:07:21 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE3F2A3F for ; Wed, 9 Oct 2013 18:07:21 +0000 (UTC) Received: by mail-yh0-f54.google.com with SMTP id b20so261116yha.13 for ; Wed, 09 Oct 2013 11:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9EJwuMRH9Ic6njSOta1E+IKD9uy7Gjk6Q32U79tVYwA=; b=wxlQUCytsuSe3gEyXDWkutzp6y0L+T3T5PPt/wHFCbiftuB0uvhUxOQYCIQUXNc5Rv YPqZ7zcNqKMUNZURkhiy2MJWWa7JhbQDuD1xxlQmQwVkq7h5vkECMXEQ+VkwiIrS/Zxv sQItHTkUtdD3wGPB01x4IF4WonVzbH591Vs7OrY4KI1USPW3W0EOoVSN/5HoO7jzx7/A XWt8uo/FTfHkbTwfPr0eg673ni9u7n7NGKSQMWkQpYACbVHeW2LYgGCBCc6yIP7Clv/I yzh9lq8682k9dLFKLQBEiJz8Mq9jiRBe/8gnnsEHyGmbiJV22UW30BhEuUJeAqbr/Mbw e91w== MIME-Version: 1.0 X-Received: by 10.236.193.42 with SMTP id j30mr106606yhn.192.1381342040710; Wed, 09 Oct 2013 11:07:20 -0700 (PDT) Received: by 10.49.39.33 with HTTP; Wed, 9 Oct 2013 11:07:20 -0700 (PDT) In-Reply-To: References: <52557FB9.9090409@cos.ru> <525585F2.2010202@o2.pl> <20131009164942.GA1397@garage.freebsd.pl> Date: Wed, 9 Oct 2013 11:07:20 -0700 Message-ID: Subject: Re: [zfs] BSD ZFS vs. illumos ZFS From: Freddie Cash To: zfs@lists.illumos.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:07:21 -0000 On Wed, Oct 9, 2013 at 10:34 AM, Tim Cook wrote: > From a downside perspective I beleive FreeBSD still has no solid block > target stack. I believe SpectraLogic gave some code to the effort but it'= s > not yet fully baked? There's also no ALUA support that I'm aware of - GE= OM > only supports active/passive pathing. > > From the NAS side of things, FreeBSD has no concept of an in-kernel > licensed CIFS stack, it relies on SAMBA. The one thing I would say on th= is > front is it's likely to be less of a concern as SAMBA embraces SMB3. I > don't see any way that the in-kernel stack in illumos is getting smb3 > support unless there's work and money behind it I'm not aware of. > > I also don't believe FreeBSD has any support for nfsv4 or 4.1/pnfs. It's > admittedly been a while since I've played with running it as a server so > some or all of the above may have been addressed. I'll leave it to someo= ne > like Pawel to correct me where I'm wrong. > =E2=80=8BFreeBSD has NFSv4 client and server support. Has for awhile now. = I believe it's experimental in 8.x and default in 9.x? And Rick Maclem (hope I spelt that right) has NFSv4.1 client support available for testing in 10.x? At least, I vaguely remember a head's up about it around a month or so ago. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed Oct 9 18:29:34 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 31E7C7C7 for ; Wed, 9 Oct 2013 18:29:34 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (ns1.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A19F2BAB for ; Wed, 9 Oct 2013 18:29:33 +0000 (UTC) Received: from somers-latitude-e6510.sldomain.com (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.5) with ESMTP id r99ITPNK014402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Oct 2013 12:29:26 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [zfs] BSD ZFS vs. illumos ZFS From: "Justin T. Gibbs" In-Reply-To: Date: Wed, 9 Oct 2013 12:29:20 -0600 Message-Id: <1FBB7450-3AC9-4180-9E80-842FE5BEFDCC@scsiguy.com> References: <52557FB9.9090409@cos.ru> <525585F2.2010202@o2.pl> <20131009164942.GA1397@garage.freebsd.pl> To: zfs@lists.illumos.org X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (aslan.scsiguy.com [70.89.174.89]); Wed, 09 Oct 2013 12:29:26 -0600 (MDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:29:34 -0000 On Oct 9, 2013, at 11:34 AM, Tim Cook wrote: >=20 >=20 > On Wed, Oct 9, 2013 at 12:09 PM, Matthew Ahrens = wrote: >=20 >=20 >=20 > On Wed, Oct 9, 2013 at 9:49 AM, Pawel Jakub Dawidek = wrote: > On Wed, Oct 09, 2013 at 06:36:02PM +0200, Radio m=C5=82odych bandyt=C3=B3= w wrote: > > > > Openzfs has a nice feature comparison: > > http://open-zfs.org/wiki/Features >=20 > It clearly wasn't done by a FreeBSD person:) >=20 > The features available only in FreeBSD: > - TRIM support (actually also in ZoL, AFAIK). > - Ability to boot from any ZFS pool (other platforms are limited to = one > top-level vdev which can be either disk or a mirror (I hope that's > correct)). > - Quick listing when using options '-o name -s name' - it is at least > 100 times faster than alternatives. Very handy when there is huge > number of snapshots. > - ZFS-super-owner - allows regular users to perform file system > operations as root. This is possible when the file system was = mounted > by the user, the user is owner of this file system (we force nosuid > option then). Used in FreeBSD netperf cluster, so regular users can > installworld (which set proper ownership of files) to their = netbooted > datasets from a build machine. >=20 > I'm sure I'm missing some. >=20 > PS. Yes, I know I should just put it onto wiki, but if anyone has some > spare cycles I'd be grateful for doing it. >=20 >=20 > I added it to the Talk page = (http://www.open-zfs.org/wiki/Talk:Features). Would be great if someone = from the FreeBSD community could take the time to verify, format and = document these on the Features page. >=20 > --matt >=20 >=20 > =46rom a downside perspective I beleive FreeBSD still has no solid = block target stack. A new, in kernel, iSCSI target and initiator stack (funded by the = FreeBSD Foundation) is available in FreeBSD/head and will be included in = FreeBSD 10. It makes use of the FreeBSD CAM Target Layer (CTL) stack = (sponsored by Copan/SGI and SpectraLogic) which is similar to COMSTAR. > I believe SpectraLogic gave some code to the effort but it's not yet = fully baked? The code from Spectra makes block serving more efficient. It is fully = baked, but not yet upstreamed. > There's also no ALUA support that I'm aware of - GEOM only supports = active/passive pathing. >=20 > =46rom the NAS side of things, FreeBSD has no concept of an in-kernel = licensed CIFS stack, it relies on SAMBA. Spectra relies on the Likewise stack. If there are others interested in = running this on FreeBSD, please contact me. We've been planning for = some time to push our version of Likewise out on GitHub or something = similar to get more collaboration on improving it. Although not in = kernel, it does have very good performance. > The one thing I would say on this front is it's likely to be less of = a concern as SAMBA embraces SMB3. I don't see any way that the = in-kernel stack in illumos is getting smb3 support unless there's work = and money behind it I'm not aware of. So long as Samba remains GPLv3, there will be interest in developing an = alternative. -- Justin From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 07:39:01 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7226450C for ; Thu, 10 Oct 2013 07:39:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 32694267D for ; Thu, 10 Oct 2013 07:39:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:402a:9533:e91d:ef08]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 7C8054AC2D; Thu, 10 Oct 2013 11:38:53 +0400 (MSK) Date: Thu, 10 Oct 2013 11:38:47 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1115074039.20131010113847@serebryakov.spb.ru> To: "Justin T. Gibbs" Subject: Re: [zfs] BSD ZFS vs. illumos ZFS In-Reply-To: <1FBB7450-3AC9-4180-9E80-842FE5BEFDCC@scsiguy.com> References: <52557FB9.9090409@cos.ru> <525585F2.2010202@o2.pl> <20131009164942.GA1397@garage.freebsd.pl> <1FBB7450-3AC9-4180-9E80-842FE5BEFDCC@scsiguy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 07:39:01 -0000 Hello, Justin. You wrote 9 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 22:29:= 20: JTG> Spectra relies on the Likewise stack. If there are others interested JTG> in running this on FreeBSD, please contact me. We've been planning for JTG> some time to push our version of Likewise out on GitHub or something JTG> similar to get more collaboration on improving it. Although not in JTG> kernel, it does have very good performance. BTW, all my trys to get full wire speed (1G, not 10G or 40G) from samba 3.6 on 9-STABLE fails, even for on client. iperf shows full wire speed. Local reading from FS shows 5-6 times wire speed (it is RAID), CPU is not loaded at 100% (even one core). But client only could read 30-45% of wire speed! I've tried myriad of tunes in smb.conf without any luck. And Samba guys says that "it works on Linux, we don't know about FreeBSD, fix your strange system". If new stack will be more FreeBSD-friendly, it is huge benefit for all of us. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 07:46:05 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B3B459AF for ; Thu, 10 Oct 2013 07:46:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7595C26F5 for ; Thu, 10 Oct 2013 07:46:05 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:402a:9533:e91d:ef08]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 403D74AC32; Thu, 10 Oct 2013 11:46:04 +0400 (MSK) Date: Thu, 10 Oct 2013 11:45:59 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1635456927.20131010114559@serebryakov.spb.ru> To: "Justin T. Gibbs" Subject: Re: [zfs] BSD ZFS vs. illumos ZFS In-Reply-To: <1FBB7450-3AC9-4180-9E80-842FE5BEFDCC@scsiguy.com> References: <52557FB9.9090409@cos.ru> <525585F2.2010202@o2.pl> <20131009164942.GA1397@garage.freebsd.pl> <1FBB7450-3AC9-4180-9E80-842FE5BEFDCC@scsiguy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 07:46:05 -0000 Hello, Justin. You wrote 9 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3., 22:29:= 20: JTG> Spectra relies on the Likewise stack. If there are others interested BTW, where could I read about Likewise OPEN and Likewise CIFS? I found several forum threads, one Samba article why writing samba is hard, one slides from presentation by Likewise, but all real links points to www.likewiseopen.org, which could not be resolved :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 10:00:02 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C0DEE9C for ; Thu, 10 Oct 2013 10:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 107192E5E for ; Thu, 10 Oct 2013 10:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9AA01Y6025382 for ; Thu, 10 Oct 2013 10:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9AA01Ng025381; Thu, 10 Oct 2013 10:00:01 GMT (envelope-from gnats) Date: Thu, 10 Oct 2013 10:00:01 GMT Message-Id: <201310101000.r9AA01Ng025381@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/182570: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 10:00:02 -0000 The following reply was made to PR kern/182570; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/182570: commit references a PR Date: Thu, 10 Oct 2013 09:53:54 +0000 (UTC) Author: avg Date: Thu Oct 10 09:53:46 2013 New Revision: 256259 URL: http://svnweb.freebsd.org/changeset/base/256259 Log: MFV r255257: 4082 zfs receive gets EFBIG from dmu_tx_hold_free() illumos change 14172:be36a38bac3d: illumos ZFS issues: 4082 zfs receive gets EFBIG from dmu_tx_hold_free() Please note that this change is slightly different from r255257, because it is merged out of order with other (larger) upstream changes. PR: kern/182570 Reported by: Keith White Tested by: Keith White Approved by: re (glebius) MFC after: 1 week X-MFC after: r254753 Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c Directory Properties: head/sys/cddl/contrib/opensolaris/ (props changed) Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c Thu Oct 10 09:43:15 2013 (r256258) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c Thu Oct 10 09:53:46 2013 (r256259) @@ -677,6 +677,16 @@ dmu_free_long_range(objset_t *os, uint64 if (err != 0) return (err); err = dmu_free_long_range_impl(os, dn, offset, length); + + /* + * It is important to zero out the maxblkid when freeing the entire + * file, so that (a) subsequent calls to dmu_free_long_range_impl() + * will take the fast path, and (b) dnode_reallocate() can verify + * that the entire file has been freed. + */ + if (offset == 0 && length == DMU_OBJECT_END) + dn->dn_maxblkid = 0; + dnode_rele(dn, FTAG); return (err); } Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c Thu Oct 10 09:43:15 2013 (r256258) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c Thu Oct 10 09:53:46 2013 (r256259) @@ -616,7 +616,7 @@ dmu_tx_hold_free(dmu_tx_t *tx, uint64_t */ if (dn->dn_datablkshift == 0) { if (off != 0 || len < dn->dn_datablksz) - dmu_tx_count_write(txh, off, len); + dmu_tx_count_write(txh, 0, dn->dn_datablksz); } else { /* first block will be modified if it is not aligned */ if (!IS_P2ALIGNED(off, 1 << dn->dn_datablkshift)) _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 12:44:10 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F9CD47F for ; Thu, 10 Oct 2013 12:44:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 35C0828EE for ; Thu, 10 Oct 2013 12:44:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAG+gVlKDaFve/2dsb2JhbABZgz9Sgyi9K0qBOHSCJQEBAQQBAQEgKyALGw4KAgINGQIjBgEJJgYIBwQBHASHUwMPDKZpiD8NiWuBKYsxgTSBBQEzB4JqgTkDlTpigxiLHYU2g0AgMoEDOQ X-IronPort-AV: E=Sophos;i="4.90,1071,1371096000"; d="scan'208";a="59046975" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 10 Oct 2013 08:43:01 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D7482B40AE; Thu, 10 Oct 2013 08:43:01 -0400 (EDT) Date: Thu, 10 Oct 2013 08:43:01 -0400 (EDT) From: Rick Macklem To: Freddie Cash Message-ID: <2072986787.39262172.1381408981871.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: [zfs] BSD ZFS vs. illumos ZFS MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-fs , zfs@lists.illumos.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:44:10 -0000 Freddie Cash wrote: > On Wed, Oct 9, 2013 at 10:34 AM, Tim Cook wrote: >=20 > > From a downside perspective I beleive FreeBSD still has no solid > > block > > target stack. I believe SpectraLogic gave some code to the effort > > but it's > > not yet fully baked? There's also no ALUA support that I'm aware > > of - GEOM > > only supports active/passive pathing. > > > > From the NAS side of things, FreeBSD has no concept of an in-kernel > > licensed CIFS stack, it relies on SAMBA. The one thing I would say > > on this > > front is it's likely to be less of a concern as SAMBA embraces > > SMB3. I > > don't see any way that the in-kernel stack in illumos is getting > > smb3 > > support unless there's work and money behind it I'm not aware of. > > > > I also don't believe FreeBSD has any support for nfsv4 or 4.1/pnfs. > > It's > > admittedly been a while since I've played with running it as a > > server so > > some or all of the above may have been addressed. I'll leave it to > > someone > > like Pawel to correct me where I'm wrong. > > >=20 > =E2=80=8BFreeBSD has NFSv4 client and server support. Has for awhile now= . I > believe it's experimental in 8.x and default in 9.x? >=20 > And Rick Maclem (hope I spelt that right) has NFSv4.1 client support > available for testing in 10.x? At least, I vaguely remember a head's > up > about it around a month or so ago. >=20 Yes, the 4.1 client side (including pNFS support for File Layouts only) is in 10.0. There is server code in projects/nfsv4.1-server, but it does not include pNFS (and I don't plan on trying to do pNFS support, since it is a major project). The main piece missing from the NFSv4.1 server is backchannel support (for callbacks) in sessions and I am currently working on that. rick > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 17:07:27 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ABF8DF6E for ; Thu, 10 Oct 2013 17:07:27 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (growveg-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:3d2::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69AA12BF3 for ; Thu, 10 Oct 2013 17:07:27 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VUJht-000Eaz-4o for freebsd-fs@freebsd.org; Thu, 10 Oct 2013 18:07:25 +0100 Date: Thu, 10 Oct 2013 18:07:24 +0100 From: John To: freebsd-fs@freebsd.org Subject: RAM and zfs and multiple disks Message-ID: <20131010170724.GA19751@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: john@potato.growveg.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:07:27 -0000 Hello list, I'd like to have zfs on my freebsd desktop. However, this motherboard can take 8GB RAM, max. I'd like to get 2 x4Tb drives. Realistically, do I need another motherboard? The primary reason to have ZFS is to guard against bitrot. thanks, -- John From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 17:16:49 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E898F443 for ; Thu, 10 Oct 2013 17:16:48 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB1A52C96 for ; Thu, 10 Oct 2013 17:16:48 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id x7so1017995qeu.28 for ; Thu, 10 Oct 2013 10:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QFQzpvhMAQD1kjIqBjnIBuuZQAP8rUQA4zKm8IQd6YM=; b=yoUxYItfO2Z4dGb5dDX8bZSyv8AmlaD5RB7E7fXUVhttJckC14ModiNMxp2OuVHYrc 4sT8zQS8p2ajlq+c7nPm2RwWll/vksGGtIvmYNceRO8Nq59ijbej1tqATDK/d2L/7QdF phGUll/75yHNOv3ITX2YJeyjRrhTZPigJ4m9qqva5VC1IDlP1Z1RmPDoxxOhPInwxI2N 8kfDgYxw0Fma9XhfpabzlDPkCkbj266eW8g1q3DmBtkOEfKo6pgj8SrQwqxW1omJW29a Y5zcHJDrRmVYu9CzCr4AXcbuNFtRkPBlS5ZeX7NUorxa0lVMl/bgkGTuDuQNn40I8+71 0r6w== MIME-Version: 1.0 X-Received: by 10.49.130.132 with SMTP id oe4mr3247501qeb.86.1381425407903; Thu, 10 Oct 2013 10:16:47 -0700 (PDT) Received: by 10.49.39.33 with HTTP; Thu, 10 Oct 2013 10:16:47 -0700 (PDT) In-Reply-To: <20131010170724.GA19751@potato.growveg.org> References: <20131010170724.GA19751@potato.growveg.org> Date: Thu, 10 Oct 2013 10:16:47 -0700 Message-ID: Subject: Re: RAM and zfs and multiple disks From: Freddie Cash To: john@potato.growveg.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:16:49 -0000 On Thu, Oct 10, 2013 at 10:07 AM, John wr= ote: > I'd like to have zfs on my freebsd desktop. However, > this motherboard can take 8GB RAM, max. > > I'd like to get 2 x4Tb drives. Realistically, do I > need another motherboard? The primary reason to have ZFS > is to guard against bitrot > =E2=80=8B. > I ran ZFS on a 32-bit install of FreeBSD using a 3.0 GHz P4 with only 2 GB of RAM for several years. Started with 4x 160 GB drives in a raidz1 vdev and FreeBSD 8.x with / on UFS on a USB stick. Migrated to 2x 500 GB drives in a mirror vdev and FreeBSD 9.0, still with / on UFS on a USB stick. Migrated to 4x 1.0 TB drives in 2 mirror vdevs and PC-BSD 9.1, with ZFS-on-root (no USB sticks). At this point, I switched to a 64-bit install running on an Athlon-II CPU with 4 GB of RAM. Finally, migrated to "rolling-release" of PC-BSD (which shows as TruOS in uname) based on FreeBSD 9-STABLE (post 9.1) running on a Phenom-II X4 with 8 GB of RAM. Beauty of ZFS snapshots send/recv and boot environments is that I didn't lose any data during any of the migrations, and was able to reconfigure the pool a couple of times. And switch from 32-bit to 64-bit FreeBSD (only saved /home for that one). IOW, you don't need a tonne of RAM to run ZFS. You just need to spend some time tweaking ZFS-related tunables in /boot/loader.conf to guard against lockups due to lack of kmem (really only an issue on a 32-bit system due to kmem fragmentation). And, definitely do NOT enable dedupe on a system with multiple TB of storage unless you have 16+ GB of RAM! Compression is fine (running with lz4 on my home system now; originally was lzjb+gzip). --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 20:21:23 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 250CC570 for ; Thu, 10 Oct 2013 20:21:23 +0000 (UTC) (envelope-from berend@pobox.com) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id D380C2A41 for ; Thu, 10 Oct 2013 20:21:22 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A5322D1E9; Thu, 10 Oct 2013 16:21:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date :message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=sasl; bh=hZqhaH4muXBpl94cGODSNWgowtU=; b=QA/Yrwbl/i4cKMsuUXmfRKH1f2bY E3ww+QiPYfoibCugyrmogSyTOH5z8WlFx89xOK/WTnOFH0EwpLZED5znK17uw8a5 wjo9oWfjRXcXKW2ep6dECPPqioY/OUeL76+O47FCOZnkigHUsbFI4snB8gE5NzuA gvbMtHO5EcUWi5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:message-id :from:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=qk/605 dBWa/x+oCe8Kr8GwxAfTGkbtAYq6k8ryAwY2l49cZpfr+i5NvqLVIV25V76EjIV5 Z1bpM6ZdneGjwRnKE5nrdzbeFLQi56ol6TzaSSkS9JJ7A0dslyn0uRm8PEJm/nu+ 9y8RPs65Uqz/7fbScKPJbb+4fwtdKO2ucS2ZM= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9C7A2D1E8; Thu, 10 Oct 2013 16:21:14 -0400 (EDT) Received: from bmach.nederware.nl (unknown [27.252.129.140]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPA id 078A7D1E6; Thu, 10 Oct 2013 16:21:14 -0400 (EDT) Received: from quadrio.nederware.nl (quadrio.nederware.nl [192.168.33.13]) by bmach.nederware.nl (Postfix) with ESMTP id EE0632160C; Fri, 11 Oct 2013 09:21:12 +1300 (NZDT) Received: from quadrio.nederware.nl (quadrio.nederware.nl [127.0.0.1]) by quadrio.nederware.nl (Postfix) with ESMTP id DB87841EA38D; Fri, 11 Oct 2013 09:21:12 +1300 (NZDT) Date: Fri, 11 Oct 2013 09:21:12 +1300 Message-ID: <87hacoubbb.wl%berend@pobox.com> From: Berend de Boer To: john@potato.growveg.org Subject: Re: RAM and zfs and multiple disks In-Reply-To: <20131010170724.GA19751@potato.growveg.org> References: <20131010170724.GA19751@potato.growveg.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.3 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: Xplain Technology Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Fri_Oct_11_09:21:12_2013-1"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 82A71322-31E9-11E3-8F19-0A540E5B5709-48001098!a-pb-sasl-quonix.pobox.com Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 20:21:23 -0000 --pgp-sign-Multipart_Fri_Oct_11_09:21:12_2013-1 Content-Type: text/plain; charset=US-ASCII >>>>> "John" == John writes: John> Hello list, I'd like to have zfs on my freebsd John> desktop. However, this motherboard can take 8GB RAM, max. John> I'd like to get 2 x4Tb drives. Realistically, do I need John> another motherboard? The primary reason to have ZFS is to John> guard against bitrot. By default ZFS takes most available memory, as it assumes it's an NFS server. That can be easily tuned, see vfs.zfs.arc_max. The main reason for a lot of memory is dedup. If you don't use it, I would say you have plenty. Note you can enable dedup on selected filesystems for ones where it makes sense. -- All the best, Berend de Boer --pgp-sign-Multipart_Fri_Oct_11_09:21:12_2013-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABCAAGBQJSVww4AAoJEKOfeD48G3g5gyYP/0UuQbQKLBA0mxQ9hxDIRKhm 3nB00vh3fiYay8NMzEqwLRJvlq4lZXd/HU1vhHjAcoveehajZNB8cqCx/7iFIede WC9qItLddhhPoSyCeGBVLgC6YL3gbuiYyvn72fivCLZ+jAyIkV1upHH5zJUPCrpG zUybmr5kSBKitWTC7EBvB0rVLJQxQ7yvXEpGhkJ8NzpZnzbHTg0d9GfR7qh3WDWK ykkiPlYYtN0J+oZcZW0rcWYTdWeNRdPV1ZwUeBEIh87tvxxOKp6BLGOS4EuG1MrD nOJLBzX3LdLkCWa5QdceTm/0GDvlEgXS43dDTk8hblAaItVx6ZtnJ/3vn0l9rECH Iely+yV3R3QlwzlkkVCOWVNRHDUMIGkDMhd9bL/iJApujCSy4hyk59v7aGxPMe+i qLU0LIwTt7ZCquMMmaHQ17qmd8m0v3e91+uJoec7UHTTMXPik/VV4ED4yT3KMb0a 8/ERoZPZk6dGh2KyBebAfSy005yZGevQag/fs/QfOgR9g6KDWm2yvtWm4OjmVRqD YgIDA7B4JNCWLEeQhj1okgi0yGUZH67LIhGZGd0dHThOpCBCfSVy3+ImJXG20wMf 1RPMTPwyboAsg5m3e7Hw+V+Rl4upnFBqtHYP1Bu1aQiHAWzlmjEZ7gVpsZlOMbYI vV2Z2HFzx7ORqrUAFdPv =hy8s -----END PGP SIGNATURE----- --pgp-sign-Multipart_Fri_Oct_11_09:21:12_2013-1-- From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 20:43:42 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D3558250 for ; Thu, 10 Oct 2013 20:43:42 +0000 (UTC) (envelope-from morgan@morganjones.org) Received: from paul.unrelated.org (paul.unrelated.org [97.107.135.152]) by mx1.freebsd.org (Postfix) with ESMTP id AB2142BF0 for ; Thu, 10 Oct 2013 20:43:41 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by paul.unrelated.org (Postfix) with ESMTP id AFA02377293 for ; Thu, 10 Oct 2013 16:32:15 -0400 (EDT) Received: from paul.unrelated.org ([127.0.0.1]) by localhost (paul.unrelated.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0whbogJsLW+i for ; Thu, 10 Oct 2013 16:32:13 -0400 (EDT) Received: from [10.32.22.207] (unknown [170.235.245.100]) by paul.unrelated.org (Postfix) with ESMTPSA id 23ED6376E01 for ; Thu, 10 Oct 2013 16:32:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: RAM and zfs and multiple disks From: Morgan Jones In-Reply-To: <20131010170724.GA19751@potato.growveg.org> Date: Thu, 10 Oct 2013 16:34:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131010170724.GA19751@potato.growveg.org> To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 20:43:42 -0000 I've FreeBSD with 8gb of ram and no swap for years. I'm currently on = 9.0 64-bit. I have 2 zfs pools:=20 one is a pair of 16gb thumb drives for / the other is 4x2tb + 2x500gb mirror for 10 or so mount points It runs with zero problems. In FreeBSD 8.x I had to set the arc max to = keep from memory starving other processes but 9.0 has been fine. 32-bit = was a disaster--I couldn't keep it from crashing. I'm not running dedup. -morgan On Oct 10, 2013, at 1:07 PM, John = wrote: > Hello list, >=20 > I'd like to have zfs on my freebsd desktop. However, > this motherboard can take 8GB RAM, max.=20 >=20 > I'd like to get 2 x4Tb drives. Realistically, do I > need another motherboard? The primary reason to have ZFS > is to guard against bitrot. >=20 > thanks, > --=20 > John > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 21:03:09 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CEEE3977; Thu, 10 Oct 2013 21:03:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A2DF42D9E; Thu, 10 Oct 2013 21:03:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 49CABB948; Thu, 10 Oct 2013 17:03:07 -0400 (EDT) From: John Baldwin To: Davide Italiano Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Date: Thu, 10 Oct 2013 16:29:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201309031507.33098.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310101629.56289.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 10 Oct 2013 17:03:08 -0400 (EDT) Cc: Kirk McKusick , alc@freebsd.org, freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras , pho@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:03:09 -0000 On Monday, October 07, 2013 1:34:24 pm Davide Italiano wrote: > > What would perhaps be better than a hardcoded reclaim age would be to use > > an LRU-type approach and perhaps set a target percent to reclaim. That is, > > suppose you were to reclaim the oldest 10% of hashes on each lowmem call > > (and make the '10%' the tunable value). Then you will always make some amount > > of progress in a low memory situation (and if the situation remains dire you > > will eventually empty the entire cache), but the effective maximum age will > > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > > throws the entire thing out on the first lowmem event. The LRU-approach would > > only throw the oldest 10% out on the first call, but eventually throw it all out > > if the situation remains dire. > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > I liked your idea more than what's available in HEAD right now and I > implemented it. > http://people.freebsd.org/~davide/review/ufs_direclaimage.diff > I was unsure what kind of heuristic I should choose to select which > (10% of) entries should be evicted so I just removed the first 10% > ones from the head of the ufs_dirhash list (which should be the > oldest). > The code keeps rescanning the cache until 10% (or, the percentage set > via SYSCTL) of the entry are freed, but probably we can discuss if > this limit could be relaxed and just do a single scan over the list. > Unfortunately I haven't a testcase to prove the effectiveness (or > non-effectiveness) of the approach but I think either Ivan or Peter > could be able to give it a spin, maybe. I think this looks good. One cosmetic nit is that I think this: if (!try_lock()) continue; else memfreed += ufsdirhash_destroy(); Looks a bit odd. I would either drop the else (which the old code did in its failsafe case) or just do this: if (try_lock()) memfreed += ufsdirhash_destroy(); -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Oct 10 22:38:43 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 67B81741 for ; Thu, 10 Oct 2013 22:38:43 +0000 (UTC) (envelope-from lkchen@ksu.edu) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 297C62437 for ; Thu, 10 Oct 2013 22:38:42 +0000 (UTC) Received: from BN1PR05MB264.namprd05.prod.outlook.com (10.141.65.26) by BN1PR05MB262.namprd05.prod.outlook.com (10.141.65.20) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 10 Oct 2013 22:38:34 +0000 Received: from BN1PR05MB264.namprd05.prod.outlook.com ([10.141.65.26]) by BN1PR05MB264.namprd05.prod.outlook.com ([10.141.65.26]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 22:38:35 +0000 From: Lawrence Chen To: "freebsd-fs@freebsd.org" Subject: RE: RAM and zfs and multiple disks Thread-Topic: RAM and zfs and multiple disks Thread-Index: AQHOxds8JZjJ9r5/Qk2N1XpVIGDhepnuZGUAgAAflcM= Date: Thu, 10 Oct 2013 22:38:34 +0000 Message-ID: <08bab77efc4a4bdabc399c6576e3420a@BN1PR05MB264.namprd05.prod.outlook.com> References: <20131010170724.GA19751@potato.growveg.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.130.0.181] x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(24454002)(54316002)(56776001)(85306002)(81686001)(76482001)(65816001)(66066001)(80022001)(74366001)(79102001)(77982001)(63696002)(59766001)(15975445006)(81816001)(74876001)(74706001)(83072001)(69226001)(15202345003)(47736001)(49866001)(50986001)(47976001)(46102001)(51856001)(53806001)(4396001)(74662001)(74502001)(19580405001)(83322001)(75432001)(54356001)(80976001)(19580395003)(47446002)(31966008)(81542001)(74316001)(76796001)(76786001)(76576001)(81342001)(33646001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB262; H:BN1PR05MB264.namprd05.prod.outlook.com; CLIP:129.130.0.181; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ksu.edu X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 22:38:43 -0000 I have a couple of SFF Atom D2700's, so max memory is 4GB. That I've been = running as headless servers.... Were FreeBSD 9.1, upgraded to 9.2 last wee= kend. Though just a couple of 120GB SSDs in them. Been going pretty goo= d.=0A= =0A= dedup is probably out, though they say L2ARC can help....no plans to add mo= re storage to these.=0A= =0A= One of the servers is really busy (cacti)....load is usually 12+, since upg= rading to FreeBSD 9.2 and switching to lz4....load is often just under 10..= ..=0A= =0A= --=0A= Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator=0A= For: Enterprise Server Technologies (EST) -- & SafeZone Ally=0A= =0A= ________________________________________=0A= From: owner-freebsd-fs@freebsd.org on behalf= of Morgan Jones =0A= Sent: Thursday, October 10, 2013 15:34=0A= To: freebsd-fs@freebsd.org=0A= Subject: Re: RAM and zfs and multiple disks=0A= =0A= I've FreeBSD with 8gb of ram and no swap for years. I'm currently on 9.0 6= 4-bit.=0A= =0A= I have 2 zfs pools:=0A= one is a pair of 16gb thumb drives for /=0A= the other is 4x2tb + 2x500gb mirror for 10 or so mount points=0A= =0A= It runs with zero problems. In FreeBSD 8.x I had to set the arc max to kee= p from memory starving other processes but 9.0 has been fine. 32-bit was a= disaster--I couldn't keep it from crashing.=0A= =0A= I'm not running dedup.=0A= =0A= -morgan=0A= =0A= =0A= On Oct 10, 2013, at 1:07 PM, John wrote:= =0A= =0A= > Hello list,=0A= >=0A= > I'd like to have zfs on my freebsd desktop. However,=0A= > this motherboard can take 8GB RAM, max.=0A= >=0A= > I'd like to get 2 x4Tb drives. Realistically, do I=0A= > need another motherboard? The primary reason to have ZFS=0A= > is to guard against bitrot.=0A= >=0A= > thanks,=0A= > --=0A= > John=0A= > _______________________________________________=0A= > freebsd-fs@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/freebsd-fs=0A= > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"=0A= =0A= _______________________________________________=0A= freebsd-fs@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-fs=0A= To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"=0A= From owner-freebsd-fs@FreeBSD.ORG Fri Oct 11 00:37:00 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9251AFC3 for ; Fri, 11 Oct 2013 00:37:00 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (growveg-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:3d2::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4AFD629E8 for ; Fri, 11 Oct 2013 00:36:59 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VUQiu-000IBY-Vp for freebsd-fs@freebsd.org; Fri, 11 Oct 2013 01:36:56 +0100 Date: Fri, 11 Oct 2013 01:36:56 +0100 From: John To: freebsd-fs@freebsd.org Subject: Re: RAM and zfs and multiple disks Message-ID: <20131011003656.GA66891@potato.growveg.org> References: <20131010170724.GA19751@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 00:37:00 -0000 On Thu, Oct 10, 2013 at 10:16:47AM -0700, Freddie Cash wrote: > Beauty of ZFS snapshots send/recv and boot environments is that I didn't > lose any data during any of the migrations, and was able to reconfigure the > pool a couple of times. And switch from 32-bit to 64-bit FreeBSD (only > saved /home for that one). > > IOW, you don't need a tonne of RAM to run ZFS. You just need to spend some > time tweaking ZFS-related tunables in /boot/loader.conf to guard against > lockups due to lack of kmem (really only an issue on a 32-bit system due to > kmem fragmentation). > > And, definitely do NOT enable dedupe on a system with multiple TB of > storage unless you have 16+ GB of RAM! Compression is fine (running with > lz4 on my home system now; originally was lzjb+gzip). Thanks for the input. Can you share what your spec and tunables were? Although I have it deployed on a freebsd host machine, (where with lots of HD and RAM It Just Works), I've never deployed it on a desktop. That being said, the host needs tuning, I'd like to bring it up to 10-current though before doing that. The desktop machine currently runs 9.2 and has three x1TB disks. I've read in the literature that it's best to have them all the same size or space is lost. I have also read that for raidZ you really need more than 2 and less than 10 so maybe make the three I already have as one raidz array and get 4x 4TB and make another array. All will be SATA 2 or 3. What do you think? Basically the whole reason for me having ZFS on the desktop is guarding against bitrot and failure of a single drive in an array. I'm really happy that you've been able to move the same data across architectures - that's a relief as my desktop is getting on a bit. thanks, -- John From owner-freebsd-fs@FreeBSD.ORG Fri Oct 11 11:04:11 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D18A1F3E for ; Fri, 11 Oct 2013 11:04:11 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6185B2A7F for ; Fri, 11 Oct 2013 11:04:11 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id y6so3199088lbh.21 for ; Fri, 11 Oct 2013 04:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HEvpc8D1CQ/CRkZ7p9gcCkNfCtDyPVr5979bnwno1SU=; b=t4n2XJuVPMWk5WSOa6hsBzb82MXair7kHn4/WezF73zDNx6fuyHxR0il6VhpHKh3AB cAR11D00meLaIMEuFCkfdK3qKew6+TsdmJ48iBZs463E+3sPHvozPn02Vir6qtC5JumO GKDvP6FNOCW3xYLNiBBLN06v11Ej7R+EvKXmHhvbFK/qC6w11roncUAyLalXfraauyiU 30eNafz8m4/gx3PxQuCTQMIUisEqXniSHH0f05qeqYBPYUaKsddnYPrsyrsB/oaRLURs 7btHsu7fH6sIpIObiuQq8XGf3PdOLacA3U3U9eCt8u+OyrgZ5uC/ydBDr2pHUpu+Rnmw zGQw== MIME-Version: 1.0 X-Received: by 10.152.171.72 with SMTP id as8mr1231557lac.33.1381489449417; Fri, 11 Oct 2013 04:04:09 -0700 (PDT) Received: by 10.112.170.70 with HTTP; Fri, 11 Oct 2013 04:04:09 -0700 (PDT) In-Reply-To: <20131010170724.GA19751@potato.growveg.org> References: <20131010170724.GA19751@potato.growveg.org> Date: Fri, 11 Oct 2013 12:04:09 +0100 Message-ID: Subject: Re: RAM and zfs and multiple disks From: Tom Evans To: john@potato.growveg.org Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 11:04:11 -0000 On Thu, Oct 10, 2013 at 6:07 PM, John wrote: > Hello list, > > I'd like to have zfs on my freebsd desktop. However, > this motherboard can take 8GB RAM, max. > > I'd like to get 2 x4Tb drives. Realistically, do I > need another motherboard? The primary reason to have ZFS > is to guard against bitrot. > My home ZFS file server is a Core2 Duo with 8GB of RAM and has 12 x 1.5TB arranged in 2 x 6 disk raidz, and before the second set of disks were added it ran with only 2 GB just fine. The only ZFS setting I "had" to tweak was to limit ARC to 4 GB, in order to have plenty of free RAM: vfs.zfs.arc_max="4294967296" I say "had to", because I didn't really, I just prefer not having the ARC taking all free RAM and releasing as necessary. Depending upon your usage, you may find that the ARC is not terribly useful anyway, eg in my case there is 4 GB of ARC covering 14336 GB of data, and since my data is mainly archived binary data, I'm unlikely to re-use the same data twice in one day. Where the ARC really comes in handy for me is prefetch, loading large files into the ARC as I start reading them. Prefetching is disabled if you have less than 4 GB of RAM. Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Fri Oct 11 13:58:10 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C495B773 for ; Fri, 11 Oct 2013 13:58:10 +0000 (UTC) (envelope-from proks@skylinetele.com) Received: from mail.sky.od.ua (relay.sky.od.ua [81.25.224.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF4542704 for ; Fri, 11 Oct 2013 13:58:08 +0000 (UTC) Received: from relay.sky.od.ua (mail [81.25.224.8]) by mail.sky.od.ua (Postfix) with ESMTP id DACC0106885 for ; Fri, 11 Oct 2013 16:48:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at sky.od.ua Received: from mail.sky.od.ua ([81.25.224.8]) by relay.sky.od.ua (relay.sky.od.ua [81.25.224.8]) (amavisd-new, port 10024) with ESMTP id OpcrBv5XayUq for ; Fri, 11 Oct 2013 16:47:58 +0300 (EEST) Received: from logos.sky.od.ua (logos.sky.od.ua [81.25.224.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sky.od.ua (Postfix) with ESMTPS id 2D7AB10687B for ; Fri, 11 Oct 2013 16:47:58 +0300 (EEST) Message-ID: <5258018D.2040301@skylinetele.com> Date: Fri, 11 Oct 2013 16:47:57 +0300 From: "Prokofiev S.P." Organization: Skyline Telecom. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Mapping POSIX ACLs to NFSv4 ACLs for Samba storage Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 13:58:10 -0000 Hi all, I propose to talk about an issue. I have a task of moving data from UFS+ACLs storage to a ZFS pool. Dump/restrore is the best way. But only owner/owner_group is saved. I've written a Perl script to translate POSIX ACLs to NFSv4 ACLs. I referred to the last draft of it (http://tools.ietf.org/html/draft-iet...acl-mapping-05 ) to emulate POSIX behaviour of permissions. I got something like that, for instance: Source directory on UFS: Code: > getfacl /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ # file: /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ # owner: 10051 # group: 513 user::rwx user:10015:r-x user:10049:r-x user:10072:rwx group::--- group:544:rwx group:10008:rwx group:10131:r-x mask::rwx other::--- > getfacl -d /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ # file: /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ # owner: 10051 # group: 513 user::rwx user:10015:r-x user:10049:r-x user:10072:rwx group::--- group:544:rwx group:10008:rwx group:10131:r-x mask::rwx other::--- Target directory on ZFS: Code: # getfacl /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ # file: /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ # owner: 10051 # group: 513 owner@:--------------:fd----:deny owner@:rwxpD-aA--cC-s:fd----:allow user:10015:-w-p---A---C--:fd----:deny user:10015:r-x---a---c--s:fd----:allow user:10049:-w-p---A---C--:fd----:deny user:10049:r-x---a---c--s:fd----:allow user:10072:-------A---C--:fd----:deny user:10072:rwxpD-a---c--s:fd----:allow group@:------a---c--s:fd----:allow group:10008:rwxpD-a---c--s:fd----:allow group:544:rwxpD-a---c--s:fd----:allow group:10131:r-x---a---c--s:fd----:allow group@:rwxp---A---C--:fd----:deny group:10008:-------A---C--:fd----:deny group:544:-------A---C--:fd----:deny group:10131:-w-p---A---C--:fd----:deny everyone@:rwxp---A---C--:fd----:deny everyone@:------a---c--s:fd----:allow I was happy, but Windows made me sad. When I tried to look at permissions of a file or a directory with a Windows file browser I had warning about ordering of permissions. Then I tried to edit permissions and allowed reordering and got this result of that: Code: getfacl /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ # file: /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ # owner: 10051 # group: 513 user:10015:-w-pD--A---C--:fd----:deny user:10049:-w-pD--A---C--:fd----:deny user:10072:-------A---C--:fd----:deny group@:rwxpD--A---C--:fd----:deny group:10008:-------A---C--:fd----:deny group:544:-------A---C--:fd----:deny group:10131:-w-pD--A---C--:fd----:deny everyone@:rwxpD--A---C--:fd----:deny <<<<<<<<< owner@:rwxpD-aA--cC--:fd----:allow user:10015:r-x---a---c---:fd----:allow user:10049:r-x---a---c---:fd----:allow user:10072:rwxpD-a---c---:fd----:allow group@:------a---c---:fd----:allow group:10008:rwxpD-a---c---:fd----:allow group:544:rwxpD-a---c---:fd----:allow group:10131:r-x---a---c---:fd----:allow everyone@:------a---c---:fd----:allow But it won't work, because of (everyone@:rwxpD--A---C--:fd----:deny). It's a mess. As it turned out according to http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx it's a rule of ordering of Windows permissions. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 11 15:58:36 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 98493C39 for ; Fri, 11 Oct 2013 15:58:36 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 583472F02 for ; Fri, 11 Oct 2013 15:58:36 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id h10so2859833vbh.6 for ; Fri, 11 Oct 2013 08:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I0IJsw+NphklY93fGcDNNg7//13u4WQ0sgRgOZ1fFTw=; b=iUsgbvnw+rvW31Oa7gwgiF8vyeapn3HUMvkJBeAJIOkIRiZpypwpe+OTPUezOav560 wg2nAidspvYHuk+Hex9aZDsxwpujsxvc+ue8hNDxXv+ZChmiUhadsBI3o0VLLyfUJ93y P//VagsYbVWwCWf2Mt5QZefCwfjfGjdN5lmzROnJHAPR6dTAQ2YW0yeTv5BQn38xbFVU bIaRKOHOXRsV+c8XTiSR9EFbYKJmoFKgkPt90JKX2X0Z4i6g94LwSq6h7yb5dNNAIAAW teVsz25vtVlyAbe1H8aPA7CMslKZVGrEPLH5biqWXQUq2EejNBwzoV0N/XdqnEw3sg0x 6V7g== MIME-Version: 1.0 X-Received: by 10.52.24.4 with SMTP id q4mr1652506vdf.34.1381507115225; Fri, 11 Oct 2013 08:58:35 -0700 (PDT) Received: by 10.220.30.130 with HTTP; Fri, 11 Oct 2013 08:58:35 -0700 (PDT) In-Reply-To: References: <20131010170724.GA19751@potato.growveg.org> Date: Fri, 11 Oct 2013 11:58:35 -0400 Message-ID: Subject: Re: RAM and zfs and multiple disks From: Zaphod Beeblebrox To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: john@potato.growveg.org, FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:58:36 -0000 At home I have a large ZFS server serving up 18x 2T disks (raidZ1 x2). The server machine is core2-duo with 8G RAM and an 'em' GigE added (because the motherboard GigE was crap). I use SATA port expanders to multiply the 6 motherboard ports. The machine has a UFS boot and there is a bit of a "fight" when something uses memory and/or UFS to do something. I would have had ZFS on my desktop, but instead I use a diskless NFS setup from the ZFS server. Originally, when I setup these systems, the NFS diskless desktop was avoiding the conflict between the nvidia driver being 32 bit only and ZFS liking more memory. This is long moot, but the setup remains. The only remaining task here is to use NFSv4 diskless. I'm not sure how easy/hard that is. The root mount seems to be NFSv3. As for ZFS on desktops, all the PC-BSD setups I've done for the family are ZFS. They typically have either 2 or 4 gig of RAM. I haven't really tried a low memory ZFS (say 512 meg). They seem to run acceptably well, but they aren't really challenging anything --- running a FreeBSD/gnome or FreeBSD/KDE desktop on a machine with 2 or 4 gig of RAM is really not a challenge. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 11 18:42:16 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0DD1D32D for ; Fri, 11 Oct 2013 18:42:16 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BE022A96 for ; Fri, 11 Oct 2013 18:42:15 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id B33F0C2FB3; Fri, 11 Oct 2013 18:42:06 +0000 (UTC) Date: Fri, 11 Oct 2013 20:42:06 +0200 From: Jeremie Le Hen To: freebsd-fs@FreeBSD.org Subject: ARC_SPACE_OTHER exceeds arc_max Message-ID: <20131011184206.GA60057@caravan.chchile.org> Mail-Followup-To: freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 18:42:16 -0000 Hi, (Please Cc: me on reply, as I'm not subscribed.) On my FreeBSD 9.1 machine, roughly 2/3 of the times the daily scripts are run, my ARC size is outgrowing like crazy the vfs.zfs.arc_max being set to 536870912 (512 MB). The consquence of this is that userland processes are killed (!). OK this box has no swap space and should have but still, this sounds really crazy that a filesystem cache is able to "reclaim" memory for running processes :). I've used top -b every 30 seconds to get an idea of the system's memory, logs below. Here is also a snippet of my sysctls related to zfs: vfs.zfs.l2arc_norw: 1 vfs.zfs.l2arc_feed_again: 1 vfs.zfs.l2arc_noprefetch: 1 vfs.zfs.l2arc_feed_min_ms: 200 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_headroom: 2 vfs.zfs.l2arc_write_boost: 8388608 vfs.zfs.l2arc_write_max: 8388608 vfs.zfs.arc_meta_limit: 134217728 vfs.zfs.arc_meta_used: 236528568 vfs.zfs.arc_min: 67108864 vfs.zfs.arc_max: 536870912 debug.adaptive_machine_arch: 1 hw.machine_arch: amd64 kstat.zfs.misc.arcstats.hits: 77149964 kstat.zfs.misc.arcstats.misses: 13690743 kstat.zfs.misc.arcstats.demand_data_hits: 8073317 kstat.zfs.misc.arcstats.demand_data_misses: 274103 kstat.zfs.misc.arcstats.demand_metadata_hits: 69076639 kstat.zfs.misc.arcstats.demand_metadata_misses: 13416617 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 8 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 23 kstat.zfs.misc.arcstats.mru_hits: 33260238 kstat.zfs.misc.arcstats.mru_ghost_hits: 2830869 kstat.zfs.misc.arcstats.mfu_hits: 43889719 kstat.zfs.misc.arcstats.mfu_ghost_hits: 3452884 kstat.zfs.misc.arcstats.allocated: 14361097 kstat.zfs.misc.arcstats.deleted: 7860017 kstat.zfs.misc.arcstats.stolen: 6994054 kstat.zfs.misc.arcstats.recycle_miss: 7051205 kstat.zfs.misc.arcstats.mutex_miss: 4479 kstat.zfs.misc.arcstats.evict_skip: 4052583 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 129211340800 kstat.zfs.misc.arcstats.evict_l2_ineligible: 14336 kstat.zfs.misc.arcstats.hash_elements: 88387 kstat.zfs.misc.arcstats.hash_elements_max: 133658 kstat.zfs.misc.arcstats.hash_collisions: 14197499 kstat.zfs.misc.arcstats.hash_chains: 16044 kstat.zfs.misc.arcstats.hash_chain_max: 27 kstat.zfs.misc.arcstats.p: 188161024 kstat.zfs.misc.arcstats.c: 536870912 kstat.zfs.misc.arcstats.c_min: 67108864 kstat.zfs.misc.arcstats.c_max: 536870912 kstat.zfs.misc.arcstats.size: 534264760 kstat.zfs.misc.arcstats.hdr_size: 20228688 kstat.zfs.misc.arcstats.data_size: 406874112 kstat.zfs.misc.arcstats.other_size: 107161960 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 5 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.arcstats.duplicate_buffers: 0 kstat.zfs.misc.arcstats.duplicate_buffers_size: 0 kstat.zfs.misc.arcstats.duplicate_reads: 0 ct 8 03:00:11 CEST 2013 Mem: 97M Active, 112M Inact, 1258M Wired, 552K Cache, 482M Free ARC: 310M Total, 42M MFU, 147M MRU, 912K Anon, 20M Header, 101M Other Tue Oct 8 03:00:41 CEST 2013 Mem: 97M Active, 112M Inact, 1258M Wired, 552K Cache, 482M Free ARC: 310M Total, 42M MFU, 147M MRU, 912K Anon, 20M Header, 101M Other Tue Oct 8 03:01:11 CEST 2013 Mem: 105M Active, 114M Inact, 1274M Wired, 552K Cache, 457M Free ARC: 330M Total, 42M MFU, 159M MRU, 2241K Anon, 20M Header, 107M Other Tue Oct 8 03:01:41 CEST 2013 Mem: 105M Active, 115M Inact, 1241M Wired, 552K Cache, 490M Free ARC: 332M Total, 32M MFU, 137M MRU, 912K Anon, 21M Header, 141M Other Tue Oct 8 03:02:11 CEST 2013 Mem: 105M Active, 121M Inact, 1251M Wired, 552K Cache, 473M Free ARC: 326M Total, 34M MFU, 145M MRU, 912K Anon, 22M Header, 124M Other Tue Oct 8 03:02:42 CEST 2013 Mem: 105M Active, 121M Inact, 1247M Wired, 552K Cache, 478M Free ARC: 350M Total, 32M MFU, 143M MRU, 1265K Anon, 23M Header, 150M Other Tue Oct 8 03:03:12 CEST 2013 Mem: 104M Active, 121M Inact, 1232M Wired, 552K Cache, 493M Free ARC: 293M Total, 35M MFU, 126M MRU, 928K Anon, 24M Header, 107M Other Tue Oct 8 03:03:42 CEST 2013 Mem: 104M Active, 119M Inact, 1253M Wired, 552K Cache, 475M Free ARC: 367M Total, 37M MFU, 145M MRU, 928K Anon, 24M Header, 160M Other Tue Oct 8 03:04:12 CEST 2013 Mem: 104M Active, 119M Inact, 1284M Wired, 552K Cache, 443M Free ARC: 316M Total, 55M MFU, 157M MRU, 912K Anon, 24M Header, 78M Other Tue Oct 8 03:04:42 CEST 2013 Mem: 104M Active, 119M Inact, 1379M Wired, 552K Cache, 348M Free ARC: 413M Total, 84M MFU, 223M MRU, 1743K Anon, 24M Header, 81M Other Tue Oct 8 03:05:12 CEST 2013 Mem: 104M Active, 119M Inact, 1451M Wired, 552K Cache, 276M Free ARC: 484M Total, 106M MFU, 274M MRU, 928K Anon, 23M Header, 80M Other Tue Oct 8 03:05:42 CEST 2013 Mem: 104M Active, 119M Inact, 1451M Wired, 552K Cache, 276M Free ARC: 494M Total, 119M MFU, 261M MRU, 930K Anon, 23M Header, 90M Other Tue Oct 8 03:06:12 CEST 2013 Mem: 104M Active, 119M Inact, 1451M Wired, 552K Cache, 276M Free ARC: 501M Total, 151M MFU, 228M MRU, 1226K Anon, 24M Header, 96M Other Tue Oct 8 03:06:42 CEST 2013 Mem: 104M Active, 119M Inact, 1450M Wired, 552K Cache, 277M Free ARC: 502M Total, 191M MFU, 188M MRU, 944K Anon, 24M Header, 99M Other Tue Oct 8 03:07:12 CEST 2013 Mem: 104M Active, 119M Inact, 1451M Wired, 552K Cache, 276M Free ARC: 507M Total, 226M MFU, 153M MRU, 1094K Anon, 24M Header, 103M Other Tue Oct 8 03:07:42 CEST 2013 Mem: 104M Active, 118M Inact, 1407M Wired, 552K Cache, 321M Free ARC: 479M Total, 175M MFU, 161M MRU, 915K Anon, 25M Header, 117M Other Tue Oct 8 03:08:13 CEST 2013 Mem: 94M Active, 116M Inact, 1387M Wired, 552K Cache, 353M Free ARC: 506M Total, 90M MFU, 231M MRU, 912K Anon, 26M Header, 158M Other Tue Oct 8 03:08:43 CEST 2013 Mem: 96M Active, 117M Inact, 1351M Wired, 552K Cache, 386M Free ARC: 436M Total, 52M MFU, 231M MRU, 1322K Anon, 23M Header, 129M Other Tue Oct 8 03:09:13 CEST 2013 Mem: 95M Active, 117M Inact, 1314M Wired, 552K Cache, 423M Free ARC: 440M Total, 73M MFU, 173M MRU, 941K Anon, 23M Header, 170M Other Tue Oct 8 03:09:43 CEST 2013 Mem: 94M Active, 117M Inact, 1327M Wired, 552K Cache, 412M Free ARC: 510M Total, 80M MFU, 182M MRU, 912K Anon, 23M Header, 223M Other Tue Oct 8 03:10:13 CEST 2013 Mem: 94M Active, 117M Inact, 1276M Wired, 552K Cache, 463M Free ARC: 578M Total, 65M MFU, 150M MRU, 912K Anon, 27M Header, 336M Other Tue Oct 8 03:10:43 CEST 2013 Mem: 95M Active, 117M Inact, 1262M Wired, 552K Cache, 476M Free ARC: 585M Total, 56M MFU, 144M MRU, 913K Anon, 26M Header, 358M Other Tue Oct 8 03:11:13 CEST 2013 Mem: 103M Active, 114M Inact, 1269M Wired, 552K Cache, 464M Free ARC: 590M Total, 66M MFU, 140M MRU, 912K Anon, 26M Header, 357M Other Tue Oct 8 03:11:44 CEST 2013 Mem: 103M Active, 114M Inact, 1294M Wired, 552K Cache, 439M Free ARC: 667M Total, 70M MFU, 155M MRU, 1056K Anon, 27M Header, 415M Other Tue Oct 8 03:12:14 CEST 2013 Mem: 103M Active, 114M Inact, 1389M Wired, 552K Cache, 343M Free ARC: 792M Total, 73M MFU, 185M MRU, 1040K Anon, 27M Header, 507M Other Tue Oct 8 03:12:44 CEST 2013 Mem: 94M Active, 119M Inact, 1472M Wired, 552K Cache, 265M Free ARC: 891M Total, 82M MFU, 212M MRU, 1056K Anon, 27M Header, 568M Other Tue Oct 8 03:13:15 CEST 2013 Mem: 94M Active, 119M Inact, 1538M Wired, 544K Cache, 199M Free ARC: 951M Total, 85M MFU, 220M MRU, 928K Anon, 28M Header, 618M Other Tue Oct 8 03:13:45 CEST 2013 Mem: 136M Active, 22M Inact, 1682M Wired, 46M Cache, 65M Free ARC: 1113M Total, 90M MFU, 259M MRU, 912K Anon, 26M Header, 738M Other Tue Oct 8 03:14:15 CEST 2013 Mem: 153M Active, 3936K Inact, 1736M Wired, 36M Cache, 21M Free ARC: 1159M Total, 95M MFU, 271M MRU, 1040K Anon, 25M Header, 767M Other Tue Oct 8 03:14:46 CEST 2013 Mem: 62M Active, 15M Inact, 1808M Wired, 35M Cache, 30M Free ARC: 1213M Total, 80M MFU, 294M MRU, 819K Anon, 19M Header, 819M Other Tue Oct 8 03:15:17 CEST 2013 Mem: 61M Active, 6488K Inact, 1816M Wired, 33M Cache, 34M Free ARC: 1194M Total, 73M MFU, 293M MRU, 1040K Anon, 19M Header, 808M Other Tue Oct 8 03:15:47 CEST 2013 Mem: 75M Active, 2548K Inact, 1808M Wired, 25M Cache, 41M Free ARC: 1189M Total, 72M MFU, 292M MRU, 1475K Anon, 19M Header, 804M Other Tue Oct 8 03:16:17 CEST 2013 Mem: 75M Active, 2928K Inact, 1806M Wired, 24M Cache, 43M Free ARC: 1183M Total, 72M MFU, 291M MRU, 912K Anon, 18M Header, 801M Other Tue Oct 8 03:16:47 CEST 2013 Mem: 64M Active, 14M Inact, 1805M Wired, 24M Cache, 44M Free ARC: 1179M Total, 71M MFU, 290M MRU, 912K Anon, 18M Header, 798M Other Tue Oct 8 03:17:17 CEST 2013 Mem: 21M Active, 57M Inact, 1802M Wired, 24M Cache, 47M Free ARC: 1174M Total, 71M MFU, 289M MRU, 912K Anon, 18M Header, 795M Other Tue Oct 8 03:17:48 CEST 2013 Mem: 16M Active, 61M Inact, 1801M Wired, 24M Cache, 49M Free ARC: 1170M Total, 70M MFU, 288M MRU, 912K Anon, 18M Header, 792M Other Tue Oct 8 03:18:18 CEST 2013 Mem: 16M Active, 61M Inact, 1800M Wired, 24M Cache, 50M Free ARC: 1165M Total, 70M MFU, 287M MRU, 912K Anon, 18M Header, 789M Other Tue Oct 8 03:18:48 CEST 2013 Mem: 17M Active, 62M Inact, 1799M Wired, 23M Cache, 50M Free ARC: 1162M Total, 70M MFU, 286M MRU, 912K Anon, 18M Header, 787M Other Tue Oct 8 03:19:18 CEST 2013 Mem: 14M Active, 57M Inact, 1797M Wired, 23M Cache, 60M Free ARC: 1157M Total, 69M MFU, 285M MRU, 912K Anon, 18M Header, 784M Other Tue Oct 8 03:19:48 CEST 2013 Mem: 14M Active, 57M Inact, 1796M Wired, 23M Cache, 61M Free ARC: 1153M Total, 69M MFU, 284M MRU, 912K Anon, 18M Header, 781M Other Tue Oct 8 03:20:18 CEST 2013 Mem: 15M Active, 56M Inact, 1794M Wired, 22M Cache, 63M Free ARC: 1148M Total, 69M MFU, 283M MRU, 912K Anon, 18M Header, 777M Other Tue Oct 8 03:20:48 CEST 2013 Mem: 14M Active, 56M Inact, 1793M Wired, 22M Cache, 65M Free ARC: 1145M Total, 69M MFU, 282M MRU, 912K Anon, 18M Header, 775M Other -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-fs@FreeBSD.ORG Sat Oct 12 00:22:16 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB6F3104 for ; Sat, 12 Oct 2013 00:22:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7F42E2D73 for ; Sat, 12 Oct 2013 00:22:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAEyVWFKDaFve/2dsb2JhbABagz9Sgym9aEuBN3SCJQEBAQMBAQEBIAQnIAsFFhgCAg0ZAikBCRgBDQYIBwQBGgIEh18GDKlokjeBKYxrBn80B4JqgTkDlCiBEoN6kFODQCAxewgXIg X-IronPort-AV: E=Sophos;i="4.93,479,1378872000"; d="scan'208";a="58913073" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 11 Oct 2013 20:22:08 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id AA5B2B3F47; Fri, 11 Oct 2013 20:22:08 -0400 (EDT) Date: Fri, 11 Oct 2013 20:22:08 -0400 (EDT) From: Rick Macklem To: "Prokofiev S.P." Message-ID: <317463358.40289383.1381537328684.JavaMail.root@uoguelph.ca> In-Reply-To: <5258018D.2040301@skylinetele.com> Subject: Re: Mapping POSIX ACLs to NFSv4 ACLs for Samba storage MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 00:22:16 -0000 Prokofiev S.P. wrote: > Hi all, > > I propose to talk about an issue. I have a task of moving data from > UFS+ACLs storage to a ZFS pool. Dump/restrore is the best way. But > only > owner/owner_group is saved. I've written a Perl script to translate > POSIX ACLs to NFSv4 ACLs. I referred to the last draft of it > (http://tools.ietf.org/html/draft-iet...acl-mapping-05 > ) to > emulate > POSIX behaviour of permissions. I got something like that, for > instance: > It probably isn't of much help to you, but eventually the NFSv4 working group realized that mapping between POSIX<->NFSv4 ACLs wasn't possible. Those drafts were just failed attempts. Also, if you are going to put all deny ACEs before all allow ACEs, then the deny ACEs must not specify anything that is allowed by the allow ACEs. (I suspect you already know, but the NFSv4 ACL is evaluated by testing each ACE in order and any match for a deny ACE denies access and any matching allow ACE allows access. As such, re-ordering ACEs in the ACL changes the ACL's semantics.) Good luck with this. I do not believe there is a correct solution in general, so all you can hope for is a simple translation that captures enough semantics for your application. rick > Source directory on UFS: > Code: > > > getfacl /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ > # file: /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ > # owner: 10051 > # group: 513 > user::rwx > user:10015:r-x > user:10049:r-x > user:10072:rwx > group::--- > group:544:rwx > group:10008:rwx > group:10131:r-x > mask::rwx > other::--- > > > getfacl -d /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ > # file: /zjail/ads/home/samba-old/docs/SECRETARY/CERTIFICATE/ > # owner: 10051 > # group: 513 > user::rwx > user:10015:r-x > user:10049:r-x > user:10072:rwx > group::--- > group:544:rwx > group:10008:rwx > group:10131:r-x > mask::rwx > other::--- > > Target directory on ZFS: > Code: > > # getfacl /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ > # file: /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ > # owner: 10051 > # group: 513 > owner@:--------------:fd----:deny > owner@:rwxpD-aA--cC-s:fd----:allow > user:10015:-w-p---A---C--:fd----:deny > user:10015:r-x---a---c--s:fd----:allow > user:10049:-w-p---A---C--:fd----:deny > user:10049:r-x---a---c--s:fd----:allow > user:10072:-------A---C--:fd----:deny > user:10072:rwxpD-a---c--s:fd----:allow > group@:------a---c--s:fd----:allow > group:10008:rwxpD-a---c--s:fd----:allow > group:544:rwxpD-a---c--s:fd----:allow > group:10131:r-x---a---c--s:fd----:allow > group@:rwxp---A---C--:fd----:deny > group:10008:-------A---C--:fd----:deny > group:544:-------A---C--:fd----:deny > group:10131:-w-p---A---C--:fd----:deny > everyone@:rwxp---A---C--:fd----:deny > everyone@:------a---c--s:fd----:allow > > I was happy, but Windows made me sad. When I tried to look at > permissions of a file or a directory with a Windows file browser I > had > warning about ordering of permissions. Then I tried to edit > permissions > and allowed reordering and got this result of that: > > Code: > > getfacl /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ > # file: /zjail/ads/home/samba-new/docs/SECRETARY/CERTIFICATE/ > # owner: 10051 > # group: 513 > user:10015:-w-pD--A---C--:fd----:deny > user:10049:-w-pD--A---C--:fd----:deny > user:10072:-------A---C--:fd----:deny > group@:rwxpD--A---C--:fd----:deny > group:10008:-------A---C--:fd----:deny > group:544:-------A---C--:fd----:deny > group:10131:-w-pD--A---C--:fd----:deny > everyone@:rwxpD--A---C--:fd----:deny <<<<<<<<< > owner@:rwxpD-aA--cC--:fd----:allow > user:10015:r-x---a---c---:fd----:allow > user:10049:r-x---a---c---:fd----:allow > user:10072:rwxpD-a---c---:fd----:allow > group@:------a---c---:fd----:allow > group:10008:rwxpD-a---c---:fd----:allow > group:544:rwxpD-a---c---:fd----:allow > group:10131:r-x---a---c---:fd----:allow > everyone@:------a---c---:fd----:allow > > But it won't work, because of (everyone@:rwxpD--A---C--:fd----:deny). > It's a mess. As it turned out according to > http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx > > it's a rule of ordering of Windows permissions. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >