From owner-freebsd-fs@FreeBSD.ORG Mon Feb 27 02:22:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB55B1065672 for ; Mon, 27 Feb 2012 02:22:31 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f196.google.com (mail-iy0-f196.google.com [209.85.210.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7548FC12 for ; Mon, 27 Feb 2012 02:22:31 +0000 (UTC) Received: by iagz35 with SMTP id z35so994691iag.7 for ; Sun, 26 Feb 2012 18:22:31 -0800 (PST) Received-SPF: pass (google.com: domain of jhellenthal@dataix.net designates 10.50.34.202 as permitted sender) client-ip=10.50.34.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jhellenthal@dataix.net designates 10.50.34.202 as permitted sender) smtp.mail=jhellenthal@dataix.net; dkim=pass header.i=jhellenthal@dataix.net Received: from mr.google.com ([10.50.34.202]) by 10.50.34.202 with SMTP id b10mr15007531igj.30.1330309351069 (num_hops = 1); Sun, 26 Feb 2012 18:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=groObZU2raZMm1Aerp2KWRBA5zW2Adolns7TCV79bjA=; b=JNpEfhPNL/TQQ7Z7WUlvbE+vK4eaGjIAz516P+5rhNG1NkdUQ3oa6AYv8CYUGYKqr6 s4SrxiRgZMd6Q12rs/aWgktQ6lMXlq+I1ayA5k5ypQVmDB2cY5BA/aszz5ym1Y/8VTFv LhKM/uMwasvfoPuzgdBHU9C0hoJEfGJQ6pD5A= Received: by 10.50.34.202 with SMTP id b10mr12058788igj.30.1330308228677; Sun, 26 Feb 2012 18:03:48 -0800 (PST) Received: from DataIX.net (adsl-99-181-135-127.dsl.klmzmi.sbcglobal.net. [99.181.135.127]) by mx.google.com with ESMTPS id ub10sm9063900igb.7.2012.02.26.18.03.47 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 18:03:48 -0800 (PST) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1R23jB8068793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2012 21:03:45 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1R23ioi067991; Sun, 26 Feb 2012 21:03:44 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Date: Sun, 26 Feb 2012 21:03:44 -0500 From: Jason Hellenthal To: Peter =?iso-8859-1?Q?Ankerst=E5l?= Message-ID: <20120227020344.GA70875@DataIX.net> References: <3E3E4094-77E2-490B-9574-5B95ECDED447@pean.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <3E3E4094-77E2-490B-9574-5B95ECDED447@pean.org> X-Gm-Message-State: ALoCoQnQeHdD7p2rFTQxH50FetVPiCwzuhcJaflDS1jcLVaTwbNMKQErxlec+8Px4CgnKZWfUZzA Cc: freebsd-fs@freebsd.org Subject: Re: glabel, gpart and zfs confusion. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 02:22:32 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 25, 2012 at 09:42:08AM +0100, Peter Ankerst=E5l wrote: > Hi, >=20 > Now Im really confused.=20 >=20 > I want in some way label my drives so the setup is independent of physica= l setup. But Jason doesn't > seem to like glabel at all. :D > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013574.html >=20 > And then he says that you should use gpart instead > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013578.html >=20 > But this seems to be in conflict with the common knowledge that zfs should > be used on whole disks, not partitions! >=20 > Any pointers?=20 glabel(8) Is not known by any other system than FreeBSD. GPT or that createed by gpart(8) are. For clarity say you create a label "test01" for /dev/ad0, you then create a ZFS pool upon "/dev/label/test01". For some reason or months down the road you somehow disable glabel on the system and boot... ZFS will search for the pool within the actual disks ultimately erasing your precious glabel. Another instance I have seen is people booting a live Solaris disc to repair the likes of anonymous "bad things". They find out that coming back to FreeBSD that the label is now gone. Now if you try to re-glabel(8) that disk that contains ZFS would you be absolutely confident that it is NOT overwriting anything important ? This is why I do not like generic labels they are a good idea but they are only temporary and very fragile when it comes to the above instances. ZFS on Solaris by default creates pools on a partition that spans accross the "whole disk". They are not refering to using the raw disk though you certainly may if thats what tweaks you. This is often confused. Hope this helps. --=20 ;s =3D; --5vNYLRcllDrimb99 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPSuSAAAoJEJBXh4mJ2FR+GwwH/18CpC8W78yRll+Wa3r9BxZN 6xU1cVUSwNeE6NiGVZIDTLJ4gICVHEHCWBCtL0vXMlYL3/FM5RcBFmK2Yn1cbPbR rgM3zGihAzpLbBTy4K6wRPcFXLyKnbDxjwj8eiBw6ZpwHr25GQVCmsIz1YwKzH2P I/XuyhanBRPT7akO2AildJV88Ov1WW1SVNtbmipSSmxZyr7csuCPmyZyA21UmIDh +t5mqUKLq4bI17cpdCjEoRfJVuhjzdJZ4WX635T1q6lpZLyhiNEEwgaU1A+NRAZG PhT3UV8a1BZckmI/yM30k/Om23MTp5+6E9rcpUS3amrAxBrYelGkzzVZR9JCvtM= =izgO -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-fs@FreeBSD.ORG Mon Feb 27 11:07:29 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F13D106566C for ; Mon, 27 Feb 2012 11:07:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7CCFF8FC12 for ; Mon, 27 Feb 2012 11:07:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1RB7TgI090186 for ; Mon, 27 Feb 2012 11:07:29 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1RB7SkS090183 for freebsd-fs@FreeBSD.org; Mon, 27 Feb 2012 11:07:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Feb 2012 11:07:28 GMT Message-Id: <201202271107.q1RB7SkS090183@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 11:07:29 -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/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/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161511 fs [unionfs] Filesystem deadlocks when using multiple uni o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [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/159663 fs [socket] [nullfs] sockets don't work though nullfs mou 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/157722 fs [geli] unable to newfs a geli encrypted partition o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs f 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/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/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/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 262 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 27 18:14:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBF951065679; Mon, 27 Feb 2012 18:14:44 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5F57A8FC19; Mon, 27 Feb 2012 18:14:44 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1RIEelK028699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 05:14:41 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q1RIEddh052643; Tue, 28 Feb 2012 05:14:39 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q1RIEbNO052642; Tue, 28 Feb 2012 05:14:37 +1100 (EST) (envelope-from peter) Date: Tue, 28 Feb 2012 05:14:37 +1100 From: Peter Jeremy To: Luke Marsden Message-ID: <20120227181436.GA49667@server.vk2pj.dyndns.org> References: <1330081612.13430.39.camel@pow> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <1330081612.13430.39.camel@pow> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, team@hybrid-logic.co.uk, "freebsd-stable@freebsd.org" Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:14:45 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Feb-24 11:06:52 +0000, Luke Marsden = wrote: >We're running 8.2-RELEASE v15 in production on 24GB RAM amd64 machines >but have been having trouble with short spikes in application memory >usage resulting in huge amounts of swapping, bringing the whole machine >to its knees and crashing it hard. I suspect this is because when there >is a sudden spike in memory usage the zfs arc reclaim thread is unable >to free system memory fast enough. There were a large number of fairly serious ZFS bugs that have been fixed since 8.2-RELEASE and I would suggest you look at upgrading. That said, I haven't seen the specific problem you are reporting. > * is this a known problem? I'm unaware of it specifically as it relates to ZFS. You don't mention how big the memory usage spike is but unless there is sufficient free+ cache available to cope with a usage spike then you will have problems whether it's UFS or ZFS (though it's possibly worse with ZFS). FreeBSD is known not to cope well with running out of memory. > * what is the community's advice for production machines running > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure > that there's enough actually free memory to handle a spike in > application memory usage) the best solution to this > spike-in-memory-means-crash problem? Are you swapping onto a ZFS vdev? If so, change back to a raw (or geom) device - swapping to ZFS is known to be problematic. If you have very spiky memory requirements, increasing vm.v_cache_min and/or vm.v_free_reserved might give you better results. > * has FreeBSD 9.0 / ZFS v28 solved this problem? The ZFS code is the same in 9.0 and 8.3. Since 8.3 is less of a jump, I'd recommend that you try 8.3-prerelease in a test box and see how it handles your load. Note that there's no need to upgrade your pools =66rom v15 to v28 unless you want the ZFS features - the actual ZFS code is independent of pool version. > * rather than setting a hard limit on the ARC cache size, is it > possible to adjust the auto-tuning variables to leave more free > memory for spiky memory situations? e.g. set the auto-tuning to > make arc eat 80% of memory instead of ~95% like it is at > present? Memory spikes are absorbed by vm.v_cache_min and vm.v_free_reserved in the first instance. The current vfs.zfs.arc_max default may be a bit high for some workloads but at this point in time, you will need to tune it manually. --=20 Peter Jeremy --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9LyAwACgkQ/opHv/APuIfByQCePnYTXe8GrzcA4RoQTJvLjqOW kRMAoMR9D6Lh6qtHKSqF48Px6HU02Iy2 =u09I -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-fs@FreeBSD.ORG Mon Feb 27 23:24:54 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 944C3106566B for ; Mon, 27 Feb 2012 23:24:54 +0000 (UTC) (envelope-from peter@ipsec.se) Received: from n.manet.nu (n.manet.nu [212.91.140.35]) by mx1.freebsd.org (Postfix) with ESMTP id 26D0E8FC08 for ; Mon, 27 Feb 2012 23:24:53 +0000 (UTC) Received: from bore.hk.ipsec.se (h87-241-127-130.dynamic.se.alltele.net [87.241.127.130]) by n.manet.nu (8.14.3/8.14.3) with ESMTP id q1RNOaQi003062; Tue, 28 Feb 2012 00:24:51 +0100 (CET) (envelope-from peter@ipsec.se) Received: from dhcp-0.hk.ipsec.se (dhcp-0.hk.ipsec.se [192.168.99.15]) by bore.hk.ipsec.se (8.14.4/8.14.4) with ESMTP id q1RNOL2F043308; Tue, 28 Feb 2012 00:24:36 +0100 (CET) (envelope-from peter@ipsec.se) From: =?iso-8859-1?Q?peter_h=E5kanson?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2012 00:24:32 +0100 Message-Id: <300898C6-33E5-4AD6-9E88-DF28737B8103@ipsec.se> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: danno@internet2.edu Subject: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 23:24:54 -0000 i have seen problems with freebsd 8.2 and 9.0 on sun thumper ( x4500)=20 where the bios logs shows "Hyper transport sync flood" will get into the = BIOS errorlog ( but nothing will come to syslog since reboot is = immediate) This was discussed on freebsd.freebsd-stable jan 18 2012 There was no solution with freebsd, to my dismay solaris works well on = the same box :-) Maybe x4200 has simular design issues ( had to do with routing of = interrupts to the available cpu's) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Peter H=E5kanson Phone +46707328101 =20 IPSec sverige Email peter@ipsec.se "Safe by design" Address Lillek=E4rr Norra 96 S-425 34 Hisings K=E4rra Sweden From owner-freebsd-fs@FreeBSD.ORG Mon Feb 27 23:52:14 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2792A106564A for ; Mon, 27 Feb 2012 23:52:14 +0000 (UTC) (envelope-from peter@ipsec.se) Received: from n.manet.nu (n.manet.nu [212.91.140.35]) by mx1.freebsd.org (Postfix) with ESMTP id 623F08FC13 for ; Mon, 27 Feb 2012 23:52:13 +0000 (UTC) Received: from bore.hk.ipsec.se (h87-241-127-130.dynamic.se.alltele.net [87.241.127.130]) by n.manet.nu (8.14.3/8.14.3) with ESMTP id q1RNOaAY003061; Tue, 28 Feb 2012 00:24:51 +0100 (CET) (envelope-from peter@ipsec.se) Received: from dhcp-0.hk.ipsec.se (dhcp-0.hk.ipsec.se [192.168.99.15]) by bore.hk.ipsec.se (8.14.4/8.14.4) with ESMTP id q1RNOL2E043308; Tue, 28 Feb 2012 00:24:36 +0100 (CET) (envelope-from peter@ipsec.se) From: =?iso-8859-1?Q?peter_h=E5kanson?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2012 00:22:21 +0100 Message-Id: <0C524480-D254-4211-9962-CF62C2A26E10@ipsec.se> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: danno@internet2.edu Subject: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 23:52:14 -0000 i have seen problems with freebsd 8.2 and 9.0 on sun thumper ( x4500)=20 where the bios logs shows "Hyper transport sync flood" will get into the = BIOS errorlog ( but nothing will come to syslog since reboot is = immediate) This was discussed on freebsd.freebsd-stable jan 18 2012 There was no solution with freebsd, to my dismay solaris works well on = the same box :-) Maybe x4200 has simular design issues ( had to do with routing of = interrupts to the available cpu's) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Peter H=E5kanson Phone +46707328101 =20 IPSec sverige Email peter@ipsec.se "Safe by design" Address Lillek=E4rr Norra 96 S-425 34 Hisings K=E4rra Sweden From owner-freebsd-fs@FreeBSD.ORG Tue Feb 28 04:25:59 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03721065673 for ; Tue, 28 Feb 2012 04:25:59 +0000 (UTC) (envelope-from efinley.lists@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FACA8FC14 for ; Tue, 28 Feb 2012 04:25:59 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so1499349obb.13 for ; Mon, 27 Feb 2012 20:25:58 -0800 (PST) Received-SPF: pass (google.com: domain of efinley.lists@gmail.com designates 10.182.31.50 as permitted sender) client-ip=10.182.31.50; Authentication-Results: mr.google.com; spf=pass (google.com: domain of efinley.lists@gmail.com designates 10.182.31.50 as permitted sender) smtp.mail=efinley.lists@gmail.com; dkim=pass header.i=efinley.lists@gmail.com Received: from mr.google.com ([10.182.31.50]) by 10.182.31.50 with SMTP id x18mr6196203obh.53.1330403158936 (num_hops = 1); Mon, 27 Feb 2012 20:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S/Fw8aGJd1uGa4bRKtyykRrd9Sl3jSS9kni6wn+iMz8=; b=enrSSDXV/CFCeC3S3bobwtBeM7LJ7yQRGoNB/H1fHMLlZQr790DuEm3Uh5ItL9bl7F QD2zzL0wT/YpEZwvUXBTX00dg0TM8uRXqkTTnb2ryYC74AxtJ3uGKUy0lkYoTja73GI1 3taRT9bvnLPpf0gfaXho3clv9Ij6R3iLP67bo= MIME-Version: 1.0 Received: by 10.182.31.50 with SMTP id x18mr5403730obh.53.1330401809636; Mon, 27 Feb 2012 20:03:29 -0800 (PST) Received: by 10.182.16.69 with HTTP; Mon, 27 Feb 2012 20:03:29 -0800 (PST) In-Reply-To: <3CEE2DA4348D944399A67E308B78D38A1A57CABA@janus.anserinae.net> References: <3CEE2DA4348D944399A67E308B78D38A1A57CABA@janus.anserinae.net> Date: Mon, 27 Feb 2012 21:03:29 -0700 Message-ID: From: Elliot Finley To: Kamil Choudhury Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-fs@freebsd.org" Subject: Re: Distributed, snapshotting, checksumming filesystems for FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 04:25:59 -0000 It's called moosefs. On Fri, Feb 24, 2012 at 9:37 PM, Kamil Choudhury wrote: > The dream: a file system spread out over a variable, > ever increasing number of hosts, presenting a single > unified file system to any client host mounting the > file system. > > >From the client's point of view, it is possible to > snapshot the directory view that is presented. The > client also has confidence that data written to the > file system will be returned exactly as it went in. > > Now that I think about it, what I seem to be looking > for is a network aware ZFS that uses hosts as vdevs. > > Is there such a thing out there? > > Kamil > > > _______________________________________________ > 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 Tue Feb 28 05:08:53 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B816B106566C for ; Tue, 28 Feb 2012 05:08:53 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 79A298FC0C for ; Tue, 28 Feb 2012 05:08:53 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 7635B7E820; Tue, 28 Feb 2012 15:49:15 +1100 (EST) Message-ID: <4F4C5CCB.3050806@freebsd.org> Date: Tue, 28 Feb 2012 15:49:15 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120208 Thunderbird/10.0 MIME-Version: 1.0 To: Kamil Choudhury References: <3CEE2DA4348D944399A67E308B78D38A1A57CABA@janus.anserinae.net> In-Reply-To: <3CEE2DA4348D944399A67E308B78D38A1A57CABA@janus.anserinae.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: "freebsd-fs@freebsd.org" Subject: Re: Distributed, snapshotting, checksumming filesystems for FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 05:08:53 -0000 On 02/25/12 15:37, Kamil Choudhury wrote: > The dream: a file system spread out over a variable, > ever increasing number of hosts, presenting a single > unified file system to any client host mounting the > file system. > >> From the client's point of view, it is possible to > snapshot the directory view that is presented. The > client also has confidence that data written to the > file system will be returned exactly as it went in. > > Now that I think about it, what I seem to be looking > for is a network aware ZFS that uses hosts as vdevs. > > Is there such a thing out there? AFS perhaps? http://en.wikipedia.org/wiki/OpenAFS http://en.wikipedia.org/wiki/Andrew_File_System /usr/ports/net/openafs Cheers, Lawrence From owner-freebsd-fs@FreeBSD.ORG Tue Feb 28 07:32:46 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D3641065675; Tue, 28 Feb 2012 07:32:46 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id 24D918FC0C; Tue, 28 Feb 2012 07:32:41 +0000 (UTC) X-AuditID: 1209190d-b7fbf6d0000008ba-40-4f4c7f93a315 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BE.91.02234.39F7C4F4; Tue, 28 Feb 2012 02:17:39 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q1S7HdM2020938; Tue, 28 Feb 2012 02:17:39 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q1S7HbKf022360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Feb 2012 02:17:38 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id q1S7HaU1015734; Tue, 28 Feb 2012 02:17:36 -0500 (EST) Date: Tue, 28 Feb 2012 02:17:36 -0500 (EST) From: Benjamin Kaduk To: Lawrence Stewart In-Reply-To: <4F4C5CCB.3050806@freebsd.org> Message-ID: References: <3CEE2DA4348D944399A67E308B78D38A1A57CABA@janus.anserinae.net> <4F4C5CCB.3050806@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixG6nrju53sffoPmtjsWxxz/ZLOYf2M5o sflWF7MDs8ebH1/YPGZ8ms8SwBTFZZOSmpNZllqkb5fAlXHt7km2ghd8FY97/7A0ML7h7mLk 5JAQMJF4fekbO4QtJnHh3nq2LkYuDiGBfYwSh1+/hHI2MEpsfnaJGcI5wCSxY/0pJgingVFi Re9ZRpB+FgFtiev/v7KA2GwCKhIz32xkA7FFgOLbzn5m7WLk4GAWyJdYtbYUxBQW8JM40xgL UsEJVNF87zYTiM0r4Cjx4+ZEZhBbSCBTomnCQ7DpogI6Eqv3T2GBqBGUODnzCZjNLGApce7P dbYJjIKzkKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGukl5tZopeaUrqJERSynJK8 OxjfHVQ6xCjAwajEw1s8y9tfiDWxrLgy9xCjJAeTkiivT62PvxBfUn5KZUZicUZ8UWlOavEh RgkOZiURXv1soHLelMTKqtSifJiUNAeLkjivqtY7PyGB9MSS1OzU1ILUIpisDAeHkgTvvjqg oYJFqempFWmZOSUIaSYOTpDhPEDDNUBqeIsLEnOLM9Mh8qcYdTkWLN98kVGIJS8/L1VKnPcU SJEASFFGaR7cHFiqecUoDvSWMO9KkCoeYJqCm/QKaAkT0JIATpAPiksSEVJSDYw+3IfvGIXM Yw2cOd8z80n97P0rKtZJH60tLCtp+LHzKUfp2dwuxbK+1uWrfVj5ttnZcVWFLln8aeO0/x9P my3x8X/IeVXmBkPkV9kV21iXrolz7tOcf8WxtMwg4i7Lol92EVLSpjF6ngHBfqIdXZZdN2z5 W7SkUyszznPKhdqLLdftL2yQVWIpzkg01GIuKk4EAKhWBHkQAwAA Cc: "freebsd-fs@freebsd.org" , Kamil Choudhury Subject: Re: Distributed, snapshotting, checksumming filesystems for FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 07:32:46 -0000 On Tue, 28 Feb 2012, Lawrence Stewart wrote: > On 02/25/12 15:37, Kamil Choudhury wrote: >> The dream: a file system spread out over a variable, >> ever increasing number of hosts, presenting a single >> unified file system to any client host mounting the >> file system. >> >>> From the client's point of view, it is possible to >> snapshot the directory view that is presented. The >> client also has confidence that data written to the >> file system will be returned exactly as it went in. >> >> Now that I think about it, what I seem to be looking >> for is a network aware ZFS that uses hosts as vdevs. >> >> Is there such a thing out there? > > AFS perhaps? > > http://en.wikipedia.org/wiki/OpenAFS > http://en.wikipedia.org/wiki/Andrew_File_System > > /usr/ports/net/openafs I almost made that suggestion, but decided not to, given that the present implementation only allows administrators to make snapshots, and I don't think any checksumming would be quite what was described. (One could certainly use a ZFS partition for the fileserver backing store, which would give some checksum functionality, but it would not be exposed to users in a particularly useful fashion.) But, it does win at having a single unified file system presented to any client mounting it, which is distributed over multiple servers (and data can be shuffled between servers seamlessly). If the OP can compromise in the right directions it might be worth looking at, though, I suppose. I'll also add that the OpenAFS client is not production-ready on FreeBSD; there are some memory leaks and issues with cache eviction for large files that are not yet resolved. Unfortunately there have been a couple of regressions on the git master branch that I need to track down before I can get back to working on the FreeBSD-specific issues. -Ben Kaduk From owner-freebsd-fs@FreeBSD.ORG Tue Feb 28 16:20:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C23F0106564A for ; Tue, 28 Feb 2012 16:20:32 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DAC68FC08 for ; Tue, 28 Feb 2012 16:20:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Content-Transfer-Encoding:Mime-Version:Date:References:Subject:To:Content-Type; bh=k7UcjpQmzqlc6XoJAPn9frIfLtb/L0tTeCe9+wBAG38=; b=oFr4/6UE4oq9rXcCaju1wsWQePKtA13h/EjKbitJjTsh9JguKfskvh87xDDwaBYTyKn1eX9gajqPvx9t2Ellm9oX7ewvTvPxpmKnZlpP+zwcxjS3jkwtL0oYHUlkS1Yy; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S2Pms-000OOm-CE for freebsd-fs@freebsd.org; Tue, 28 Feb 2012 10:20:32 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1330446020-13047-13046/5/30; Tue, 28 Feb 2012 16:20:20 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <0C524480-D254-4211-9962-CF62C2A26E10@ipsec.se> Date: Tue, 28 Feb 2012 10:20:19 -0600 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Mark Felder Message-Id: In-Reply-To: <0C524480-D254-4211-9962-CF62C2A26E10@ipsec.se> User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 16:20:32 -0000 On Mon, 27 Feb 2012 17:22:21 -0600, peter h=C3=A5kanson = wrote: > i have seen problems with freebsd 8.2 and 9.0 on sun thumper ( x4500) > where the bios logs shows "Hyper transport sync flood" will get into = the =20 > BIOS errorlog ( but nothing will come to syslog since reboot is =20 > immediate) I've read this exact report on one of the FreeBSD mailing lists before. = I =20 can't remember if it was solved. Perhaps someone in-the-know can chime = in. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 04:13:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96DCB106566B; Wed, 29 Feb 2012 04:13:25 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 836598FC1E; Wed, 29 Feb 2012 04:13:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1T4DP0p030359; Wed, 29 Feb 2012 04:13:25 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1T4DPgD030358; Wed, 29 Feb 2012 04:13:25 GMT (envelope-from jwd) Date: Wed, 29 Feb 2012 04:13:25 +0000 From: John To: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Message-ID: <20120229041325.GA4447@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: GEOM tasting iscsi zvols? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 04:13:25 -0000 Hi Folks, I noticed (actually looked at my serial console logs :) that GEOM appears to be tasting the zvols being exported via iscsi(istgt). For instance: multipath completes... GEOM_MULTIPATH: da405 added to Z22 GEOM_MULTIPATH: da406 added to Z23 GEOM_MULTIPATH: da407 added to Z24 load zfs... ZFS filesystem version 5 ZFS storage pool version 28 luns tasted... GEOM_PART: integrity check failed (zvol/pool0/d00000003_300g_16k, MBR) GEOM_PART: integrity check failed (zvol/pool0/d00000003_300g_16k@snap1, MBR) GEOM_PART: integrity check failed (zvol/pool0/d00000001_300g_16k, MBR) GEOM_PART: integrity check failed (zvol/pool0/d00000001_300g_16k@snap1, MBR) The zvols have never been accessed/formatted from the local system except via the istgt daemon from the client. Is there a way to disable this that I've somehow missed? man 4 GEOM mentions "tasting" and the logic around this operation. A google search shows a couple of similar questions - no discrete answers. Comments welcome. Thanks, John From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 11:09:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7F1E1065672 for ; Wed, 29 Feb 2012 11:09:15 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7FB8FC17 for ; Wed, 29 Feb 2012 11:09:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S2hPF-00045N-8H for freebsd-fs@freebsd.org; Wed, 29 Feb 2012 12:09:13 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Feb 2012 12:09:13 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Feb 2012 12:09:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Wed, 29 Feb 2012 12:08:51 +0100 Lines: 50 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1A8FB78AEA4D6626C31A47B7" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 X-Enigmail-Version: 1.3.5 Subject: fsync: giving up on dirty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 11:09:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1A8FB78AEA4D6626C31A47B7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, One of the machines I take care of started recently started recording messages such as these in the logs: Feb 28 04:02:09 skynet kernel: fsync: giving up on dirty Feb 28 04:02:09 skynet kernel: 0xfffffe000fef2780: tag devfs, type VCHR Feb 28 04:02:09 skynet kernel: usecount 1, writecount 0, refcount 2400 mountedhere 0xfffffe000fd25200 Feb 28 04:02:09 skynet kernel: flags () Feb 28 04:02:09 skynet kernel: v_object 0xfffffe000fe96d98 ref 0 pages 23= 990 Feb 28 04:02:09 skynet kernel: lock type devfs: EXCL by thread 0xfffffe000feb5000 (pid 44968) Feb 28 04:02:09 skynet kernel: dev multipath/hpdisk4-web I'm leaning towards suspecting bad hardware - the device behind "multipath/hpdisk4-web" is an old HP MSA FC storage (which I wouldn't recommend to anyone), but though verbose, the message lacks device-level specifics. I would expect messages to be logged by the isp driver, or the CAM layer, or even GEOM, but there is nothing there - only this "fsync" message. =46rom the code, it looks like an transient condition (printed in the cas= e of EAGAIN), but the hardware here is behaving a bit suspect so I'd like to make sure - should I ignore this message? --------------enig1A8FB78AEA4D6626C31A47B7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9OB00ACgkQldnAQVacBcj7FgCfSUqoXYRAPBW2EhRKVTUUx2lg rJIAoKgpdh6B5xejCwIr6Lv3AoShvtht =Ucqp -----END PGP SIGNATURE----- --------------enig1A8FB78AEA4D6626C31A47B7-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 18:08:41 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D5DD106564A; Wed, 29 Feb 2012 18:08:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 04C0A8FC0A; Wed, 29 Feb 2012 18:08:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1TI8ea3033112; Wed, 29 Feb 2012 18:08:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1TI8ejt033108; Wed, 29 Feb 2012 18:08:40 GMT (envelope-from linimon) Date: Wed, 29 Feb 2012 18:08:40 GMT Message-Id: <201202291808.q1TI8ejt033108@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165559: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:08:41 -0000 Old Synopsis: ufsmount.h uses the 'export' keyword as a structure member name New Synopsis: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Feb 29 18:08:22 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165559 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 18:57:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FB9A106566B; Wed, 29 Feb 2012 18:57:17 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 155988FC13; Wed, 29 Feb 2012 18:57:16 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q1TIvGb6038966; Wed, 29 Feb 2012 13:57:16 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id q1TIvGN2038963; Wed, 29 Feb 2012 13:57:16 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20302.29963.529821.258448@hergotha.csail.mit.edu> Date: Wed, 29 Feb 2012 13:57:15 -0500 From: Garrett Wollman To: freebsd-fs@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 29 Feb 2012 13:57:16 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: rmacklem@freebsd.org Subject: Under what circumstances does the new NFS client return EAGAIN? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:57:17 -0000 I'm testing out a new file server, and trying to rsync files from a proprietary NAS to the box I'm testing. It's running the new NFS code and 9.0. rsync frequently and repeatably errors out with something like this: rsync: read errors mapping "[source file name]": Resource temporarily unavailable (35) cp(1), on the other hand, seems just fine with the same source files. Any ideas what causes this? -GAWollman From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 19:10:13 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33E721065675 for ; Wed, 29 Feb 2012 19:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 22C3F8FC14 for ; Wed, 29 Feb 2012 19:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1TJACKZ087983 for ; Wed, 29 Feb 2012 19:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1TJACSG087982; Wed, 29 Feb 2012 19:10:12 GMT (envelope-from gnats) Date: Wed, 29 Feb 2012 19:10:12 GMT Message-Id: <201202291910.q1TJACSG087982@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Jim Carroll" Cc: Subject: Re: kern/165559: ufsmount.h uses the ' export' keyword as a structure member name X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jim Carroll List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 19:10:13 -0000 The following reply was made to PR kern/165559; it has been noted by GNATS. From: "Jim Carroll" To: Cc: Subject: Re: kern/165559: ufsmount.h uses the 'export' keyword as a structure member name Date: Wed, 29 Feb 2012 13:07:44 -0500 This is a multipart message in MIME format. ------=_NextPart_000_0010_01CCF6E3.2168D7F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit WHOOPS - inverted the filenames for our patch. Here is the correct patch --- /usr/include/ufs/ufs/ufsmount.h 2012-02-29 12:32:28.000000000 -0500 +++ ufsmount.h 2012-02-29 13:07:08.000000000 -0500 @@ -40,7 +40,7 @@ */ struct ufs_args { char *fspec; /* block special device to mount */ - struct oexport_args export; /* network export information */ + struct oexport_args export_; /* network export information */ }; #ifdef _KERNEL ------=_NextPart_000_0010_01CCF6E3.2168D7F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WHOOPS – inverted the = filenames for our patch. Here is the correct = patch

 

 

--- = /usr/include/ufs/ufs/ufsmount.h   2012-02-29 = 12:32:28.000000000 -0500

+++ = ufsmount.h 2012-02-29 13:07:08.000000000 -0500

@@ -40,7 +40,7 @@

  */

= struct ufs_args {

=     char = *fspec;           = /* block special device to mount */

-    struct    = oexport_args export;    /* network export information = */

+    = struct    oexport_args export_;   /* network = export information */

= };

 #ifdef _KERNEL

 

------=_NextPart_000_0010_01CCF6E3.2168D7F0-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 19:19:46 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A792C106564A; Wed, 29 Feb 2012 19:19:46 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0018FC12; Wed, 29 Feb 2012 19:19:46 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q1TJJfCP082878; Wed, 29 Feb 2012 11:19:41 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201202291919.q1TJJfCP082878@chez.mckusick.com> To: Ivan Voras In-reply-to: Date: Wed, 29 Feb 2012 11:19:41 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org Subject: Re: fsync: giving up on dirty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 19:19:46 -0000 > To: freebsd-fs@freebsd.org > From: Ivan Voras > Date: Wed, 29 Feb 2012 12:08:51 +0100 > Subject: fsync: giving up on dirty > > Hi, > > One of the machines I take care of started recently started recording > messages such as these in the logs: > > Feb 28 04:02:09 skynet kernel: fsync: giving up on dirty > Feb 28 04:02:09 skynet kernel: 0xfffffe000fef2780: tag devfs, type VCHR > Feb 28 04:02:09 skynet kernel: usecount 1, writecount 0, refcount 2400 > mountedhere 0xfffffe000fd25200 > Feb 28 04:02:09 skynet kernel: flags () > Feb 28 04:02:09 skynet kernel: v_object 0xfffffe000fe96d98 ref 0 pages 23990 > Feb 28 04:02:09 skynet kernel: lock type devfs: EXCL by thread > 0xfffffe000feb5000 (pid 44968) > Feb 28 04:02:09 skynet kernel: dev multipath/hpdisk4-web > > I'm leaning towards suspecting bad hardware - the device behind > "multipath/hpdisk4-web" is an old HP MSA FC storage (which I wouldn't > recommend to anyone), but though verbose, the message lacks device-level > specifics. I would expect messages to be logged by the isp driver, or > the CAM layer, or even GEOM, but there is nothing there - only this > "fsync" message. > > From the code, it looks like an transient condition (printed in the case > of EAGAIN), but the hardware here is behaving a bit suspect so I'd like > to make sure - should I ignore this message? I have seen this message during some of Peter Holm's stress tests when running with journaled soft updates. Note that soft updates without journaling do not show this issue. The "giving up" message comes when trying to flush the filesystem metadata blocks associated with the mount device (hence the VCHR type of the vnode). The problem has become more evident with my recent changes to the way that sync'ing is done. I believe that the problem is because the soft updates worklist needs to be flushed before some of the dirty blocks can be successfully written. If you are running a 9-stable system on this machine, are using journaled soft updates on the filesystem in question, and are willing to try out my first attempt at a fix, let me know and I'll send you the diffs for it. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 20:37:19 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59E49106566C; Wed, 29 Feb 2012 20:37:19 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 317778FC17; Wed, 29 Feb 2012 20:37:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1TKbJr0072743; Wed, 29 Feb 2012 20:37:19 GMT (envelope-from kib@freefall.freebsd.org) Received: (from kib@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1TKbJDI072739; Wed, 29 Feb 2012 20:37:19 GMT (envelope-from kib) Date: Wed, 29 Feb 2012 20:37:19 GMT Message-Id: <201202292037.q1TKbJDI072739@freefall.freebsd.org> To: kib@FreeBSD.org, freebsd-fs@FreeBSD.org, kib@FreeBSD.org From: kib@FreeBSD.org Cc: Subject: Re: kern/165559: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 20:37:19 -0000 Synopsis: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name Responsible-Changed-From-To: freebsd-fs->kib Responsible-Changed-By: kib Responsible-Changed-When: Wed Feb 29 20:36:32 UTC 2012 Responsible-Changed-Why: Grab. The supplied patch is obviously wrong, or rather incomplete. The in-kernel uses of the export member must be corrected. http://www.freebsd.org/cgi/query-pr.cgi?pr=165559 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 29 21:40:14 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B1CE106566B for ; Wed, 29 Feb 2012 21:40:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3D68FC0A for ; Wed, 29 Feb 2012 21:40:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1TLeEdx027923 for ; Wed, 29 Feb 2012 21:40:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1TLeEXL027922; Wed, 29 Feb 2012 21:40:14 GMT (envelope-from gnats) Date: Wed, 29 Feb 2012 21:40:14 GMT Message-Id: <201202292140.q1TLeEXL027922@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/51583: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:40:14 -0000 The following reply was made to PR kern/51583; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/51583: commit references a PR Date: Wed, 29 Feb 2012 21:38:56 +0000 (UTC) Author: trociny Date: Wed Feb 29 21:38:31 2012 New Revision: 232317 URL: http://svn.freebsd.org/changeset/base/232317 Log: Introduce VOP_UNP_BIND(), VOP_UNP_CONNECT(), and VOP_UNP_DETACH() operations for setting and accessing vnode's v_socket field. The operations are necessary to implement proper unix socket handling on layered file systems like nullfs(5). This change fixes the long standing issue with nullfs(5) being in that unix sockets did not work between lower and upper layers: if we bound to a socket on the lower layer we could connect only to the lower path; if we bound to the upper layer we could connect only to the upper path. The new behavior is one can connect to both the lower and the upper paths regardless what layer path one binds to. PR: kern/51583, kern/159663 Suggested by: kib Reviewed by: arch MFC after: 2 weeks Modified: head/UPDATING head/sys/kern/uipc_usrreq.c head/sys/kern/vfs_default.c head/sys/kern/vnode_if.src head/sys/sys/vnode.h Modified: head/UPDATING ============================================================================== --- head/UPDATING Wed Feb 29 21:11:02 2012 (r232316) +++ head/UPDATING Wed Feb 29 21:38:31 2012 (r232317) @@ -22,6 +22,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10 machines to maximize performance. (To disable malloc debugging, run ln -s aj /etc/malloc.conf.) +20120229: + Now unix domain sockets behave "as expected" on nullfs(5). Previously + nullfs(5) did not pass through all behaviours to the underlying layer, + as a result if we bound to a socket on the lower layer we could connect + only to the lower path; if we bound to the upper layer we could connect + only to the upper path. The new behavior is one can connect to both the + lower and the upper paths regardless what layer path one binds to. + 20120211: The getifaddrs upgrade path broken with 20111215 has been restored. If you have upgraded in between 20111215 and 20120209 you need to Modified: head/sys/kern/uipc_usrreq.c ============================================================================== --- head/sys/kern/uipc_usrreq.c Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/kern/uipc_usrreq.c Wed Feb 29 21:38:31 2012 (r232317) @@ -542,7 +542,7 @@ restart: UNP_LINK_WLOCK(); UNP_PCB_LOCK(unp); - vp->v_socket = unp->unp_socket; + VOP_UNP_BIND(vp, unp->unp_socket); unp->unp_vnode = vp; unp->unp_addr = soun; unp->unp_flags &= ~UNP_BINDING; @@ -638,7 +638,7 @@ uipc_detach(struct socket *so) * XXXRW: Should assert vp->v_socket == so. */ if ((vp = unp->unp_vnode) != NULL) { - unp->unp_vnode->v_socket = NULL; + VOP_UNP_DETACH(vp); unp->unp_vnode = NULL; } unp2 = unp->unp_conn; @@ -1308,7 +1308,7 @@ unp_connect(struct socket *so, struct so * and to protect simultaneous locking of multiple pcbs. */ UNP_LINK_WLOCK(); - so2 = vp->v_socket; + VOP_UNP_CONNECT(vp, &so2); if (so2 == NULL) { error = ECONNREFUSED; goto bad2; @@ -2318,17 +2318,15 @@ vfs_unp_reclaim(struct vnode *vp) active = 0; UNP_LINK_WLOCK(); - so = vp->v_socket; + VOP_UNP_CONNECT(vp, &so); if (so == NULL) goto done; unp = sotounpcb(so); if (unp == NULL) goto done; UNP_PCB_LOCK(unp); - if (unp->unp_vnode != NULL) { - KASSERT(unp->unp_vnode == vp, - ("vfs_unp_reclaim: vp != unp->unp_vnode")); - vp->v_socket = NULL; + if (unp->unp_vnode == vp) { + VOP_UNP_DETACH(vp); unp->unp_vnode = NULL; active = 1; } Modified: head/sys/kern/vfs_default.c ============================================================================== --- head/sys/kern/vfs_default.c Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/kern/vfs_default.c Wed Feb 29 21:38:31 2012 (r232317) @@ -123,6 +123,9 @@ struct vop_vector default_vnodeops = { .vop_unlock = vop_stdunlock, .vop_vptocnp = vop_stdvptocnp, .vop_vptofh = vop_stdvptofh, + .vop_unp_bind = vop_stdunp_bind, + .vop_unp_connect = vop_stdunp_connect, + .vop_unp_detach = vop_stdunp_detach, }; /* @@ -1037,6 +1040,30 @@ vop_stdadvise(struct vop_advise_args *ap return (error); } +int +vop_stdunp_bind(struct vop_unp_bind_args *ap) +{ + + ap->a_vp->v_socket = ap->a_socket; + return (0); +} + +int +vop_stdunp_connect(struct vop_unp_connect_args *ap) +{ + + *ap->a_socket = ap->a_vp->v_socket; + return (0); +} + +int +vop_stdunp_detach(struct vop_unp_detach_args *ap) +{ + + ap->a_vp->v_socket = NULL; + return (0); +} + /* * vfs default ops * used to fill the vfs function table to get reasonable default return values. Modified: head/sys/kern/vnode_if.src ============================================================================== --- head/sys/kern/vnode_if.src Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/kern/vnode_if.src Wed Feb 29 21:38:31 2012 (r232317) @@ -640,6 +640,26 @@ vop_advise { IN int advice; }; +%% unp_bind vp E E E + +vop_unp_bind { + IN struct vnode *vp; + IN struct socket *socket; +}; + +%% unp_connect vp L L L + +vop_unp_connect { + IN struct vnode *vp; + OUT struct socket **socket; +}; + +%% unp_detach vp = = = + +vop_unp_detach { + IN struct vnode *vp; +}; + # The VOPs below are spares at the end of the table to allow new VOPs to be # added in stable branches without breaking the KBI. New VOPs in HEAD should # be added above these spares. When merging a new VOP to a stable branch, Modified: head/sys/sys/vnode.h ============================================================================== --- head/sys/sys/vnode.h Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/sys/vnode.h Wed Feb 29 21:38:31 2012 (r232317) @@ -703,6 +703,9 @@ int vop_stdpathconf(struct vop_pathconf_ int vop_stdpoll(struct vop_poll_args *); int vop_stdvptocnp(struct vop_vptocnp_args *ap); int vop_stdvptofh(struct vop_vptofh_args *ap); +int vop_stdunp_bind(struct vop_unp_bind_args *ap); +int vop_stdunp_connect(struct vop_unp_connect_args *ap); +int vop_stdunp_detach(struct vop_unp_detach_args *ap); int vop_eopnotsupp(struct vop_generic_args *ap); int vop_ebadf(struct vop_generic_args *ap); int vop_einval(struct vop_generic_args *ap); _______________________________________________ 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 Wed Feb 29 21:40:16 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B7A51065673 for ; Wed, 29 Feb 2012 21:40:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9978FC15 for ; Wed, 29 Feb 2012 21:40:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1TLeG1a027928 for ; Wed, 29 Feb 2012 21:40:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1TLeGXu027927; Wed, 29 Feb 2012 21:40:16 GMT (envelope-from gnats) Date: Wed, 29 Feb 2012 21:40:16 GMT Message-Id: <201202292140.q1TLeGXu027927@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159663: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:40:16 -0000 The following reply was made to PR kern/159663; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159663: commit references a PR Date: Wed, 29 Feb 2012 21:38:57 +0000 (UTC) Author: trociny Date: Wed Feb 29 21:38:31 2012 New Revision: 232317 URL: http://svn.freebsd.org/changeset/base/232317 Log: Introduce VOP_UNP_BIND(), VOP_UNP_CONNECT(), and VOP_UNP_DETACH() operations for setting and accessing vnode's v_socket field. The operations are necessary to implement proper unix socket handling on layered file systems like nullfs(5). This change fixes the long standing issue with nullfs(5) being in that unix sockets did not work between lower and upper layers: if we bound to a socket on the lower layer we could connect only to the lower path; if we bound to the upper layer we could connect only to the upper path. The new behavior is one can connect to both the lower and the upper paths regardless what layer path one binds to. PR: kern/51583, kern/159663 Suggested by: kib Reviewed by: arch MFC after: 2 weeks Modified: head/UPDATING head/sys/kern/uipc_usrreq.c head/sys/kern/vfs_default.c head/sys/kern/vnode_if.src head/sys/sys/vnode.h Modified: head/UPDATING ============================================================================== --- head/UPDATING Wed Feb 29 21:11:02 2012 (r232316) +++ head/UPDATING Wed Feb 29 21:38:31 2012 (r232317) @@ -22,6 +22,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10 machines to maximize performance. (To disable malloc debugging, run ln -s aj /etc/malloc.conf.) +20120229: + Now unix domain sockets behave "as expected" on nullfs(5). Previously + nullfs(5) did not pass through all behaviours to the underlying layer, + as a result if we bound to a socket on the lower layer we could connect + only to the lower path; if we bound to the upper layer we could connect + only to the upper path. The new behavior is one can connect to both the + lower and the upper paths regardless what layer path one binds to. + 20120211: The getifaddrs upgrade path broken with 20111215 has been restored. If you have upgraded in between 20111215 and 20120209 you need to Modified: head/sys/kern/uipc_usrreq.c ============================================================================== --- head/sys/kern/uipc_usrreq.c Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/kern/uipc_usrreq.c Wed Feb 29 21:38:31 2012 (r232317) @@ -542,7 +542,7 @@ restart: UNP_LINK_WLOCK(); UNP_PCB_LOCK(unp); - vp->v_socket = unp->unp_socket; + VOP_UNP_BIND(vp, unp->unp_socket); unp->unp_vnode = vp; unp->unp_addr = soun; unp->unp_flags &= ~UNP_BINDING; @@ -638,7 +638,7 @@ uipc_detach(struct socket *so) * XXXRW: Should assert vp->v_socket == so. */ if ((vp = unp->unp_vnode) != NULL) { - unp->unp_vnode->v_socket = NULL; + VOP_UNP_DETACH(vp); unp->unp_vnode = NULL; } unp2 = unp->unp_conn; @@ -1308,7 +1308,7 @@ unp_connect(struct socket *so, struct so * and to protect simultaneous locking of multiple pcbs. */ UNP_LINK_WLOCK(); - so2 = vp->v_socket; + VOP_UNP_CONNECT(vp, &so2); if (so2 == NULL) { error = ECONNREFUSED; goto bad2; @@ -2318,17 +2318,15 @@ vfs_unp_reclaim(struct vnode *vp) active = 0; UNP_LINK_WLOCK(); - so = vp->v_socket; + VOP_UNP_CONNECT(vp, &so); if (so == NULL) goto done; unp = sotounpcb(so); if (unp == NULL) goto done; UNP_PCB_LOCK(unp); - if (unp->unp_vnode != NULL) { - KASSERT(unp->unp_vnode == vp, - ("vfs_unp_reclaim: vp != unp->unp_vnode")); - vp->v_socket = NULL; + if (unp->unp_vnode == vp) { + VOP_UNP_DETACH(vp); unp->unp_vnode = NULL; active = 1; } Modified: head/sys/kern/vfs_default.c ============================================================================== --- head/sys/kern/vfs_default.c Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/kern/vfs_default.c Wed Feb 29 21:38:31 2012 (r232317) @@ -123,6 +123,9 @@ struct vop_vector default_vnodeops = { .vop_unlock = vop_stdunlock, .vop_vptocnp = vop_stdvptocnp, .vop_vptofh = vop_stdvptofh, + .vop_unp_bind = vop_stdunp_bind, + .vop_unp_connect = vop_stdunp_connect, + .vop_unp_detach = vop_stdunp_detach, }; /* @@ -1037,6 +1040,30 @@ vop_stdadvise(struct vop_advise_args *ap return (error); } +int +vop_stdunp_bind(struct vop_unp_bind_args *ap) +{ + + ap->a_vp->v_socket = ap->a_socket; + return (0); +} + +int +vop_stdunp_connect(struct vop_unp_connect_args *ap) +{ + + *ap->a_socket = ap->a_vp->v_socket; + return (0); +} + +int +vop_stdunp_detach(struct vop_unp_detach_args *ap) +{ + + ap->a_vp->v_socket = NULL; + return (0); +} + /* * vfs default ops * used to fill the vfs function table to get reasonable default return values. Modified: head/sys/kern/vnode_if.src ============================================================================== --- head/sys/kern/vnode_if.src Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/kern/vnode_if.src Wed Feb 29 21:38:31 2012 (r232317) @@ -640,6 +640,26 @@ vop_advise { IN int advice; }; +%% unp_bind vp E E E + +vop_unp_bind { + IN struct vnode *vp; + IN struct socket *socket; +}; + +%% unp_connect vp L L L + +vop_unp_connect { + IN struct vnode *vp; + OUT struct socket **socket; +}; + +%% unp_detach vp = = = + +vop_unp_detach { + IN struct vnode *vp; +}; + # The VOPs below are spares at the end of the table to allow new VOPs to be # added in stable branches without breaking the KBI. New VOPs in HEAD should # be added above these spares. When merging a new VOP to a stable branch, Modified: head/sys/sys/vnode.h ============================================================================== --- head/sys/sys/vnode.h Wed Feb 29 21:11:02 2012 (r232316) +++ head/sys/sys/vnode.h Wed Feb 29 21:38:31 2012 (r232317) @@ -703,6 +703,9 @@ int vop_stdpathconf(struct vop_pathconf_ int vop_stdpoll(struct vop_poll_args *); int vop_stdvptocnp(struct vop_vptocnp_args *ap); int vop_stdvptofh(struct vop_vptofh_args *ap); +int vop_stdunp_bind(struct vop_unp_bind_args *ap); +int vop_stdunp_connect(struct vop_unp_connect_args *ap); +int vop_stdunp_detach(struct vop_unp_detach_args *ap); int vop_eopnotsupp(struct vop_generic_args *ap); int vop_ebadf(struct vop_generic_args *ap); int vop_einval(struct vop_generic_args *ap); _______________________________________________ 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 Mar 1 00:21:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F1C0106566C; Thu, 1 Mar 2012 00:21:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 231128FC15; Thu, 1 Mar 2012 00:21:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAGLATk+DaFvO/2dsb2JhbABEhSevTYF6AQEBBAEBASArIAsbGAICDRkCKQEJJgYIBwQBHASHaAunMpIxgS+IU4J4BQQHFBACAgUCCgEGBAcCBgcVCwYDAoREAQI6GgUGAQIBAwMHAQEYB4I6gRYEiE+KSIIokw+BNggK X-IronPort-AV: E=Sophos;i="4.73,506,1325480400"; d="scan'208";a="158513384" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Feb 2012 19:21:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 196FEB3F68; Wed, 29 Feb 2012 19:21:25 -0500 (EST) Date: Wed, 29 Feb 2012 19:21:25 -0500 (EST) From: Rick Macklem To: Garrett Wollman Message-ID: <148631084.149332.1330561285089.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20302.29963.529821.258448@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, rmacklem@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 00:21:26 -0000 Garrett Wollman wrote: > I'm testing out a new file server, and trying to rsync files from > a proprietary NAS to the box I'm testing. It's running the new NFS > code and 9.0. rsync frequently and repeatably errors out with > something like this: > > rsync: read errors mapping "[source file name]": Resource temporarily > unavailable (35) > > cp(1), on the other hand, seems just fine with the same source files. > > Any ideas what causes this? > EWOULDBLOCK is most likely being returned by the kernel rpc, when a wait for a reply has timed out. With hard mounts, this would normally not be returned to userland (at least that's my understanding of the krpc code, which I didn't write), but would result in a new socket/connection being created for a retry of the RPC. The other cases are things like a non-blocking I/O or a non-blocking byte range lock request, which I doubt rsync is doing, but I don't know anything about rsync's implementation. If you are using the "soft" or "intr" mount options, I'd suggest you get rid of them (technically "intr" should result in EINTR, but I wouldn't be surprised if an EWOULDBLOCK could pop out, as well). Also, you didn't mention whether you were using UDP or TCP mounts, although the above comments should apply to both. You might also want to capture packets and look at them in wireshark, to make sure the EWOULDBLOCK isn't coming from the proprietary NAS server. rick > -GAWollman > _______________________________________________ > 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 Mar 1 01:52:16 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 377D7106567C for ; Thu, 1 Mar 2012 01:52:16 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id C0B538FC25 for ; Thu, 1 Mar 2012 01:52:15 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q211qEuE051449; Wed, 29 Feb 2012 20:52:14 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id q211qEnC051446; Wed, 29 Feb 2012 20:52:14 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20302.54862.344852.13627@hergotha.csail.mit.edu> Date: Wed, 29 Feb 2012 20:52:14 -0500 From: Garrett Wollman To: Rick Macklem In-Reply-To: <148631084.149332.1330561285089.JavaMail.root@erie.cs.uoguelph.ca> References: <20302.29963.529821.258448@hergotha.csail.mit.edu> <148631084.149332.1330561285089.JavaMail.root@erie.cs.uoguelph.ca> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 29 Feb 2012 20:52:14 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 01:52:16 -0000 < said: > If you are using the "soft" or "intr" mount options, I'd suggest you > get rid of them (technically "intr" should result in EINTR, but I wouldn't > be surprised if an EWOULDBLOCK could pop out, as well). Also, you > didn't mention whether you were using UDP or TCP mounts, although the > above comments should apply to both. mount -t nfs -o ro,hard,tcp,nointr > You might also want to capture packets and look at them in wireshark, > to make sure the EWOULDBLOCK isn't coming from the proprietary NAS server. Unfortunately, I can't capture packets on this machine fast enough to record a decodeable NFS/TCP stream with the NAS. Another bug I've noticed: when mounting any remote NFS filesystem, all of the local exported NFS filesystems briefly give [EPERM] (or maybe it's [EACCES]) errors to their clients. This tends to break whatever is trying to use them at the time. It doesn't happen when local ZFS datasets are created and mounted. -GAWollman From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 02:08:54 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25CD8106564A; Thu, 1 Mar 2012 02:08:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id B94D88FC14; Thu, 1 Mar 2012 02:08:53 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2128nX3022888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 13:08:51 +1100 Date: Thu, 1 Mar 2012 13:08:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: kib@FreeBSD.org In-Reply-To: <201202292037.q1TKbJDI072739@freefall.freebsd.org> Message-ID: <20120301115156.X1922@besplex.bde.org> References: <201202292037.q1TKbJDI072739@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/165559: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 02:08:54 -0000 On Wed, 29 Feb 2012 kib@FreeBSD.org wrote: > Synopsis: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name > > The supplied patch is obviously wrong, or rather incomplete. > The in-kernel uses of the export member must be corrected. The kernel should change to support applications that abuse kernel headers. libufs uses ufsmount.h, but I consider the existence of libufs to be another bug, and it's not clear whey it uses this header. Even mount(8) no longer uses this header. It used to use it, but now uses nmount(2) so everything is done using string options and mount args structs are never used. I don't like nmount(), but it seems that anything new enough to be tripping over the export keyword should also be new enough to not use old mount args structs. df(1) still uses this header, since it hasn't been converted to use nmount(). But if nmount() is good for anything it is good here. df only uses mount() to run report results for unmounted file systems. But it only understands ffs. Actually, it blindly assumes ffs. It could do better using nmount(), except the details of creating options are even more difficult using nmount(), and it is unreasonable fot df to create options more complicated than "-o ro ", which are not enough in many cases. So it shouldn't do any of this. It could reasonably fork mount(8) to do whatever can be done using /etc/fsatab. Either way, it wouldn't use this header. Here is the entire contents of this header after removing the _KERNEL parts of it: % #include /* XXX For struct workhead. */ This supplies gross namespace pollution. Perhaps parts of userland that are abusing this header actually want this pollution. sys/buf.h is another header that should be kernel-only, but it has some _KERNEL ifdefs in it, and removing the _KERNEL parts in it shows gross namespace pollution that is not under these ifdefs. It begins by includinf , , and and gets whatever pollution these supply. Then it soon declares a kernel variable (extern struct... bioops). Otherwise, it is realtively clean and only defines kernel types and macros. % % /* % * Arguments to mount UFS-based filesystems % */ % struct ufs_args { % char *fspec; /* block special device to mount */ % struct oexport_args export; /* network export information */ % }; There is not much here. libufs of course doesn't use this struct or anything in it. It seems to build perfectly after removing all includes of ufsmount.h in it (5 in .c files). This shows that none of the other ufs headers that libufs includes depend on this header, and that nothing depends on the namespace pollution in this header. libufs also says that applications must include this header in the SYNOPSIS of all 5 of its man pages. This seems to be wrong too. The man pages also says that applications must include 2 other ffs headers. These headers are actually needed, to declare types for libufs's header. Actually, the `export' variable should be fixed because it has style bugs. Struct members should have a fairly unique prefix related to the struct. The style bugs are missing in , so it wouldn't have this bug if it had a struct member near `export'. It actually doesn't have any names near `export', but has struct export args and uses the prefix ex_ for all struct members in it. I only searched for includes of this header in an old version of FreeBSD. Apart from the above, they are in - amd: it still uses mount() AFAIK - sysinstall: too old to use nmount() - mountd: now the use is almost reasonable, but it has XXX comments about this assuming that all mount args structs look like ffs's, and I think they must indeed start like ffs's - mountd in -current: mountd uses nmount() and no longer uses the ufs header, but it does use the corresponding nfs header, which, since it lmust look like ffs's header, has the same bugs (no prefixes in names, and the second member is named `export'). So the scope of this bug includes all mount args structs in the kernel. - dump/main.c: ufs utilities can use ufs headers without abusing them, but like libufs, this file includes this header, apparently without actually using it (the include is grouped with the other 2 as in libufs, except it is only unsorted in ufs. - newfs/newfs.c: same as in libufs, with different unsorting - tunefs/tunefs.c: this actually uses the header, since it needs to remount and hasn't been converted to nmount(). - fsck_ffs/main.c: legit use. Even uses `export', but only to zero it. - ffsinfo/ffsinfo.c: like dump/main.c - mksnap/mksnap_ffs.c: used to use args.fspec a lot. Has been converted to nmount, so no longer uses the header (?), but still includes it. (I only checked about 3/4 of the files in this list for conversion to nmount()). - kernel uses of this header: there are a few outside of ffs. To summarise, even ffs utilities should be using this header. There are 1 or 2 ffs utilities that can reasonably use it, and a few non-ffs utilities that use since they haven't been converted to nmount(). amd is the only significant remaining one. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 03:13:48 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E0621065672 for ; Thu, 1 Mar 2012 03:13:48 +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 E0D3C8FC08 for ; Thu, 1 Mar 2012 03:13:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKjoTk+DaFvO/2dsb2JhbAA9B4Unr1aBegEBBAEjVgUWGAICDRkCWQYTiAQFpzqSKIEviFmCcgUEBwMFBhYCAgUCCgEGBAcCBgcVCwkChEQBAjoaBQYBAgEDAwcBAQuCToEWBIhPjHCTD4E2CAk X-IronPort-AV: E=Sophos;i="4.73,507,1325480400"; d="scan'208";a="161609066" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Feb 2012 22:13:47 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 20A3CB3F65; Wed, 29 Feb 2012 22:13:47 -0500 (EST) Date: Wed, 29 Feb 2012 22:13:47 -0500 (EST) From: Rick Macklem To: Garrett Wollman Message-ID: <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20302.54862.344852.13627@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 03:13:48 -0000 Garrett Wollman wrote: > < said: > > > If you are using the "soft" or "intr" mount options, I'd suggest you > > get rid of them (technically "intr" should result in EINTR, but I > > wouldn't > > be surprised if an EWOULDBLOCK could pop out, as well). Also, you > > didn't mention whether you were using UDP or TCP mounts, although > > the > > above comments should apply to both. > > mount -t nfs -o ro,hard,tcp,nointr > > > You might also want to capture packets and look at them in > > wireshark, > > to make sure the EWOULDBLOCK isn't coming from the proprietary NAS > > server. > > Unfortunately, I can't capture packets on this machine fast enough to > record a decodeable NFS/TCP stream with the NAS. > Hmm. Well, for hard mounts the krpc shouldn't be returning EWOULDBLOCK. (It is conceivable that the server is returning this, but without a packet trace, I don't know how you could find out. I suppose you could put a "if (error == EWOULDBLOCK) printf(...);" in the code that decodes the NFS reply. If you'd like to do that, email and I'll come up with a quick patch.) Otherwise, maybe rsync is doing byte range locking. You could add "nolockd" to the mount options (which avoids using the NLM) and see if that helps. > Another bug I've noticed: when mounting any remote NFS filesystem, all > of the local exported NFS filesystems briefly give [EPERM] (or maybe > it's [EACCES]) errors to their clients. This tends to break whatever > is trying to use them at the time. It doesn't happen when local ZFS > datasets are created and mounted. > Personally, I'm not very fond of it, but "mount" forces mountd to redo the file exports whenever a new mount is done. (I believe the thinking was to make sure the newly mounted fs gets exported, if it is in /etc/exports, but I wasn't the author of it and I haven't looked at the commit log for mount.c.) You could easily hack mount.c to not do this. Unfortunately it is a well known issue that updating exports is not done atomically. (I had a patch that suspended the nfsd threads while exports were being updated, but it was felt to be risky and zack@ was going to come up with a patch to fix this, but I don't think he has committed anything.) rick From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 08:49:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835191065670 for ; Thu, 1 Mar 2012 08:49:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BA6888FC12 for ; Thu, 1 Mar 2012 08:49:01 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q218m1SO032188; Thu, 1 Mar 2012 10:48:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q218m1ug013137; Thu, 1 Mar 2012 10:48:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q218m1Iu013136; Thu, 1 Mar 2012 10:48:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 1 Mar 2012 10:48:01 +0200 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120301084801.GP55074@deviant.kiev.zoral.com.ua> References: <201202292037.q1TKbJDI072739@freefall.freebsd.org> <20120301115156.X1922@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ic1EQBzFNokAMJj2" Content-Disposition: inline In-Reply-To: <20120301115156.X1922@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: kern/165559: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 08:49:02 -0000 --ic1EQBzFNokAMJj2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 01, 2012 at 01:08:49PM +1100, Bruce Evans wrote: > On Wed, 29 Feb 2012 kib@FreeBSD.org wrote: >=20 > >Synopsis: [ufs] [patch] ufsmount.h uses the 'export' keyword as a=20 > >structure member name > > > >The supplied patch is obviously wrong, or rather incomplete. > >The in-kernel uses of the export member must be corrected. >=20 > The kernel should change to support applications that abuse kernel > headers. >=20 > libufs uses ufsmount.h, but I consider the existence of libufs to be > another bug, and it's not clear whey it uses this header. >=20 > Even mount(8) no longer uses this header. It used to use it, but now > uses nmount(2) so everything is done using string options and mount args > structs are never used. I don't like nmount(), but it seems that anything > new enough to be tripping over the export keyword should also be new > enough to not use old mount args structs. >=20 > df(1) still uses this header, since it hasn't been converted to use > nmount(). But if nmount() is good for anything it is good here. df > only uses mount() to run report results for unmounted file systems. > But it only understands ffs. Actually, it blindly assumes ffs. It > could do better using nmount(), except the details of creating options > are even more difficult using nmount(), and it is unreasonable fot > df to create options more complicated than "-o ro ", > which are not enough in many cases. So it shouldn't do any of this. > It could reasonably fork mount(8) to do whatever can be done using > /etc/fsatab. Either way, it wouldn't use this header. There is more uses of ufs_args, in particular, in automounter. >=20 > Here is the entire contents of this header after removing the _KERNEL > parts of it: >=20 > % #include /* XXX For struct workhead. */ >=20 > This supplies gross namespace pollution. Perhaps parts of userland > that are abusing this header actually want this pollution. sys/buf.h > is another header that should be kernel-only, but it has some _KERNEL > ifdefs in it, and removing the _KERNEL parts in it shows gross > namespace pollution that is not under these ifdefs. It begins by > includinf , , and > and gets whatever pollution these supply. Then it > soon declares a kernel variable (extern struct... bioops). Otherwise, > it is realtively clean and only defines kernel types and macros. >=20 > %=20 > % /* > % * Arguments to mount UFS-based filesystems > % */ > % struct ufs_args { > % char *fspec; /* block special device to mount */ > % struct oexport_args export; /* network export information */ > % }; >=20 > There is not much here. libufs of course doesn't use this struct or > anything in it. It seems to build perfectly after removing all includes > of ufsmount.h in it (5 in .c files). This shows that none of the other > ufs headers that libufs includes depend on this header, and that nothing > depends on the namespace pollution in this header. >=20 > libufs also says that applications must include this header in the > SYNOPSIS of all 5 of its man pages. This seems to be wrong too. The > man pages also says that applications must include 2 other ffs headers. > These headers are actually needed, to declare types for libufs's header. >=20 > Actually, the `export' variable should be fixed because it has style bugs. > Struct members should have a fairly unique prefix related to the struct. > The style bugs are missing in , so it wouldn't have this > bug if it had a struct member near `export'. It actually doesn't have > any names near `export', but has struct export args and uses the prefix > ex_ for all struct members in it. >=20 > I only searched for includes of this header in an old version of FreeBSD. > Apart from the above, they are in > - amd: it still uses mount() AFAIK > - sysinstall: too old to use nmount() > - mountd: now the use is almost reasonable, but it has XXX comments about > this assuming that all mount args structs look like ffs's, and I think > they must indeed start like ffs's > - mountd in -current: mountd uses nmount() and no longer uses the ufs > header, but it does use the corresponding nfs header, which, since it > lmust look like ffs's header, has the same bugs (no prefixes in names, > and the second member is named `export'). So the scope of this bug > includes all mount args structs in the kernel. > - dump/main.c: ufs utilities can use ufs headers without abusing them, > but like libufs, this file includes this header, apparently without > actually using it (the include is grouped with the other 2 as in > libufs, except it is only unsorted in ufs. > - newfs/newfs.c: same as in libufs, with different unsorting > - tunefs/tunefs.c: this actually uses the header, since it needs to > remount and hasn't been converted to nmount(). > - fsck_ffs/main.c: legit use. Even uses `export', but only to zero it. > - ffsinfo/ffsinfo.c: like dump/main.c > - mksnap/mksnap_ffs.c: used to use args.fspec a lot. Has been converted > to nmount, so no longer uses the header (?), but still includes it. > (I only checked about 3/4 of the files in this list for conversion to > nmount()). > - kernel uses of this header: there are a few outside of ffs. >=20 > To summarise, even ffs utilities should be using this header. There are > 1 or 2 ffs utilities that can reasonably use it, and a few non-ffs > utilities that use since they haven't been converted to nmount(). amd > is the only significant remaining one. >=20 Yes. I expect the bug submitter to finish the work and provide a complete patch for renaming. FWIW, the export_ is ugly, some reasonable name should be used. > Bruce --ic1EQBzFNokAMJj2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9PN8EACgkQC3+MBN1Mb4hEEACfV1Ae1mHTp66A13+3E8bLNr7+ NxoAoJf9DO7egn6mW3Oo1ygeSGTi/2MU =J90p -----END PGP SIGNATURE----- --ic1EQBzFNokAMJj2-- From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 11:05:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B041065679 for ; Thu, 1 Mar 2012 11:05:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5721B8FC13 for ; Thu, 1 Mar 2012 11:05:17 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q21B5DOc028742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 22:05:15 +1100 Date: Thu, 1 Mar 2012 22:05:13 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120301084801.GP55074@deviant.kiev.zoral.com.ua> Message-ID: <20120301214559.N3748@besplex.bde.org> References: <201202292037.q1TKbJDI072739@freefall.freebsd.org> <20120301115156.X1922@besplex.bde.org> <20120301084801.GP55074@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: kern/165559: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:05:17 -0000 On Thu, 1 Mar 2012, Konstantin Belousov wrote: > On Thu, Mar 01, 2012 at 01:08:49PM +1100, Bruce Evans wrote: >> ... >> To summarise, even ffs utilities should be using this header. There are >> 1 or 2 ffs utilities that can reasonably use it, and a few non-ffs >> utilities that use since they haven't been converted to nmount(). amd >> is the only significant remaining one. >> > Yes. amd seems to have no references to `export' (it does have references to fspec). Thus the problem is very small. > I expect the bug submitter to finish the work and provide a complete > patch for renaming. That's asking a lot. > FWIW, the export_ is ugly, some reasonable name should be used. It could probably be renamed to `foo', or better yet, to `ugly' for userland only, and almost nothing would notice (I only noticed fsck_ffs accessing it, and that access was bogus (better done with bzero()) and went away with conversion to nmount()). Of course, the correct name is something like fa_export (fa = ffs args). In old mount(8), args.export was only used to initialize args.export.ex_root to DEFAULT_ROOTUID = -2 (uids can't be negative and this gets type-punned to 0xfffffffe) and args.export.ex_flags to either MNT_EXRDONLY or to 0 depending on whether the mount is r/o. I wonder how this works now. Current mount code doesn't pass "export" and doesn't define DEFAULT_ROOTUID. mountd still has a more-magic -2. and OP_MAPROOT to change it. Other callers of mount() didn't bother to set DEFAULT_ROOTUID or MNT_EXRDONLY. One in fsck_ffs even seems to pass stack garbage for the entire args.export. df still uses mount() and a ufs_args struct. It doesn't bother setting anything, but doesn't pass stack garbage since it uses a static args struct. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 15:07:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E5FE106564A for ; Thu, 1 Mar 2012 15:07:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 42CA18FC16 for ; Thu, 1 Mar 2012 15:07:27 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S36za-000AsG-RR; Thu, 01 Mar 2012 18:28:26 +0400 Date: Thu, 1 Mar 2012 18:28:26 +0400 From: Slawa Olhovchenkov To: Peter Jeremy Message-ID: <20120301142826.GG97848@zxy.spb.ru> References: <1330081612.13430.39.camel@pow> <20120227181436.GA49667@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120227181436.GA49667@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-fs@freebsd.org, "freebsd-stable@freebsd.org" , team@hybrid-logic.co.uk Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:07:28 -0000 On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > > * what is the community's advice for production machines running > > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure > > that there's enough actually free memory to handle a spike in > > application memory usage) the best solution to this > > spike-in-memory-means-crash problem? > > Are you swapping onto a ZFS vdev? If so, change back to a raw (or > geom) device - swapping to ZFS is known to be problematic. If you I see kernel stuck when swapping to ZFS. This is only known problem? From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 17:36:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7248F106566B for ; Thu, 1 Mar 2012 17:36:17 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 03B0D8FC1D for ; Thu, 1 Mar 2012 17:36:16 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q21HaFaI090513; Thu, 1 Mar 2012 12:36:15 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id q21HaFei090510; Thu, 1 Mar 2012 12:36:15 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20303.45967.708688.414986@hergotha.csail.mit.edu> Date: Thu, 1 Mar 2012 12:36:15 -0500 From: Garrett Wollman To: Rick Macklem In-Reply-To: <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> References: <20302.54862.344852.13627@hergotha.csail.mit.edu> <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 01 Mar 2012 12:36:16 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:36:17 -0000 < said: > Otherwise, maybe rsync is doing byte range locking. You could add > "nolockd" to the mount options (which avoids using the NLM) and see > if that helps. That may well have done it, although I changed too many variables to be certain. -o udp,rsize=262144,wsize=262144,nolockd,hard,nointr seems to be working without error. rpc.lockd is running, for what it's worth. > Unfortunately it is a well known issue that updating exports > is not done atomically. (I had a patch that suspended the nfsd > threads while exports were being updated, but it was felt to > be risky and zack@ was going to come up with a patch to fix this, > but I don't think he has committed anything.) That might be something that we at least would need. You don't need to suspend all of the nfsd threads, just delay responding to any request that fails access control until the filter programming is done. We may actually need to do something like that, if this machine is to be usable as a file server. (Can't have our users' jobs randomly breaking just because an administrator mounted a new filesystem.) -GAWollman From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 00:25:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 344901065675 for ; Fri, 2 Mar 2012 00:25:25 +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 E20F18FC18 for ; Fri, 2 Mar 2012 00:25:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAH8SUE+DaFvO/2dsb2JhbAA8B4U/r2iBfQEBBAEjVgUWGAICDRkCWQYTiAEFrVqKEIEviF2CKQoBCAUXAgIFAgoBBgQHAgYHFQsJAoREAQI6GgUGAQIBAwMHAQELglKBFgSIT4xskxCBNggO X-IronPort-AV: E=Sophos;i="4.73,514,1325480400"; d="scan'208";a="161752725" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Mar 2012 19:25:24 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 21851B3F1F; Thu, 1 Mar 2012 19:25:24 -0500 (EST) Date: Thu, 1 Mar 2012 19:25:24 -0500 (EST) From: Rick Macklem To: Garrett Wollman Message-ID: <1549796645.224931.1330647924122.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20303.45967.708688.414986@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 00:25:25 -0000 Garrett Wollman wrote: > < said: > > > Otherwise, maybe rsync is doing byte range locking. You could add > > "nolockd" to the mount options (which avoids using the NLM) and see > > if that helps. > > That may well have done it, although I changed too many variables to > be certain. -o udp,rsize=262144,wsize=262144,nolockd,hard,nointr > seems to be working without error. > Wow, those are big UDP datagrams, but if they work, cool... > rpc.lockd is running, for what it's worth. > Doesn't matter. With the "nolockd" option, the client mount never uses it. > > Unfortunately it is a well known issue that updating exports > > is not done atomically. (I had a patch that suspended the nfsd > > threads while exports were being updated, but it was felt to > > be risky and zack@ was going to come up with a patch to fix this, > > but I don't think he has committed anything.) > > That might be something that we at least would need. You don't need > to suspend all of the nfsd threads, just delay responding to any > request that fails access control until the filter programming is > done. We may actually need to do something like that, if this machine > is to be usable as a file server. (Can't have our users' jobs > randomly breaking just because an administrator mounted a new > filesystem.) > Well, it happens to be easy to block all the nfsd threads when they are between processing of RPCs. There are times (not very frequent) when this is necessary for NFSv4, so the code is already there to do it. I don't know how to delay replies and that might be messy. I can resurrect the patch for you, because it is simply two new options on the nfssvc() syscall to suspend and resume the threads, that are done by mountd before/after updating exports. (I think the main concern is that, if mountd crashes while processing the exports update, the resume will never happen, at least not until mountd is restarted. I think rwatson@ had an additional concern when this was discussed at the BSDCan developer summit, but I can't recall what it was?) Just email if you want the patch to test, rick From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 03:20:15 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E4A1106566C for ; Fri, 2 Mar 2012 03:20:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 447518FC13 for ; Fri, 2 Mar 2012 03:20:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q223KExI017850 for ; Fri, 2 Mar 2012 03:20:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q223KE5g017849; Fri, 2 Mar 2012 03:20:14 GMT (envelope-from gnats) Date: Fri, 2 Mar 2012 03:20:14 GMT Message-Id: <201203020320.q223KE5g017849@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Robert Simmons Cc: Subject: Re: kern/157722: [geli] unable to newfs a geli encrypted partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Simmons List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 03:20:15 -0000 The following reply was made to PR kern/157722; it has been noted by GNATS. From: Robert Simmons To: bug-followup@freebsd.org Cc: Subject: Re: kern/157722: [geli] unable to newfs a geli encrypted partition Date: Thu, 1 Mar 2012 22:10:25 -0500 Please close this bug. It is not a bug, I failed to read the man page completely. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 05:20:58 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F122B106566B; Fri, 2 Mar 2012 05:20:58 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C955A8FC14; Fri, 2 Mar 2012 05:20:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q225Kw7T031893; Fri, 2 Mar 2012 05:20:58 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q225KwcA031889; Fri, 2 Mar 2012 05:20:58 GMT (envelope-from pluknet) Date: Fri, 2 Mar 2012 05:20:58 GMT Message-Id: <201203020520.q225KwcA031889@freefall.freebsd.org> To: rsimmons0@gmail.com, pluknet@FreeBSD.org, freebsd-fs@FreeBSD.org From: pluknet@FreeBSD.org Cc: Subject: Re: kern/157722: [geli] unable to newfs a geli encrypted partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 05:20:59 -0000 Synopsis: [geli] unable to newfs a geli encrypted partition State-Changed-From-To: open->closed State-Changed-By: pluknet State-Changed-When: Fri Mar 2 05:20:30 UTC 2012 State-Changed-Why: Close per submitter request. http://www.freebsd.org/cgi/query-pr.cgi?pr=157722 From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 09:41:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0395106564A for ; Fri, 2 Mar 2012 09:41:58 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 53BAA8FC22 for ; Fri, 2 Mar 2012 09:41:58 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C459.dip.t-dialin.net [87.150.196.89]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 30511844754; Fri, 2 Mar 2012 10:25:17 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 6409E1499; Fri, 2 Mar 2012 10:25:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330680314; bh=5QyKGocFBu/2XKhkfJ4/E8j3NM6lYfhPLHjD+SsgpSQ=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=FyCEmMVWETd0dg2fsmf6DKAsi/ftsw/56fWc9HYHOwjThkqYyqkq+Z41OSsrGF3Gt WnLvycrl1hZH0GDkOE0RDxRJ8VAsp83rqe+17Wyeg1L2WvqMV9VLsbHwbZYfaOFn0n CqQqPrMZlcauw4SP2AL+jBRAjcN//6CK1Smk8S8SyxH7eTFe//BwxGtk3aSK82Ixxh OI47pVx6yXGFmRI3NnBlTNb5ilIwwekkoJTT4/5oNx+2eyyaOhDdBtI+yf73k7Awge bq1Vvopo4JPHaVrL9XuIWZD4YWKYWweNaYS45zh87j9lF3BLK4io4FG7/gGSsOmmdC y67haqUhmodnw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q229P9sF030600; Fri, 2 Mar 2012 10:25:09 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 02 Mar 2012 10:25:09 +0100 Date: Fri, 02 Mar 2012 10:25:09 +0100 Message-ID: <20120302102509.Horde.6uPSdpjmRSRPUJH1lHEHc3A@webmail.leidinger.net> From: Alexander Leidinger To: Slawa Olhovchenkov References: <1330081612.13430.39.camel@pow> <20120227181436.GA49667@server.vk2pj.dyndns.org> <20120301142826.GG97848@zxy.spb.ru> In-Reply-To: <20120301142826.GG97848@zxy.spb.ru> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 30511844754.AF00A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.63, required 6, autolearn=disabled, AWL -0.52, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331285118.98985@gGJ43yjbyPyQdVSP2GBu5Q X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org, team@hybrid-logic.co.uk, "freebsd-stable@freebsd.org" Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 09:41:58 -0000 Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 18:28:26 +0400): > On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > >> > * what is the community's advice for production machines running >> > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure >> > that there's enough actually free memory to handle a spike in >> > application memory usage) the best solution to this >> > spike-in-memory-means-crash problem? >> >> Are you swapping onto a ZFS vdev? If so, change back to a raw (or >> geom) device - swapping to ZFS is known to be problematic. If you > > I see kernel stuck when swapping to ZFS. This is only known problem? This is a known problem. Don't use swap on a zpool. If you want fault tollerance use gmirror for the swap paritions instead (make sure the swap partition does end _before_ the last sector of the disk in this case). Bye, Alexander. -- As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 10:16:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5811C1065672; Fri, 2 Mar 2012 10:16:20 +0000 (UTC) (envelope-from luke-lists@hybrid-logic.co.uk) Received: from hybrid-sites.com (ns226322.hybrid-sites.com [176.31.229.137]) by mx1.freebsd.org (Postfix) with ESMTP id 009AE8FC18; Fri, 2 Mar 2012 10:16:19 +0000 (UTC) Received: from [127.0.0.1] (helo=ewes) by hybrid-sites.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1S3PWz-000LoP-Mg; Fri, 02 Mar 2012 10:16:15 +0000 Received: from [176.31.225.127] (helo=ewes by ns226322.hybrid-sites.com with esmtp (Hybrid Web Cluster distributed mail proxy) (envelope-from ); Fri, 02 Mar 2012 10:16:09 -0000 Received: from [78.105.122.99] (helo=[192.168.1.23] by ns225413.hybrid-sites.com with esmtp (Hybrid Web Cluster distributed mail proxy) (envelope-from ); Fri, 02 Mar 2012 10:16:09 -0000 From: Luke Marsden To: Alexander Leidinger In-Reply-To: <20120302102509.Horde.6uPSdpjmRSRPUJH1lHEHc3A@webmail.leidinger.net> References: <1330081612.13430.39.camel@pow> <20120227181436.GA49667@server.vk2pj.dyndns.org> <20120301142826.GG97848@zxy.spb.ru> <20120302102509.Horde.6uPSdpjmRSRPUJH1lHEHc3A@webmail.leidinger.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 02 Mar 2012 10:16:06 +0000 Message-ID: <1330683366.3819.20.camel@pow> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Spam-bar: + Cc: freebsd-fs@freebsd.org, team@hybrid-logic.co.uk, "freebsd-stable@freebsd.org" , Slawa Olhovchenkov Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 10:16:20 -0000 On Fri, 2012-03-02 at 10:25 +0100, Alexander Leidinger wrote: > Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 > 18:28:26 +0400): > > > On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > > > >> > * what is the community's advice for production machines running > >> > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure > >> > that there's enough actually free memory to handle a spike in > >> > application memory usage) the best solution to this > >> > spike-in-memory-means-crash problem? > >> > >> Are you swapping onto a ZFS vdev? We are not swapping onto a ZFS vdev (we've been down that road and know it's a bad idea). Our issue is primarily with ARC cache eviction not happening fast enough or at all when there is a spike in memory usage, causing machines to hang. We are presently working around it by limiting arc_max to 4G on our 24G RAM production boxes (which seems like a massive waste of performance) and by doing very careful/aggressive application level management of memory usage to ensure stability (limits.conf didn't work for us, so we rolled our own). A better solution would be welcome, though, so that we can utilise all the free memory we're presently keeping around as a safety margin - ideally it would be used as ARC cache. Two more questions, again wrt 8.2-RELEASE: 1. Is it expected that with a 4G limited arc_max value that we should see wired memory usage around 7-8G? I understand that the kernel has to use some memory, but really 3-4G of non-ARC data? 2. We have some development machines with only 3G of RAM. Previously they had no arc_max set and were left to tune themselves. They were quite unstable. Now we've set arc_max to 256M but things have got worse: we've seen a disk i/o big performance hit (untarring a ports tarball now takes 20 minutes), and wired memory usage is up around 2.5GB, the machines are swapping a lot, and crashing more frequently. Follows is arc_summary.pl from one of the troubled dev machines showing the ARC using 500% of the memory it should be. Also uname follows. My second question is: have there been fixes between 8.2-RELEASE and 8.3-BETA1 or 9.0-RELEASE which solve this ARC over-usage problem? hybrid@node5:~$ ./arc_summary.pl ------------------------------------------------------------------------ ZFS Subsystem Report Fri Mar 2 09:55:00 2012 ------------------------------------------------------------------------ System Memory: 8.92% 264.89 MiB Active, 6.43% 190.75 MiB Inact 80.91% 2.35 GiB Wired, 1.97% 58.46 MiB Cache 1.74% 51.70 MiB Free, 0.03% 864.00 KiB Gap Real Installed: 3.00 GiB Real Available: 99.56% 2.99 GiB Real Managed: 97.04% 2.90 GiB Logical Total: 3.00 GiB Logical Used: 90.20% 2.71 GiB Logical Free: 9.80% 300.91 MiB Kernel Memory: 1.08 GiB Data: 98.75% 1.06 GiB Text: 1.25% 13.76 MiB Kernel Memory Map: 2.83 GiB Size: 26.80% 775.56 MiB Free: 73.20% 2.07 GiB Page: 1 ------------------------------------------------------------------------ ARC Summary: (THROTTLED) Storage pool Version: 15 Filesystem Version: 4 Memory Throttle Count: 53.77m ARC Misc: Deleted: 1.99m Recycle Misses: 6.84m Mutex Misses: 6.96k Evict Skips: 6.96k ARC Size: 552.16% 1.38 GiB Target Size: (Adaptive) 100.00% 256.00 MiB Min Size (Hard Limit): 36.23% 92.75 MiB Max Size (High Water): 2:1 256.00 MiB ARC Size Breakdown: Recently Used Cache Size: 16.97% 239.90 MiB Frequently Used Cache Size: 83.03% 1.15 GiB ARC Hash Breakdown: Elements Max: 83.19k Elements Current: 84.72% 70.48k Collisions: 2.53m Chain Max: 9 Chains: 18.94k Page: 2 ------------------------------------------------------------------------ ARC Efficiency: 126.65m Cache Hit Ratio: 95.07% 120.41m Cache Miss Ratio: 4.93% 6.24m Actual Hit Ratio: 95.07% 120.41m Data Demand Efficiency: 99.45% 111.87m Data Prefetch Efficiency: 0.00% 235.34k CACHE HITS BY CACHE LIST: Most Recently Used: 4.14% 4.99m Most Frequently Used: 95.85% 115.42m Most Recently Used Ghost: 0.24% 292.53k Most Frequently Used Ghost: 3.73% 4.50m CACHE HITS BY DATA TYPE: Demand Data: 92.40% 111.26m Prefetch Data: 0.00% 0 Demand Metadata: 7.60% 9.15m Prefetch Metadata: 0.00% 2.73k CACHE MISSES BY DATA TYPE: Demand Data: 9.79% 610.82k Prefetch Data: 3.77% 235.34k Demand Metadata: 85.67% 5.35m Prefetch Metadata: 0.78% 48.47k Page: 3 ------------------------------------------------------------------------ VDEV Cache Summary: 5.33m Hit Ratio: 91.14% 4.86m Miss Ratio: 8.59% 458.07k Delegations: 0.27% 14.34k Page: 6 ------------------------------------------------------------------------ ZFS Tunable (sysctl): kern.maxusers 384 vm.kmem_size 3112275968 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 329853485875 vfs.zfs.l2c_only_size 0 vfs.zfs.mfu_ghost_data_lsize 4866048 vfs.zfs.mfu_ghost_metadata_lsize 185315328 vfs.zfs.mfu_ghost_size 190181376 vfs.zfs.mfu_data_lsize 4608 vfs.zfs.mfu_metadata_lsize 3072 vfs.zfs.mfu_size 254041600 vfs.zfs.mru_ghost_data_lsize 0 vfs.zfs.mru_ghost_metadata_lsize 0 vfs.zfs.mru_ghost_size 0 vfs.zfs.mru_data_lsize 0 vfs.zfs.mru_metadata_lsize 0 vfs.zfs.mru_size 520685568 vfs.zfs.anon_data_lsize 0 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_size 20846592 vfs.zfs.l2arc_norw 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_noprefetch 0 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 67108864 vfs.zfs.arc_meta_used 1479184192 vfs.zfs.mdcomp_disable 0 vfs.zfs.arc_min 97258624 vfs.zfs.arc_max 268435456 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.zfetch.block_cap 256 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.max_streams 8 vfs.zfs.prefetch_disable 1 vfs.zfs.check_hostid 1 vfs.zfs.recover 0 vfs.zfs.txg.write_limit_override 0 vfs.zfs.txg.synctime 5 vfs.zfs.txg.timeout 30 vfs.zfs.scrub_limit 10 vfs.zfs.vdev.cache.bshift 16 vfs.zfs.vdev.cache.size 10485760 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.aggregation_limit 131072 vfs.zfs.vdev.ramp_rate 2 vfs.zfs.vdev.time_shift 6 vfs.zfs.vdev.min_pending 4 vfs.zfs.vdev.max_pending 10 vfs.zfs.cache_flush_disable 0 vfs.zfs.zil_disable 0 vfs.zfs.zio.use_uma 0 vfs.zfs.version.zpl 4 vfs.zfs.version.spa 15 vfs.zfs.version.dmu_backup_stream 1 vfs.zfs.version.dmu_backup_header 2 vfs.zfs.version.acl 1 vfs.zfs.debug 0 vfs.zfs.super_owner 0 Page: 7 ------------------------------------------------------------------------ hybrid@node5:~$ uname -a FreeBSD node5.hybridlogiclabs.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Thanks! Luke Marsden -- CTO, Hybrid Logic +447791750420 | +1-415-449-1165 | www.hybrid-cluster.com From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 11:11:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD55A106566B for ; Fri, 2 Mar 2012 11:11:33 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 514BE8FC12 for ; Fri, 2 Mar 2012 11:11:32 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q22BBSl0008647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 22:11:30 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q22BBQwJ042605; Fri, 2 Mar 2012 22:11:26 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q22BBOOh042604; Fri, 2 Mar 2012 22:11:24 +1100 (EST) (envelope-from peter) Date: Fri, 2 Mar 2012 22:11:23 +1100 From: Peter Jeremy To: Luke Marsden Message-ID: <20120302111123.GA40708@server.vk2pj.dyndns.org> References: <1330081612.13430.39.camel@pow> <20120227181436.GA49667@server.vk2pj.dyndns.org> <20120301142826.GG97848@zxy.spb.ru> <20120302102509.Horde.6uPSdpjmRSRPUJH1lHEHc3A@webmail.leidinger.net> <1330683366.3819.20.camel@pow> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <1330683366.3819.20.camel@pow> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, Alexander Leidinger Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 11:11:34 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Cc list pruned] On 2012-Mar-02 10:16:06 +0000, Luke Marsden = wrote: >We are presently working around it by limiting arc_max to 4G on our 24G >RAM production boxes (which seems like a massive waste of performance) >and by doing very careful/aggressive application level management of >memory usage to ensure stability (limits.conf didn't work for us, so we >rolled our own). A better solution would be welcome, though, so that we >can utilise all the free memory we're presently keeping around as a >safety margin - ideally it would be used as ARC cache. Have you tried increasing vm.v_cache_min to cover your spikes? >1. Is it expected that with a 4G limited arc_max value that we should >see wired memory usage around 7-8G? I understand that the kernel has to >use some memory, but really 3-4G of non-ARC data? Yes, that sounds possible. >2. We have some development machines with only 3G of RAM. Previously >they had no arc_max set and were left to tune themselves. They were >quite unstable. Now we've set arc_max to 256M but things have got >worse: we've seen a disk i/o big performance hit (untarring a ports >tarball now takes 20 minutes), and wired memory usage is up around >2.5GB, the machines are swapping a lot, and crashing more frequently. That's stress-testing ZFS more than anything else. You definitely can't use those results as a guide to tune your production boxes (other than what not to do). That said, I have 3.5GB in my $work desktop (running 8.2-stable from about a month ago) and don't have any stability issues with either it or a buildbox with 2GB RAM. >Follows is arc_summary.pl from one of the troubled dev machines showing >the ARC using 500% of the memory it should be. Also uname follows. My >second question is: have there been fixes between 8.2-RELEASE and >8.3-BETA1 or 9.0-RELEASE which solve this ARC over-usage problem? There definitely have been some commits to ensure that arc_max is treated much more as a hard limit but I can't quickly find them so I'm not sure if they pre- or post-date 8.2-RELEASE. --=20 Peter Jeremy --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9QqtsACgkQ/opHv/APuIfWmgCfW+tqI1+n5qV9b5dWZ4F2aK/M khEAoKqIgtv3M7cmbCQ0RBRrIJpSEfwj =DgVI -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 12:26:18 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6B971065672 for ; Fri, 2 Mar 2012 12:26:18 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 683158FC12 for ; Fri, 2 Mar 2012 12:26:18 +0000 (UTC) Received: by yhgm50 with SMTP id m50so809990yhg.13 for ; Fri, 02 Mar 2012 04:26:17 -0800 (PST) Received-SPF: pass (google.com: domain of ivoras@gmail.com designates 10.236.190.134 as permitted sender) client-ip=10.236.190.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ivoras@gmail.com designates 10.236.190.134 as permitted sender) smtp.mail=ivoras@gmail.com; dkim=pass header.i=ivoras@gmail.com Received: from mr.google.com ([10.236.190.134]) by 10.236.190.134 with SMTP id e6mr12886935yhn.98.1330691177797 (num_hops = 1); Fri, 02 Mar 2012 04:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=waB2YxPzbzLscFWFI7vfTkIVi+/i2ZqmWoPlBclDpgc=; b=skNkJ8Rdr5AThxoWi4bP91yo6GHOzre7OEkKrXiq2CR/fQ5ZXos7MPOa/B4jXDrv1h dyPOwcib7wn1b9YetGAFSm7bkAHJJ9zQVkDVDxYqfpdwJAD3BGYSWc68J5RxWlMfPj/K 6dHlAEVcRHHflMS9/c+PExGRQwC8NNsd+ueTdXZrWa92BJrku7Gkkm4J8oUeaD18ISzS dBDsrCmGg4by0mY4kcxVIJ0YsxFaHZBFi1ms0fAmmrMzXndQCB9ueR1CC/eewJXvzpFu xxaUBk1PNPQ8GvLNFGyjawoAGVWCMO3XtIpllKGvTtuSycATRjXpAxqvFJHiQqLuHSfL YXRw== Received: by 10.236.190.134 with SMTP id e6mr10050283yhn.98.1330689460120; Fri, 02 Mar 2012 03:57:40 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.101.130.23 with HTTP; Fri, 2 Mar 2012 03:57:00 -0800 (PST) In-Reply-To: <201202291919.q1TJJfCP082878@chez.mckusick.com> References: <201202291919.q1TJJfCP082878@chez.mckusick.com> From: Ivan Voras Date: Fri, 2 Mar 2012 12:57:00 +0100 X-Google-Sender-Auth: PSbvmf60ohxuGW4IAwdt2vSwZK0 Message-ID: To: Kirk McKusick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: fsync: giving up on dirty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:26:18 -0000 On 29 February 2012 20:19, Kirk McKusick wrote: >> To: freebsd-fs@freebsd.org >> From: Ivan Voras >> Date: Wed, 29 Feb 2012 12:08:51 +0100 >> Subject: fsync: giving up on dirty >> >> Hi, >> >> One of the machines I take care of started recently started recording >> messages such as these in the logs: >> >> Feb 28 04:02:09 skynet kernel: fsync: giving up on dirty ... > I believe that the problem is because the soft updates worklist needs > to be flushed before some of the dirty blocks can be successfully written. > If you are running a 9-stable system on this machine, are using journaled > soft updates on the filesystem in question, and are willing to try out > my first attempt at a fix, let me know and I'll send you the diffs for it. The thing is - I'm not. This is a 9-stable, but it was upgraded from 8 and I don't have SUJ enabled. I keep getting such messages daily. Mar 1 04:02:09 skynet kernel: fsync: giving up on dirty Mar 1 04:02:09 skynet kernel: 0xfffffe000fef2780: tag devfs, type VCHR Mar 1 04:02:09 skynet kernel: usecount 1, writecount 0, refcount 2515 mountedhere 0xfffffe000fd25200 Mar 1 04:02:09 skynet kernel: flags () Mar 1 04:02:09 skynet kernel: v_object 0xfffffe000fe96d98 ref 0 pages 10182 Mar 1 04:02:09 skynet kernel: lock type devfs: EXCL by thread 0xfffffe003dc8d000 (pid 79344) Mar 1 04:02:09 skynet kernel: dev multipath/hpdisk4-web From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 13:03:52 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05763106564A for ; Fri, 2 Mar 2012 13:03:52 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id B2C998FC08 for ; Fri, 2 Mar 2012 13:03:51 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S3S9H-0002Fc-0S for freebsd-fs@freebsd.org; Fri, 02 Mar 2012 14:03:51 +0100 Received: from dyn1218-51.wlan.ic.ac.uk ([129.31.218.51]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Mar 2012 14:03:51 +0100 Received: from johannes by dyn1218-51.wlan.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Mar 2012 14:03:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Fri, 02 Mar 2012 13:03:37 +0000 Lines: 42 Message-ID: References: <201202291919.q1TJJfCP082878@chez.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1218-51.wlan.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: Subject: Re: fsync: giving up on dirty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 13:03:52 -0000 On 02/03/2012 11:57, Ivan Voras wrote: > On 29 February 2012 20:19, Kirk McKusick wrote: >>> To: freebsd-fs@freebsd.org >>> From: Ivan Voras >>> Date: Wed, 29 Feb 2012 12:08:51 +0100 >>> Subject: fsync: giving up on dirty >>> >>> Hi, >>> >>> One of the machines I take care of started recently started recording >>> messages such as these in the logs: >>> >>> Feb 28 04:02:09 skynet kernel: fsync: giving up on dirty > ... >> I believe that the problem is because the soft updates worklist needs >> to be flushed before some of the dirty blocks can be successfully written. >> If you are running a 9-stable system on this machine, are using journaled >> soft updates on the filesystem in question, and are willing to try out >> my first attempt at a fix, let me know and I'll send you the diffs for it. > > The thing is - I'm not. This is a 9-stable, but it was upgraded from 8 > and I don't have SUJ enabled. > > I keep getting such messages daily. > > Mar 1 04:02:09 skynet kernel: fsync: giving up on dirty > Mar 1 04:02:09 skynet kernel: 0xfffffe000fef2780: tag devfs, type VCHR > Mar 1 04:02:09 skynet kernel: usecount 1, writecount 0, refcount 2515 > mountedhere 0xfffffe000fd25200 > Mar 1 04:02:09 skynet kernel: flags () > Mar 1 04:02:09 skynet kernel: v_object 0xfffffe000fe96d98 ref 0 pages 10182 > Mar 1 04:02:09 skynet kernel: lock type devfs: EXCL by thread > 0xfffffe003dc8d000 (pid 79344) > Mar 1 04:02:09 skynet kernel: dev multipath/hpdisk4-web A while back I got similar messages (should be in the archives somewhere). Eventually it led to filesystem corruption with a kernel panic. It seemed to be related to snapsot creation (soft-updates, no journal). fsck and manually deleting all snapshots solved the problem temporarily. But when I stopped doing UFS snapshots alltogether the messages stopped too... From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 15:07:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4460106564A for ; Fri, 2 Mar 2012 15:07:02 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 29E2B8FC14 for ; Fri, 2 Mar 2012 15:07:01 +0000 (UTC) Received: by eekd17 with SMTP id d17so673218eek.13 for ; Fri, 02 Mar 2012 07:07:01 -0800 (PST) Received-SPF: pass (google.com: domain of c.kworr@gmail.com designates 10.14.119.194 as permitted sender) client-ip=10.14.119.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of c.kworr@gmail.com designates 10.14.119.194 as permitted sender) smtp.mail=c.kworr@gmail.com; dkim=pass header.i=c.kworr@gmail.com Received: from mr.google.com ([10.14.119.194]) by 10.14.119.194 with SMTP id n42mr6158094eeh.113.1330700821123 (num_hops = 1); Fri, 02 Mar 2012 07:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=CnHsgjssbNqzEWUFVTVkLVz/z5L2EAyYabRQHA9nRbI=; b=0vtRtjkJFpPaA7ScxA0gqR3xJEi2kfeZWYuzDRfPI/qWEbIoULg0yu/2QkKhnSIE/w xaxZoOOKMFo/P+f/uI/WUVXTXtMOWK3WwqngnKKgtAjU48IxxuZMooMt7MWjqCH4SGLQ TutWkffqqeBbm+tjHpgN58ClaqeQSarxUlr2h+kDhSQQA53K2NoJbq8GPBLGOkX+9qvw q6bStwOyqsSKS6cC1J/NGsDV2rA6h/SufdSNlKJn/iWKJR/UyTGlXbDCkoAUM7hCFc5u tx8H1sjzxDhxkMLbbXFvX+t71weIJ6KNTR1vrNZA2j2uL9RvXMfyQM/ftUU8lAgQUQbi 9K+Q== Received: by 10.14.119.194 with SMTP id n42mr4700386eeh.113.1330699485025; Fri, 02 Mar 2012 06:44:45 -0800 (PST) Received: from green.tandem.local (184-174-132-95.pool.ukrtel.net. [95.132.174.184]) by mx.google.com with ESMTPS id c15sm21015421eei.9.2012.03.02.06.44.41 (version=SSLv3 cipher=OTHER); Fri, 02 Mar 2012 06:44:43 -0800 (PST) Message-ID: <4F50DCD8.9080603@gmail.com> Date: Fri, 02 Mar 2012 16:44:40 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120220 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: zfs fails to mount correctly during 8.2 -> 9.0 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:07:02 -0000 Hi all. I'm writing it just in case someone else will face this problem. Some days ago I was moving my last server from 8.2 to 9.0. At first I had installed kernel with: make KODIR=/boot/test installkernel and rebooted. At loader prompt I selected this kernel with: unload boot-conf /boot/test After that 9.0 kernel was loaded with 8.2 userland. I know this is not the right-and-only-one way of updating FreeBSD but it works for me through releases. But this time something strange happened. During system mount kernel spits out something like: Solaris: WARNING: metaslab_free_dva(): bad DVA 0:52834975928475 It was something like one page of this lines. The pool seems to be mounted readonly and refused to remount writable. It return zero empty space and status stated something about stopped scrub. Second pull was writable and working. However I haven't updated the userland so I just rebooted back to 8.2 kernel. Machine comes back online at full health. Everything stated both pools are healthy and working. Scrub doesn't yield any results - not a single error. I wiped /usr/obj and rebuilt everything from a scratch. After planting a test kernel and booting from it everything worked fine so I continued with upgrade. After upgrade was committed and pools were updated to ZFSv28 I repeated scrub on both. There was no single error. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 16:01:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 491C6106564A for ; Fri, 2 Mar 2012 16:01:00 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id CB6248FC13 for ; Fri, 2 Mar 2012 16:00:59 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBE06F.dip.t-dialin.net [93.203.224.111]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id q22FV9R0009388; Fri, 2 Mar 2012 15:31:10 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id q22FUwEg016550; Fri, 2 Mar 2012 16:30:58 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id q22FUjOU040478; Fri, 2 Mar 2012 16:30:57 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201203021530.q22FUjOU040478@fire.js.berklix.net> to: freebsd-fs@freebsd.org From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 01 Mar 2012 11:45:53 MST." <4F4FC3E1.5040700@freebsdfoundation.org> Date: Fri, 02 Mar 2012 16:30:44 +0100 Sender: jhs@berklix.com Cc: Deb Goodkin Subject: Re: [FreeBSD-Announce] Foundation Announces NAND File System for FreeBSD Project X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:01:00 -0000 Hi freebsd-fs@freebsd.org cc Deb Deb Goodkin wrote to announce@ Thu, 01 Mar 2012 11:45:53 -0700 (19:45 CET): > The FreeBSD Foundation is pleased to announce that Semihalf, an ... I was interested to read more background, but no URLs, so I found http://www.semihalf.com/ & re. NAND Flash File System found: http://en.wikipedia.org/wiki/Flash_memory#NAND_flash "Manufacturers try to maximize the amount of usable storage by shrinking the size of the transistor below the size where they can be made reliably, to the size where further reductions would increase the number of faults faster than it would increase the total storage available." - Really scarey if that is taken literaly, I jhs@ presume loose phraseology, hopefully someone who knows more will rephrase that :-). http://en.wikipedia.org/wiki/YAFFS http://www.yaffs.net/yaffs-nand-specific-flash-file-system-introductory-article GPL licence. Must release any linked sources. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, & indent with "> ". Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 16:28:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 990B11065676 for ; Fri, 2 Mar 2012 16:28:55 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45E668FC26 for ; Fri, 2 Mar 2012 16:28:50 +0000 (UTC) Received: by vcmm1 with SMTP id m1so385701vcm.13 for ; Fri, 02 Mar 2012 08:28:50 -0800 (PST) Received-SPF: pass (google.com: domain of fjwcash@gmail.com designates 10.52.36.176 as permitted sender) client-ip=10.52.36.176; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fjwcash@gmail.com designates 10.52.36.176 as permitted sender) smtp.mail=fjwcash@gmail.com; dkim=pass header.i=fjwcash@gmail.com Received: from mr.google.com ([10.52.36.176]) by 10.52.36.176 with SMTP id r16mr16925106vdj.84.1330705730456 (num_hops = 1); Fri, 02 Mar 2012 08:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lugs2pe76pPqrx1l8hsLGhXzZ34A0XqEB16u+Z/NSqQ=; b=Y3ZlI3Z6Puq3S2M7SR7U7dzBZo7NWGDNxAoVCxiRBBwhL0F6qQ2ezwwfbHkDl1cqkq kjqjNKBtVSMaMzedDeBRgdXxTa0yn6sdxSPIk5GEobCn11e21CNLIybcs7dgSlNWEG1F Rl0+r9CLL2lDWCbt+KyoBEcxlFuxqqvzuiGQNhlHsVqe4fRJsV9poBMo3oFn/ZCHBT7O 0JYAyulGgjIrQ6K7mrqyRiz4ymxYYziBW6dD/Al35ckwVs02NGSXibvkfPucG+PJqZ+d l0S/YCRzafIRbh9XnLHm4xJFPGQnTm/UVvZvN/1NQY7Hhb5HI56U2ydjZ1zM0uyk+ecb Gdsg== MIME-Version: 1.0 Received: by 10.52.36.176 with SMTP id r16mr14363276vdj.84.1330705730372; Fri, 02 Mar 2012 08:28:50 -0800 (PST) Received: by 10.220.178.74 with HTTP; Fri, 2 Mar 2012 08:28:50 -0800 (PST) In-Reply-To: <201203021530.q22FUjOU040478@fire.js.berklix.net> References: <4F4FC3E1.5040700@freebsdfoundation.org> <201203021530.q22FUjOU040478@fire.js.berklix.net> Date: Fri, 2 Mar 2012 08:28:50 -0800 Message-ID: From: Freddie Cash To: "Julian H. Stacey" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Deb Goodkin Subject: Re: [FreeBSD-Announce] Foundation Announces NAND File System for FreeBSD Project X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:28:55 -0000 On Fri, Mar 2, 2012 at 7:30 AM, Julian H. Stacey wrote: > Hi freebsd-fs@freebsd.org > cc Deb > > Deb Goodkin wrote to announce@ Thu, 01 Mar 2012 11:45:53 -0700 (19:45 CET= ): >> The FreeBSD Foundation is pleased to announce that Semihalf, an > ... > > I was interested to read more background, but no URLs, > so I found http://www.semihalf.com/ & re. > =C2=A0 =C2=A0 =C2=A0 =C2=A0NAND Flash File System > found: > =C2=A0http://en.wikipedia.org/wiki/Flash_memory#NAND_flash > =C2=A0 =C2=A0 =C2=A0 =C2=A0"Manufacturers try to maximize the amount of u= sable storage > =C2=A0 =C2=A0 =C2=A0 =C2=A0by shrinking the size of the transistor below = the size where > =C2=A0 =C2=A0 =C2=A0 =C2=A0they can be made reliably, to the size where f= urther > =C2=A0 =C2=A0 =C2=A0 =C2=A0reductions would increase the number of faults= faster than > =C2=A0 =C2=A0 =C2=A0 =C2=A0it would increase the total storage available.= " > =C2=A0 =C2=A0 =C2=A0 =C2=A0- > =C2=A0 Really scarey if that is taken literaly, I jhs@ presume loose phra= seology, > =C2=A0 =C2=A0 =C2=A0 =C2=A0hopefully someone who knows more will rephrase= that :-). A good primer on NAND Flash with lots of info on "the next hot thing", triple-level cell (TLC) flash, which has all the flaws of MLC multiplied many times over, but is a lot less expensive to use/make, so expect it to hit consumer drives this year. :( Page 3 is extremely enlightening about the issues, especially regarding the increased CRC requirements in order to actually read a valid bit from the cell. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 16:29:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D53AF106567C for ; Fri, 2 Mar 2012 16:29:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7AAA18FC23 for ; Fri, 2 Mar 2012 16:29:10 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2034022vbm.13 for ; Fri, 02 Mar 2012 08:29:09 -0800 (PST) Received-SPF: pass (google.com: domain of fjwcash@gmail.com designates 10.52.31.42 as permitted sender) client-ip=10.52.31.42; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fjwcash@gmail.com designates 10.52.31.42 as permitted sender) smtp.mail=fjwcash@gmail.com; dkim=pass header.i=fjwcash@gmail.com Received: from mr.google.com ([10.52.31.42]) by 10.52.31.42 with SMTP id x10mr17364074vdh.33.1330705749536 (num_hops = 1); Fri, 02 Mar 2012 08:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=F1IrIKVXFfNSF4ofEHF/MfpfASpcAFncYUIlF+FpMhE=; b=bPogz1gO4tTr5omO7oA8lCWC17meL4rAHvnxFOb5m+MMF/Z225tfZcx+LDi327CHUy NKCCRHqh+ixHpl2EFrubW6NwlSC48UQp09BdiJn1yqkr7aB4HM/OnwfuUyI67s7sarrO GH5b42plKWPhjuzkcgFiHGAMWw7GykGrpc4VoTk0yyLKG2Cdcnc7FBhC+a993pDCCJl9 6zFGEcFdQ4R5CcWVKZ1YBImd99P0uQfDWj3JhbeZ0RAPHVfd85OjMlBcdKyYpBAKjBxg ik3xCdvXFVEZ4OjTbDM2XNt+yr6bUHuDislFA2XI3kAkV/cpszyBAE86y3AXrto6X+ii Olzg== MIME-Version: 1.0 Received: by 10.52.31.42 with SMTP id x10mr14770150vdh.33.1330705749473; Fri, 02 Mar 2012 08:29:09 -0800 (PST) Received: by 10.220.178.74 with HTTP; Fri, 2 Mar 2012 08:29:09 -0800 (PST) In-Reply-To: References: <4F4FC3E1.5040700@freebsdfoundation.org> <201203021530.q22FUjOU040478@fire.js.berklix.net> Date: Fri, 2 Mar 2012 08:29:09 -0800 Message-ID: From: Freddie Cash To: "Julian H. Stacey" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Deb Goodkin Subject: Re: [FreeBSD-Announce] Foundation Announces NAND File System for FreeBSD Project X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:29:10 -0000 On Fri, Mar 2, 2012 at 8:28 AM, Freddie Cash wrote: > On Fri, Mar 2, 2012 at 7:30 AM, Julian H. Stacey wrote: >> Hi freebsd-fs@freebsd.org >> cc Deb >> >> Deb Goodkin wrote to announce@ Thu, 01 Mar 2012 11:45:53 -0700 (19:45 CE= T): >>> The FreeBSD Foundation is pleased to announce that Semihalf, an >> ... >> >> I was interested to read more background, but no URLs, >> so I found http://www.semihalf.com/ & re. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0NAND Flash File System >> found: >> =C2=A0http://en.wikipedia.org/wiki/Flash_memory#NAND_flash >> =C2=A0 =C2=A0 =C2=A0 =C2=A0"Manufacturers try to maximize the amount of = usable storage >> =C2=A0 =C2=A0 =C2=A0 =C2=A0by shrinking the size of the transistor below= the size where >> =C2=A0 =C2=A0 =C2=A0 =C2=A0they can be made reliably, to the size where = further >> =C2=A0 =C2=A0 =C2=A0 =C2=A0reductions would increase the number of fault= s faster than >> =C2=A0 =C2=A0 =C2=A0 =C2=A0it would increase the total storage available= ." >> =C2=A0 =C2=A0 =C2=A0 =C2=A0- >> =C2=A0 Really scarey if that is taken literaly, I jhs@ presume loose phr= aseology, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0hopefully someone who knows more will rephras= e that :-). > > A good primer on NAND Flash with lots of info on "the next hot thing", > triple-level cell (TLC) flash, which has all the flaws of MLC > multiplied many times over, but is a lot less expensive to use/make, > so expect it to hit consumer drives this year. =C2=A0:( =C2=A0Page 3 is > extremely enlightening about the issues, especially regarding the > increased CRC requirements in order to actually read a valid bit from > the cell. Let's try actually including the link this time: http://www.anandtech.com/show/5067/understanding-tlc-nand --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 16:48:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5154E106566C for ; Fri, 2 Mar 2012 16:48:37 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id ECACF8FC12 for ; Fri, 2 Mar 2012 16:48:36 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C459.dip.t-dialin.net [87.150.196.89]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1EB74844752; Fri, 2 Mar 2012 17:48:21 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 6A07514C9; Fri, 2 Mar 2012 17:48:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330706898; bh=jGDbQUanYy6bVMRxvvgy7kH4q9Rw/FTyywmqchy4yzE=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=lo/Rh2FauQRSSeQE/g7mODNY4lBF/yqE6/AdlwJLvDXg+P+NP9Y+n2AEUPzouXKkF djVFhp+J9vTLk8jpf3N0cG/ctWdxY5Ia2ZIJI9+kcJA8O15n0k+a9ERX9E7gfd53wP ixkqoIrsUPfkQtIIej74lf0vgQASVsSMCim4/+6qBW8BojkufOmR6/6h+3Iw9gh7Na thv9sDdvGwhTUoiCTFahjEZmLRGfqxZWeNX/labY2K1NCARlyAQFkOncFqqeggozAJ 2FBWS3UQocTk0k7DZJqyMvFkfIan0ZQCCEUAwe/HxJqzLY/ipFxzDIRz1YwuKMO5Ai ULfZVRl9IXbjw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q22GmHKO060155; Fri, 2 Mar 2012 17:48:17 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 02 Mar 2012 17:48:17 +0100 Date: Fri, 02 Mar 2012 17:48:14 +0100 Message-ID: <20120302174814.Horde.D12JcpjmRSRPUPnOdPNegTA@webmail.leidinger.net> From: Alexander Leidinger To: Volodymyr Kostyrko References: <4F50DCD8.9080603@gmail.com> In-Reply-To: <4F50DCD8.9080603@gmail.com> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1EB74844752.AEF35 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.654, required 6, autolearn=disabled, AWL -0.62, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZF 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331311703.52364@8HqfVaLQ9qLVSj3jnJVB+Q X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: zfs fails to mount correctly during 8.2 -> 9.0 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:48:37 -0000 Quoting Volodymyr Kostyrko (from Fri, 02 Mar 2012 16:44:40 +0200): > After that 9.0 kernel was loaded with 8.2 userland. I know this is > not the right-and-only-one way of updating FreeBSD but it works for > me through releases. But this time something strange happened. > During system mount kernel spits out something like: > > Solaris: WARNING: metaslab_free_dva(): bad DVA 0:52834975928475 > > It was something like one page of this lines. The ZFS in 9.0 and 8.3 detect some things in the pool which 8.2 does not detect. It seems that the boot with 9.0 repaired something in your pool, which 8.2 didn't detect. As you haven't provided the output of "zpool status -v" when the pool was in the RO state, it's less easy to determine what happened exactly. In short: problem solved, you're system is OK (according to the problem detection code of the scrub) now, no need to worry. Bye, Alexander: -- Within a computer, natural language is unnatural. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 21:36:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72267106576A; Fri, 2 Mar 2012 21:36:33 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 507F68FC17; Fri, 2 Mar 2012 21:36:33 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q22LaTvj037524; Fri, 2 Mar 2012 13:36:29 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201203022136.q22LaTvj037524@chez.mckusick.com> To: Ivan Voras In-reply-to: Date: Fri, 02 Mar 2012 13:36:29 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org Subject: Re: fsync: giving up on dirty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:36:33 -0000 > From: Ivan Voras > Date: Fri, 2 Mar 2012 12:57:00 +0100 > Subject: Re: fsync: giving up on dirty > To: Kirk McKusick > Cc: freebsd-fs@freebsd.org > > On 29 February 2012 20:19, Kirk McKusick wrote: > > > I believe that the problem is because the soft updates worklist needs > > to be flushed before some of the dirty blocks can be successfully written. > > If you are running a 9-stable system on this machine, are using journaled > > soft updates on the filesystem in question, and are willing to try out > > my first attempt at a fix, let me know and I'll send you the diffs for it. > > The thing is - I'm not. This is a 9-stable, but it was upgraded from 8 > and I don't have SUJ enabled. > > I keep getting such messages daily. > > Mar 1 04:02:09 skynet kernel: fsync: giving up on dirty > Mar 1 04:02:09 skynet kernel: 0xfffffe000fef2780: tag devfs, type VCHR > Mar 1 04:02:09 skynet kernel: usecount 1, writecount 0, refcount 2515 > mountedhere 0xfffffe000fd25200 > Mar 1 04:02:09 skynet kernel: flags () > Mar 1 04:02:09 skynet kernel: v_object 0xfffffe000fe96d98 ref 0 pages 10182 > Mar 1 04:02:09 skynet kernel: lock type devfs: EXCL by thread > 0xfffffe003dc8d000 (pid 79344) > Mar 1 04:02:09 skynet kernel: dev multipath/hpdisk4-web Thanks for the report. It is useful to know that this can occur even with non SUJ systems. I am working with Peter Holm to identify the cause and will keep you (and the list) posted with what we figure out. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 22:53:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E0061065672 for ; Fri, 2 Mar 2012 22:53:44 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 05F3C8FC08 for ; Fri, 2 Mar 2012 22:53:43 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q22MrHv5006069 for ; Fri, 2 Mar 2012 23:53:30 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q22MpkZR096948 for ; Fri, 2 Mar 2012 23:51:46 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q22MpkoV096945; Fri, 2 Mar 2012 23:51:46 +0100 (CET) (envelope-from arno) To: freebsd-fs@freebsd.org From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Fri, 02 Mar 2012 23:51:46 +0100 In-Reply-To: (Arno J. Klaassen's message of "Sun\, 19 Feb 2012 17\:54\:50 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F514F5D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F514F5D.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Subject: Re: 9-stable: one-device ZFS fails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 22:53:44 -0000 hello, [ old thread omitted; kept subject ] bon, I still see this behaviour, quite easy to reprodruce using an external disk connected via USB (I applied r232358 to rule out (as much as possible) other reasons. I know this is not the dreamt setup for ZFS (Dual Pentium T3400 with 3G of main memory), I permitt myself to repost, thinking it might indicate a problem (latest 9-stable, stripped GENERIC, initialy nothing in /boot/loader.conf, now vfs.zfs.arc_max="983040000" vfs.zfs.txg.timeout="5" vfs.zfs.write_limit_override="536870912" but that doesn't seem to bother). For info : [root@cc ~]# camcontrol devlist | fgrep pass2 at scbus4 target 0 lun 0 (da0,pass2) [root@cc ~]# dmesg -a | fgrep pass2 pass2 at umass-sim0 bus 0 scbus4 target 0 lun 0 pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number 00A123456813 pass2: 40.000MB/s transfers Then I do : zpool create zdisk /dev/da0 zfs zdisk/test zfs create zdisk/test cd /zdisk/test/ [put some data on it] Quite soon I get again : root@cc ~]# zpool status -v zdisk pool: zdisk state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: resilvered 182K in 0h0m with 0 errors on Fri Mar 2 23:02:01 2012 config: NAME STATE READ WRITE CKSUM zdisk ONLINE 0 1 0 da0 ONLINE 0 1 0 errors: Permanent errors have been detected in the following files: /zdisk/test/ [root@cc ~]# Same kind of error as for my original post, though this time even the system doesn't seem to believe it : [root@cc ~]# cat /zdisk/test/ > /dev/null [root@cc ~]# md5 /zdisk/test/ = 764a10604b8c0076ec8955a2a35c0b57 ( the "orginal" ... : ) [root@cc ~]# md5 /zgeli/home/ MD5 (/zgeli/home/ = 764a10604b8c0076ec8955a2a35c0b57 I made a 12-part raidz on the original disk I reported this problem on : [root@cc /]# gpart show => 63 976773105 ada0 MBR (465G) 63 79691409 1 ntfs (38G) 79691472 67108608 2 freebsd [active] (32G) 146800080 829973088 3 freebsd (395G) => 0 67108608 ada0s2 BSD (32G) 0 4194304 1 freebsd-ufs (2.0G) 4194304 6340608 2 freebsd-swap (3.0G) 10534912 56573696 5 freebsd-ufs (27G) => 0 103746635 ada0s3.eli BSD (395G) 0 8645542 1 freebsd-zfs (33G) 8645542 8645542 2 freebsd-zfs (33G) 17291084 8645542 4 freebsd-zfs (33G) 25936626 8645542 5 freebsd-zfs (33G) 34582168 8645542 6 freebsd-zfs (33G) 43227710 8645542 7 freebsd-zfs (33G) 51873252 8645542 8 freebsd-zfs (33G) 60518794 8645542 9 freebsd-zfs (33G) 69164336 8645542 10 freebsd-zfs (33G) 77809878 8645542 11 freebsd-zfs (33G) 86455420 8645542 12 freebsd-zfs (33G) 95100962 8645542 13 freebsd-zfs (33G) 103746504 131 - free - (524k) [root@cc /]# Works like a charm .... : [root@cc /]# zpool status zgeli pool: zgeli state: ONLINE scan: scrub repaired 0 in 4h56m with 0 errors on Sun Feb 26 18:54:11 2012 config: NAME STATE READ WRITE CKSUM zgeli ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada0s3.elia ONLINE 0 0 0 ada0s3.elib ONLINE 0 0 0 ada0s3.elid ONLINE 0 0 0 ada0s3.elie ONLINE 0 0 0 ada0s3.elif ONLINE 0 0 0 ada0s3.elig ONLINE 0 0 0 ada0s3.elih ONLINE 0 0 0 ada0s3.elii ONLINE 0 0 0 ada0s3.elij ONLINE 0 0 0 ada0s3.elik ONLINE 0 0 0 ada0s3.elil ONLINE 0 0 0 ada0s3.elim ONLINE 0 0 0 errors: No known data errors I know, bis; nobody else reported this kind of a problem; but I'm really not aware of doing something other than usual (rather than testing ZFS on a might be underpowered notebook) ... Willing to help, best, Arno From owner-freebsd-fs@FreeBSD.ORG Sat Mar 3 06:10:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 996CF106564A for ; Sat, 3 Mar 2012 06:10:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3998FC17 for ; Sat, 3 Mar 2012 06:10:41 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q236ANUh025810 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 22:10:27 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F51B5D4.4070005@freebsd.org> Date: Fri, 02 Mar 2012 22:10:28 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201203021530.q22FUjOU040478@fire.js.berklix.net> In-Reply-To: <201203021530.q22FUjOU040478@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: [FreeBSD-Announce] Foundation Announces NAND File System for FreeBSD Project X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 06:10:42 -0000 On 3/2/12 7:30 AM, Julian H. Stacey wrote: > Hi freebsd-fs@freebsd.org > cc Deb > > Deb Goodkin wrote to announce@ Thu, 01 Mar 2012 11:45:53 -0700 (19:45 CET): >> The FreeBSD Foundation is pleased to announce that Semihalf, an > ... > > I was interested to read more background, but no URLs, > so I found http://www.semihalf.com/& re. > NAND Flash File System > found: > http://en.wikipedia.org/wiki/Flash_memory#NAND_flash > "Manufacturers try to maximize the amount of usable storage > by shrinking the size of the transistor below the size where > they can be made reliably, to the size where further > reductions would increase the number of faults faster than > it would increase the total storage available." > - > Really scarey if that is taken literaly, I jhs@ presume loose phraseology, > hopefully someone who knows more will rephrase that :-). working for a flash memory based company I can say that flash is getting crappier and crappier. Slower, less reliable, more damaged by overuse, more sensitive to temperature, etc. etc. we're talking about sensing the difference between 100 trapped electrons and 75 trapped electrons. > http://en.wikipedia.org/wiki/YAFFS > > http://www.yaffs.net/yaffs-nand-specific-flash-file-system-introductory-article > GPL licence. Must release any linked sources. > > Cheers, > Julian From owner-freebsd-fs@FreeBSD.ORG Sat Mar 3 08:33:39 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E656106564A for ; Sat, 3 Mar 2012 08:33:39 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id DB7608FC12 for ; Sat, 3 Mar 2012 08:33:38 +0000 (UTC) Received: by eaaf13 with SMTP id f13so853904eaa.13 for ; Sat, 03 Mar 2012 00:33:31 -0800 (PST) Received-SPF: pass (google.com: domain of c.kworr@gmail.com designates 10.14.37.7 as permitted sender) client-ip=10.14.37.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of c.kworr@gmail.com designates 10.14.37.7 as permitted sender) smtp.mail=c.kworr@gmail.com; dkim=pass header.i=c.kworr@gmail.com Received: from mr.google.com ([10.14.37.7]) by 10.14.37.7 with SMTP id x7mr7666224eea.90.1330763611952 (num_hops = 1); Sat, 03 Mar 2012 00:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5kaE1VPUTnWa75t3gwzUcMHCwM/h+mO0x9cn+67ZBTA=; b=DT5UfyRe2RliFLPW/NjSgjMa2/TmYHrBNvLIb4eIJsS14g07vSO2qHe0M6769jTAwA FkvSjO/Bt8j+KhXGEb5kPiCwyKrGO7QX/klFF7IeWLzaSpp/XPsCEuxMmKTtkq5Y7XPi 7X4AD2QR+KAuRnf4xXkQXzfI0aIrkt5Cl2l17b+TWLxg6va4IXpfK5RVVrl41YH73Aw3 lgn+9kkBUToLl84pzNLgOXCQg5Uzo4uHkZmYwcWHfZbXkiVOr7TB+fB8+WDFk2OLfMHq u4vabjsfUDYANYIWp5Njus60nVewOue9FHux8X70qg2zgLa9MRPGsbLNOwDg2M9H6Q2a cuew== Received: by 10.14.37.7 with SMTP id x7mr5891431eea.90.1330763611849; Sat, 03 Mar 2012 00:33:31 -0800 (PST) Received: from green.tandem.local (184-174-132-95.pool.ukrtel.net. [95.132.174.184]) by mx.google.com with ESMTPS id n17sm31014352eei.3.2012.03.03.00.33.29 (version=SSLv3 cipher=OTHER); Sat, 03 Mar 2012 00:33:30 -0800 (PST) Message-ID: <4F51D758.7070504@gmail.com> Date: Sat, 03 Mar 2012 10:33:28 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120220 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: Alexander Leidinger References: <4F50DCD8.9080603@gmail.com> <20120302174814.Horde.D12JcpjmRSRPUPnOdPNegTA@webmail.leidinger.net> In-Reply-To: <20120302174814.Horde.D12JcpjmRSRPUPnOdPNegTA@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs fails to mount correctly during 8.2 -> 9.0 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 08:33:39 -0000 Alexander Leidinger wrote: > Quoting Volodymyr Kostyrko (from Fri, 02 Mar 2012 > 16:44:40 +0200): > >> After that 9.0 kernel was loaded with 8.2 userland. I know this is not >> the right-and-only-one way of updating FreeBSD but it works for me >> through releases. But this time something strange happened. During >> system mount kernel spits out something like: >> >> Solaris: WARNING: metaslab_free_dva(): bad DVA 0:52834975928475 >> >> It was something like one page of this lines. > > The ZFS in 9.0 and 8.3 detect some things in the pool which 8.2 does not > detect. It seems that the boot with 9.0 repaired something in your pool, > which 8.2 didn't detect. As you haven't provided the output of "zpool > status -v" when the pool was in the RO state, it's less easy to > determine what happened exactly. I know that 9.0 can fix more things that 8.2. But I doubt 9.0 this time fixed anything as it comes up with pool in readonly state. Maybe something was fixed by 9.0 or maybe by scrub. I don't care really. The machine is in production and problem is solved. Anyway I just added a task to my list to recreate all upgraded pools when this would be available. I haven't include output for "zpool status" because it was partially gibberish due to running 8.2 tools with 8.2 lib over 9.0 module. However as I recall it hasn't pointed any errors. > In short: problem solved, you're system is OK (according to the problem > detection code of the scrub) now, no need to worry. I known, I know... I just ended up thinking that raising my voice to inform others of possible flaws and clues even without full data can help someone to investigate it better. Like this one: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/144214 -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 3 09:30:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45B52106566B for ; Sat, 3 Mar 2012 09:30:43 +0000 (UTC) (envelope-from davide.damico@contactlab.com) Received: from mail2.shared.smtp.contactlab.it (mail2.shared.smtp.contactlab.it [93.94.37.7]) by mx1.freebsd.org (Postfix) with ESMTP id 210CB8FC08 for ; Sat, 3 Mar 2012 09:30:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=contactlab.com; s=s768; c=relaxed/relaxed; q=dns/txt; i=@contactlab.com; t=1330765221; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=UD30V9oGnyRvWxA/SDpQV5SPNKI=; b=on27wpXVw/FhD/6mG64pgfZgNvtWWbfJPaW5iu+OmDqG9wJpeqPpAPx13l672+FO LXylgeeWc+CqSWSFxTrVlvpuVwsiBSVfANi8+X4p98Em9cfsIqHQdilhNGKhZ+DB; Received: from [213.92.90.12] ([213.92.90.12:46751] helo=mail3.tomato.it) by t.contactlab.it (envelope-from ) (ecelerity 3.2.3.43244 r(43244)) with ESMTP id 2E/46-07734-5ADD15F4; Sat, 03 Mar 2012 10:00:21 +0100 Received: from mx3-master.housing.tomato.lan ([172.16.7.55]) by mail3.tomato.it with smtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S3kpB-000EST-82 for freebsd-fs@freebsd.org; Sat, 03 Mar 2012 10:00:21 +0100 Received: (qmail 55577 invoked by uid 80); 3 Mar 2012 09:00:21 -0000 To: X-PHP-Script: uebmeil.sys.tomatointeractive.it/index.php for 213.92.90.4, 213.92.90.4 X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 03 Mar 2012 10:00:21 +0100 From: Davide D'Amico Organization: ContactLab Mail-Reply-To: Message-ID: X-Sender: davide.damico@contactlab.com User-Agent: Roundcube Webmail/0.7.1 Subject: FreeBSD 8.2-p5 and Perc6/i X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davide.damico@contactlab.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 09:30:43 -0000 Hi all, I've a couple of dell r410 servers (smtp1 and smtp2) in production with the same hw config: # mfiutil show firmware mfi0 Firmware Package Version: 6.3.0-0001 mfi0 Firmware Images: Name Version Date Time Status APP 1.22.12-0952 Jul 27 2010 16:44:00 active BIOS 2.04.00 active BCON 1.1-46-e_15-Rel Mar 2 2008 14:06:08 active CTLR 1.02-015B Jan 27 2009 12:02:58 active PCLI 01.00-023:#%00006 Nov 25 2008 17:21:50 active BTBL 1.00.00.01-0011 Nov 27 2007 18:29:20 active # mfiutil show volumes mfi0 Volumes: Id Size Level Stripe State Cache Name mfid0 ( 279G) RAID-1 64K OPTIMAL Enabled # mfiutil show drives mfi0 Physical Drives: ( 279G) ONLINE SAS enclosure 1, slot 0 ( 279G) ONLINE SAS enclosure 1, slot 1 # mfiutil show volumes mfi0 Volumes: Id Size Level Stripe State Cache Name mfid0 ( 279G) RAID-1 64K OPTIMAL Enabled # uname -a FreeBSD smtp2 8.2-RELEASE-p6 FreeBSD 8.2-RELEASE-p6 #1: Mon Feb 27 11:17:40 CET 2012 root@smtp2:/usr/obj/usr/src/sys/R410 amd64 # smtp1 has no problem on its perc controller, but smtp2 sometimes (1 or 2 times every day) freezes up and I find in user.log (I use syslog-ng): Mar 2 22:29:59.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1784 SECONDS Mar 2 22:30:29.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1814 SECONDS Mar 2 22:30:59.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1844 SECONDS Mar 2 22:31:29.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1874 SECONDS Mar 2 22:31:59.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1904 SECONDS Mar 2 22:32:29.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1934 SECONDS Mar 2 22:32:59.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1964 SECONDS Mar 2 22:33:29.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 1994 SECONDS Mar 2 22:33:59.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 2024 SECONDS Mar 2 22:34:29.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 2054 SECONDS Mar 2 22:34:59.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 2084 SECONDS Mar 2 22:35:29.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 2114 SECONDS Mar 2 22:35:59.056 smtp2 mfi0: COMMAND 0xffffff80009aa7f8 TIMEOUT AFTER 2144 SECONDS During these periods, the server becomes unresponsive and this is bad. smtp2 isn't very "load": 1 users Load 0.00 0.00 0.00 Mar 3 09:57 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 388136 6276 2322812 7796 14973k count All 522452 7448 1076201k 19580 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 32010 total 147 467 3 203 10 167 zfod atkbd0 1 ozfod irq0: 0.0%Sys 0.0%Intr 0.0%User 0.0%Nice 100%Idle %ozfod stray irq0 | | | | | | | | | | | daefr 1 ehci0 19 prcfr uhci2 uhci 10 dtbuf totfr mfi0 irq38 Namei Name-cache Dir-cache 333647 desvn react 2000 cpu0: time Calls hits % hits % 130182 numvn pdwak 9 bce1 257 155 155 100 80196 frevn pdpgs 2000 cpu1: time intrn 2000 cpu9: time Disks mfid0 891628 wire 2000 cpu6: time KB/t 0.00 339876 act 2000 cpu8: time tps 0 35168 inact 2000 cpu5: time MB/s 0.00 2420 cache 2000 cpu14: tim %busy 0 14970588 free 2000 cpu7: time 1103136 buf 2000 cpu11: tim 2000 cpu4: time 2000 cpu15: tim 2000 cpu2: time 2000 cpu10: tim 2000 cpu3: time 2000 cpu12: tim 2000 cpu13: tim smtp2 hasn't any disk crunching cron job, daemon or service running. Is it a hw problem on the controller or a compatibility problem? Upgrading to 9.0-RELEASE could solve this issue? Thanks in advance, d. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 3 09:48:27 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1542106564A for ; Sat, 3 Mar 2012 09:48:27 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55F2B8FC08 for ; Sat, 3 Mar 2012 09:48:27 +0000 (UTC) Received: by ghrr20 with SMTP id r20so1294652ghr.13 for ; Sat, 03 Mar 2012 01:48:26 -0800 (PST) Received-SPF: pass (google.com: domain of kraduk@gmail.com designates 10.236.200.230 as permitted sender) client-ip=10.236.200.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kraduk@gmail.com designates 10.236.200.230 as permitted sender) smtp.mail=kraduk@gmail.com; dkim=pass header.i=kraduk@gmail.com Received: from mr.google.com ([10.236.200.230]) by 10.236.200.230 with SMTP id z66mr18632979yhn.20.1330768106905 (num_hops = 1); Sat, 03 Mar 2012 01:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YBRiUv9MGA2g7+9jM7peT8QAucTiJY+SEVVoSoV0jsY=; b=ZvAvl73+27lSstp6YlnlE7MyAylOmN58XqBt2w9rN9n9i6wHKzJWinhXeeKLzuMtT1 VOYacIDM6tESo2LqerkRkZrRJgvDrtmq+yg7+amTbi5DYkYvBlcqYXq47Aq35csj2RRY cjsGS55FTRFvVZTcBwIrMODRcHCHV9Gq9oTU9XXoZm2VI63tt9St9n+V/uSTOP5UoHI3 cIwNr736/f1v4dsnKNhJU8zVzp9n0z4BZLs8fw8jOtjlgpt1DvABpfIUIUjUzCgoDGoh VkyKJrwAYhi+uRsgSIi04DwQ87qR0PDkg3g/EvPko6F/nCI8Mw2Obw2bpSNyrskOemA2 qeCQ== MIME-Version: 1.0 Received: by 10.236.200.230 with SMTP id z66mr14722785yhn.20.1330768106841; Sat, 03 Mar 2012 01:48:26 -0800 (PST) Received: by 10.236.22.7 with HTTP; Sat, 3 Mar 2012 01:48:26 -0800 (PST) In-Reply-To: <4F50DCD8.9080603@gmail.com> References: <4F50DCD8.9080603@gmail.com> Date: Sat, 3 Mar 2012 09:48:26 +0000 Message-ID: From: krad To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: zfs fails to mount correctly during 8.2 -> 9.0 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 09:48:27 -0000 On 2 March 2012 14:44, Volodymyr Kostyrko wrote: > Hi all. > > I'm writing it just in case someone else will face this problem. > > Some days ago I was moving my last server from 8.2 to 9.0. At first I had > installed kernel with: > > make KODIR=/boot/test installkernel > > and rebooted. At loader prompt I selected this kernel with: > > unload > boot-conf /boot/test > > After that 9.0 kernel was loaded with 8.2 userland. I know this is not the > right-and-only-one way of updating FreeBSD but it works for me through > releases. But this time something strange happened. During system mount > kernel spits out something like: > > Solaris: WARNING: metaslab_free_dva(): bad DVA 0:52834975928475 > > It was something like one page of this lines. > > The pool seems to be mounted readonly and refused to remount writable. It > return zero empty space and status stated something about stopped scrub. > Second pull was writable and working. However I haven't updated the > userland so I just rebooted back to 8.2 kernel. > > Machine comes back online at full health. Everything stated both pools are > healthy and working. Scrub doesn't yield any results - not a single error. > > I wiped /usr/obj and rebuilt everything from a scratch. After planting a > test kernel and booting from it everything worked fine so I continued with > upgrade. After upgrade was committed and pools were updated to ZFSv28 I > repeated scrub on both. There was no single error. > > -- > Sphinx of black quartz judge my vow. > ______________________________**_________________ > 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 have generally found this stepped method of booting into the new kernel with the old userland as a bad thing with zfs. Especially if there is a zfs version bump in the new build. This is due the the user land zfs tools being out of sync with the kernel. What I have found works much better is to clone your zfs root file system, mount it somewhere, set DESTDIR to there and install world and kernel. Then tweak the loader.conf on the relevent fs and the pools bootfs property accordingly. Unmount the new root fs and set the mountpoint the legacy, then reboot. If you get problems with the new build just boot in with a live ios and reset the bootfs property of the pool to the old value. I wish the last step could be done from the loader prompt but as far as i can see you cant yet 8( From owner-freebsd-fs@FreeBSD.ORG Sat Mar 3 11:36:52 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8279D106564A for ; Sat, 3 Mar 2012 11:36:52 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 05A738FC13 for ; Sat, 3 Mar 2012 11:36:51 +0000 (UTC) Received: by eaaf13 with SMTP id f13so891008eaa.13 for ; Sat, 03 Mar 2012 03:36:51 -0800 (PST) Received-SPF: pass (google.com: domain of c.kworr@gmail.com designates 10.14.39.145 as permitted sender) client-ip=10.14.39.145; Authentication-Results: mr.google.com; spf=pass (google.com: domain of c.kworr@gmail.com designates 10.14.39.145 as permitted sender) smtp.mail=c.kworr@gmail.com; dkim=pass header.i=c.kworr@gmail.com Received: from mr.google.com ([10.14.39.145]) by 10.14.39.145 with SMTP id d17mr6995658eeb.86.1330774611006 (num_hops = 1); Sat, 03 Mar 2012 03:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=APO+GrupiHapVuQu38oM/FcU7BhENry6sIoTUaoQb/g=; b=kX9caoK5yIBCwHcMw4MS+2Mf16O/CBpWNGMNZZGX5J4/zGMZUHlLkN5VWS+lDPN0ry yeSiFI1il/h29doALShPosy3zBZbEikyKy+bnxl5brAFGWiXBYkXdlsoz3CXR400FS2f CjeddNz8BA2jIUKVd3ZDjmJVBf36Ookbh2j3y/HJPwzbEsO6jE/7zyZpKg7SnizHkn1n 8jgWAqcrxOc8Tk1rKtzdVlQ7w3PDA6VUnGfirUwv6SiIoT2qJB6qy8yyNZl5XZc1c+C3 wngLsfQCgKZ8YkO8Xu/APbOYUtFZcR0RrtnFO/6sVoY0WdqF5pHKrvNaRQF8MB80Rvj+ ns6Q== Received: by 10.14.39.145 with SMTP id d17mr5359155eeb.86.1330774610897; Sat, 03 Mar 2012 03:36:50 -0800 (PST) Received: from green.tandem.local (73-193-200-46.pool.ukrtel.net. [46.200.193.73]) by mx.google.com with ESMTPS id u11sm32950873eeb.1.2012.03.03.03.36.49 (version=SSLv3 cipher=OTHER); Sat, 03 Mar 2012 03:36:50 -0800 (PST) Message-ID: <4F520250.7090402@gmail.com> Date: Sat, 03 Mar 2012 13:36:48 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120220 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: krad References: <4F50DCD8.9080603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs fails to mount correctly during 8.2 -> 9.0 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 11:36:52 -0000 krad wrote: > I have generally found this stepped method of booting into the new kernel > with the old userland as a bad thing with zfs. Especially if there is a zfs > version bump in the new build. This is due the the user land zfs tools > being out of sync with the kernel. What I have found works much better is > to clone your zfs root file system, mount it somewhere, set DESTDIR to > there and install world and kernel. Then tweak the loader.conf on the > relevent fs and the pools bootfs property accordingly. Unmount the new > root fs and set the mountpoint the legacy, then reboot. If you get problems > with the new build just boot in with a live ios and reset the bootfs > property of the pool to the old value. I wish the last step could be done > from the loader prompt but as far as i can see you cant yet 8( I know, this is rather "works for me" way of updating. However zfs userland is mostly not used for booting from or mounting zfs so its generally safe if the minimal set of commands for activating zfs works. This minimal set consists of: zfs mount -a zfs share -a And as far as I recall kernel interface for those was never touched so the previous tools work with new kernel module. One can even run new version of tools without installing them to system by creating some catalog in tmp and copying libraries and tools from /usr/obj to this catalog. Actually as far as I recall only thing bootfs flag does is refusing some advanced features like adding separate log/cache device. The system boots fine regardless bootfs setting. So mounting another file system as a root can be accomplished by setting or changing vfs.root.mountfrom at loader prompt. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 3 12:43:40 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14106106564A for ; Sat, 3 Mar 2012 12:43:40 +0000 (UTC) (envelope-from shuey@fmepnet.org) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id BED2D8FC12 for ; Sat, 3 Mar 2012 12:43:39 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2790790vbm.13 for ; Sat, 03 Mar 2012 04:43:39 -0800 (PST) Received-SPF: pass (google.com: domain of shuey@fmepnet.org designates 10.52.93.77 as permitted sender) client-ip=10.52.93.77; Authentication-Results: mr.google.com; spf=pass (google.com: domain of shuey@fmepnet.org designates 10.52.93.77 as permitted sender) smtp.mail=shuey@fmepnet.org Received: from mr.google.com ([10.52.93.77]) by 10.52.93.77 with SMTP id cs13mr22947622vdb.71.1330778619143 (num_hops = 1); Sat, 03 Mar 2012 04:43:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.77 with SMTP id cs13mr19604254vdb.71.1330778619071; Sat, 03 Mar 2012 04:43:39 -0800 (PST) Received: by 10.220.48.196 with HTTP; Sat, 3 Mar 2012 04:43:39 -0800 (PST) X-Originating-IP: [98.223.59.225] In-Reply-To: <4F50DCD8.9080603@gmail.com> References: <4F50DCD8.9080603@gmail.com> Date: Sat, 3 Mar 2012 07:43:39 -0500 Message-ID: From: Michael Shuey To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn0iY/FN0HGlaVJyBwsZu1jIwhGO6BDB/v0wub3mdAuNpyXJGqk8P9dGoQ6PISXggRqfUpo Cc: freebsd-fs@freebsd.org Subject: Re: zfs fails to mount correctly during 8.2 -> 9.0 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 12:43:40 -0000 I hit this exact problem when I upgraded. Rebooting back to 8.2's kernel, and scrubbing (under 8.2), then rebooting to 8.2, then rebooting to 9.0's kernel, fixed it for me. On Fri, Mar 2, 2012 at 9:44 AM, Volodymyr Kostyrko wrot= e: > Hi all. > > I'm writing it just in case someone else will face this problem. > > Some days ago I was moving my last server from 8.2 to 9.0. At first I had > installed kernel with: > > =A0make KODIR=3D/boot/test installkernel > > and rebooted. At loader prompt I selected this kernel with: > > =A0unload > =A0boot-conf /boot/test > > After that 9.0 kernel was loaded with 8.2 userland. I know this is not th= e > right-and-only-one way of updating FreeBSD but it works for me through > releases. But this time something strange happened. During system mount > kernel spits out something like: > > =A0Solaris: WARNING: metaslab_free_dva(): bad DVA 0:52834975928475 > > It was something like one page of this lines. > > The pool seems to be mounted readonly and refused to remount writable. It > return zero empty space and status stated something about stopped scrub. > Second pull was writable and working. However I haven't updated the userl= and > so I just rebooted back to 8.2 kernel. > > Machine comes back online at full health. Everything stated both pools ar= e > healthy and working. Scrub doesn't yield any results - not a single error= . > > I wiped /usr/obj and rebuilt everything from a scratch. After planting a > test kernel and booting from it everything worked fine so I continued wit= h > upgrade. After upgrade was committed and pools were updated to ZFSv28 I > repeated scrub on both. There was no single error. > > -- > Sphinx of black quartz judge my vow. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Mar 3 14:25:46 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D09A1065744 for ; Sat, 3 Mar 2012 14:25:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8E46E8FC17 for ; Sat, 3 Mar 2012 14:25:45 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA07108; Sat, 03 Mar 2012 16:25:42 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F5229E5.4010809@FreeBSD.org> Date: Sat, 03 Mar 2012 16:25:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120221 Thunderbird/10.0.2 MIME-Version: 1.0 To: krad References: <4F50DCD8.9080603@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Volodymyr Kostyrko Subject: Re: zfs fails to mount correctly during 8.2 -> 9.0 update X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 14:25:46 -0000 on 03/03/2012 11:48 krad said the following: > What I have found works much better is > to clone your zfs root file system, mount it somewhere, set DESTDIR to > there and install world and kernel. Then tweak the loader.conf on the > relevent fs and the pools bootfs property accordingly. Unmount the new > root fs and set the mountpoint the legacy, then reboot. If you get problems > with the new build just boot in with a live ios and reset the bootfs > property of the pool to the old value. I wish the last step could be done > from the loader prompt but as far as i can see you cant yet 8( See these patches: https://gitorious.org/~avg/freebsd/avgbsd/commit/1ffe908762d7fc5c132fc711e50e6f1a6db5f19b https://gitorious.org/~avg/freebsd/avgbsd/commit/7db964b9b69e7cd77260a70a3e300fe10f33b5b1 Unfortunately I can't seem to find time to finish them. -- Andriy Gapon