From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 06:22:35 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 4290F106566B; Mon, 9 Apr 2012 06:22:35 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE778FC08; Mon, 9 Apr 2012 06:22:34 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKT4KAJEpfMiU2CdpExOIQt+JzhEGJb7+t@postini.com; Sun, 08 Apr 2012 23:22:34 PDT Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 9 Apr 2012 02:27:34 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 9 Apr 2012 02:22:27 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 9 Apr 2012 11:52:24 +0530 From: "Desai, Kashyap" To: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= , "Kirk McKusick" Date: Mon, 9 Apr 2012 11:52:22 +0530 Thread-Topic: Kernel crash at "softdep_deallocate_dependencies" Thread-Index: Ac0ULTFrKrXpfHM7RceBRgQ+7I27bQB684OQ Message-ID: References: <20120406130006.GC1336@garage.freebsd.pl> <201204061721.q36HLTj6030692@chez.mckusick.com> <20120406194047.GA1673@strashydlo.local> In-Reply-To: <20120406194047.GA1673@strashydlo.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-fs@freebsd.org" , Pawel Jakub Dawidek , "Kenneth D.Merry" , "McConnell, Stephen" Subject: RE: Kernel crash at "softdep_deallocate_dependencies" 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, 09 Apr 2012 06:22:35 -0000 Thanks for such wonderful technical discussion. Things are now clear and w= e are planning to do some experiment based on your feedback. ~ Kashyap > -----Original Message----- > From: Edward Tomasz Napiera=B3a [mailto:etnapierala@googlemail.com] On > Behalf Of Edward Tomasz Napierala > Sent: Saturday, April 07, 2012 1:11 AM > To: Kirk McKusick > Cc: Desai, Kashyap; freebsd-fs@freebsd.org; Kenneth D.Merry; Pawel Jakub > Dawidek; McConnell, Stephen > Subject: Re: Kernel crash at "softdep_deallocate_dependencies" >=20 > On Fri, Apr 06, 2012 at 10:21:29AM -0700, Kirk McKusick wrote: > > Following through on Pawel Jakub Dawidek's comments, there is no > > way that the filesystem can recover when a large piece of its has > > disappeared. The panic that you are getting is because the soft > > updates system realizes that allowing writes to continue on the > > filesystem will cause it to be corrupted in an unrepairable way. > > As it has no way to cleanly downgrade it to read-only or unmount > > it, its only choice is to panic. >=20 > Actually, there is a third way, which is what UFS mounted without > softupdates does: do nothing. This works, because when ENXIO gets > returned, the device is already gone. >=20 > > If you do not like this panic, you can disable soft updates using: > > > > tunefs -n disable > > > > Absent the soft updates integrity checking, the filesystem will > > carry on a good bit longer (though after a reboot it will likely > > be unrecoverable even if you have put the disk back into it). >=20 > Apart of a situation where ENXIO would be returned, but the device > would stay accessible, which doesn't happen, afaik, what will actually > happen is that all the operations on a filesystem will return ENXIO, > except for reads for which the data is still in cache. Nothing will > get written, so no further damage will be done, and it will be possible > to forcibly unmount the filesystem without panicing. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 11:07:11 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 396DE1065670 for ; Mon, 9 Apr 2012 11:07:11 +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 22FFF8FC14 for ; Mon, 9 Apr 2012 11:07:11 +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 q39B7BHI039590 for ; Mon, 9 Apr 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q39B7ALT039588 for freebsd-fs@FreeBSD.org; Mon, 9 Apr 2012 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Apr 2012 11:07:10 GMT Message-Id: <201204091107.q39B7ALT039588@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, 09 Apr 2012 11:07:11 -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/166566 fs [zfs] zfs split renders 2 disk (MBR based) mirror unbo o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu 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/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 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 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 264 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 11:58:58 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 315241065676 for ; Mon, 9 Apr 2012 11:58:58 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB8C18FC15 for ; Mon, 9 Apr 2012 11:58:57 +0000 (UTC) Received: by lbok6 with SMTP id k6so2440271lbo.13 for ; Mon, 09 Apr 2012 04:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=33kiFSs2kEPf5Dk/4u3C7Pzil4vWYeZI8v4V7MDpRl4=; b=I3FUB3dc+vbbHWeuYz4c/Q/CdJXz2L3MtvNrj1u7w2dingQXjK9xM3udeRgi7OaTgG C2MRikDoXWEpkRK+szgIoMVMg+9zyElkvZ+imF0auxmEgf51l2xQseYbqnqgY0fGwlM/ AY6wbDuRkvQtBzVwLSPkMqQ5XUZGAMxRWzDZ5Np91OeJsahj3akcmQxWC0fP6/O9DhcP zNUmDI8ngHhWtOFLWAfeGWgn87AtMksJyuiEN81RtOXN5PHwi4PMu7xLNJ6P4U920b6Q 9eB3VEKtSn/oLprovoHOy6IL0QQhVE16jKdS/4jcutJ9erc0/FFr8tkslfnY22FVVx7Z XlTQ== MIME-Version: 1.0 Received: by 10.152.125.41 with SMTP id mn9mr11057672lab.30.1333972730598; Mon, 09 Apr 2012 04:58:50 -0700 (PDT) Received: by 10.152.25.69 with HTTP; Mon, 9 Apr 2012 04:58:50 -0700 (PDT) Date: Mon, 9 Apr 2012 15:58:50 +0400 Message-ID: From: Sergey Kandaurov To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [patch] ufs extattr panic w/ quota under DIAGNOSTIC 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, 09 Apr 2012 11:58:58 -0000 Hi. This is a patch to fix ufs extattr panic seen when trying to set extended attributes on a file system with quotas enabled and options DIAGNOSTIC. # setextattr system md5 `md5 -q /boot/kernel/kernel` /boot/kernel/kernel The problem is that when getting at chkdquot() from UFS_BALLOC() it is expected that the vnode to operate extattr on was "prepared" with getinoquota(). This assertion is explicitly turned off for snapshots and quota files by setting VV_SYSTEM vnode flag. This is probably should be also done for extended attributes. Index: sys/ufs/ffs/ffs_vnops.c =================================================================== --- sys/ufs/ffs/ffs_vnops.c (revision 233936) +++ sys/ufs/ffs/ffs_vnops.c (working copy) @@ -1681,6 +1681,8 @@ vop_setextattr { return (error); } + ap->a_vp->v_vflag |= VV_SYSTEM; + error = ffs_open_ea(ap->a_vp, ap->a_cred, ap->a_td); if (error) return (error); chkdquot: missing dquot 0xfffffe00483744e0: tag ufs, type VREG usecount 1, writecount 0, refcount 567 mountedhere 0 flags () v_object 0xfffffe004839bbc8 ref 0 pages 2260 lock type ufs: EXCL by thread 0xfffffe004844a000 (pid 11419, setextattr, tid 100136) #9 0xffffffff804380f7 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:633 #10 0xffffffff80666f94 in chkdquot (ip=0xfffffe00669749d8) at /usr/src/sys/ufs/ufs/ufs_quota.c:479 #11 0xffffffff8066765c in chkdq (ip=0xfffffe00669749d8, change=4, cred=0xfffffe0071d0a800, flags=0) at /usr/src/sys/ufs/ufs/ufs_quota.c:174 #12 0xffffffff80632879 in ffs_alloc (ip=0xfffffe00669749d8, lbn=Variable "lbn" is not available. ) at /usr/src/sys/ufs/ffs/ffs_alloc.c:184 #13 0xffffffff80635b49 in ffs_balloc_ufs2 (vp=0xfffffe006475cc30, startoffset=Variable "startoffset" is not available. ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:647 #14 0xffffffff8065f1e9 in ffs_close_ea (vp=0xfffffe006475cc30, commit=Variable "commit" is not available. ) at /usr/src/sys/ufs/ffs/ffs_vnops.c:1076 #15 0xffffffff8065f7d7 in ffs_setextattr (ap=0xffffff809097e850) at /usr/src/sys/ufs/ffs/ffs_vnops.c:1749 #16 0xffffffff806fd349 in VOP_SETEXTATTR_APV (vop=0xffffffff80a3d900, a=0xffffff809097e850) at vnode_if.c:3294 #17 0xffffffff804ca399 in extattr_set_vp (vp=0xfffffe006475cc30, attrnamespace=2, attrname=0xffffff809097e9d0 "md5", data=Variable "data" is not available. ) at vnode_if.h:1480 #18 0xffffffff804ca6c3 in sys_extattr_set_file (td=0xfffffe006d2bb920, uap=0xffffff809097ebb0) at /usr/src/sys/kern/vfs_extattr.c:276 #19 0xffffffff806b3610 in amd64_syscall (td=0xfffffe006d2bb920, traced=0) at subr_syscall.c:135 -- wbr, pluknet From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 12:11:11 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 E1E23106566B for ; Mon, 9 Apr 2012 12:11:11 +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 587AF8FC12 for ; Mon, 9 Apr 2012 12:11:11 +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 q39CB4KC030992; Mon, 9 Apr 2012 15:11:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q39CB385049609; Mon, 9 Apr 2012 15:11:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q39CB3G9049608; Mon, 9 Apr 2012 15:11:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Apr 2012 15:11:03 +0300 From: Konstantin Belousov To: Sergey Kandaurov Message-ID: <20120409121103.GL2358@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TP7FfcN1qgl8s+1K" Content-Disposition: inline In-Reply-To: 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: [patch] ufs extattr panic w/ quota under DIAGNOSTIC 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, 09 Apr 2012 12:11:12 -0000 --TP7FfcN1qgl8s+1K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2012 at 03:58:50PM +0400, Sergey Kandaurov wrote: > Hi. >=20 > This is a patch to fix ufs extattr panic seen when trying to set extended > attributes on a file system with quotas enabled and options DIAGNOSTIC. >=20 > # setextattr system md5 `md5 -q /boot/kernel/kernel` /boot/kernel/kernel >=20 > The problem is that when getting at chkdquot() from UFS_BALLOC() > it is expected that the vnode to operate extattr on was "prepared" with > getinoquota(). This assertion is explicitly turned off for snapshots and > quota files by setting VV_SYSTEM vnode flag. >=20 > This is probably should be also done for extended attributes. >=20 > Index: sys/ufs/ffs/ffs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/ufs/ffs/ffs_vnops.c (revision 233936) > +++ sys/ufs/ffs/ffs_vnops.c (working copy) > @@ -1681,6 +1681,8 @@ vop_setextattr { > return (error); > } >=20 > + ap->a_vp->v_vflag |=3D VV_SYSTEM; > + > error =3D ffs_open_ea(ap->a_vp, ap->a_cred, ap->a_td); > if (error) > return (error); >=20 The patch turns off quota for any file that is accessed for setting extended attribute. Why not calling getinoquota(), as it is done for other VOPs modifying the inode ? >=20 > chkdquot: missing dquot > 0xfffffe00483744e0: tag ufs, type VREG > usecount 1, writecount 0, refcount 567 mountedhere 0 > flags () > v_object 0xfffffe004839bbc8 ref 0 pages 2260 > lock type ufs: EXCL by thread 0xfffffe004844a000 (pid 11419, > setextattr, tid 100136) >=20 >=20 > #9 0xffffffff804380f7 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:633 > #10 0xffffffff80666f94 in chkdquot (ip=3D0xfffffe00669749d8) > at /usr/src/sys/ufs/ufs/ufs_quota.c:479 > #11 0xffffffff8066765c in chkdq (ip=3D0xfffffe00669749d8, change=3D4, > cred=3D0xfffffe0071d0a800, flags=3D0) at /usr/src/sys/ufs/ufs/ufs_quo= ta.c:174 > #12 0xffffffff80632879 in ffs_alloc (ip=3D0xfffffe00669749d8, > lbn=3DVariable "lbn" is not available. > ) > at /usr/src/sys/ufs/ffs/ffs_alloc.c:184 > #13 0xffffffff80635b49 in ffs_balloc_ufs2 (vp=3D0xfffffe006475cc30, > startoffset=3DVariable "startoffset" is not available. > ) > at /usr/src/sys/ufs/ffs/ffs_balloc.c:647 > #14 0xffffffff8065f1e9 in ffs_close_ea (vp=3D0xfffffe006475cc30, > commit=3DVariable "commit" is not available. > ) > at /usr/src/sys/ufs/ffs/ffs_vnops.c:1076 > #15 0xffffffff8065f7d7 in ffs_setextattr (ap=3D0xffffff809097e850) > at /usr/src/sys/ufs/ffs/ffs_vnops.c:1749 > #16 0xffffffff806fd349 in VOP_SETEXTATTR_APV (vop=3D0xffffffff80a3d900, > a=3D0xffffff809097e850) at vnode_if.c:3294 > #17 0xffffffff804ca399 in extattr_set_vp (vp=3D0xfffffe006475cc30, > attrnamespace=3D2, attrname=3D0xffffff809097e9d0 "md5", data=3DVariab= le > "data" is not available. > ) > at vnode_if.h:1480 > #18 0xffffffff804ca6c3 in sys_extattr_set_file (td=3D0xfffffe006d2bb920, > uap=3D0xffffff809097ebb0) at /usr/src/sys/kern/vfs_extattr.c:276 > #19 0xffffffff806b3610 in amd64_syscall (td=3D0xfffffe006d2bb920, traced= =3D0) > at subr_syscall.c:135 >=20 > --=20 > wbr, > pluknet > _______________________________________________ > 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" --TP7FfcN1qgl8s+1K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+C0dcACgkQC3+MBN1Mb4iQgQCg7cKKbxOs8Y041I/1SAnwZHfN 458AoJtVQjY9yRkE6OAyd/9calUxMLJb =s2sV -----END PGP SIGNATURE----- --TP7FfcN1qgl8s+1K-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 12: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 86EEC106566B for ; Mon, 9 Apr 2012 12: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 707518FC08 for ; Mon, 9 Apr 2012 12: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 q39CKF8G011691 for ; Mon, 9 Apr 2012 12:20:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q39CKF0x011689; Mon, 9 Apr 2012 12:20:15 GMT (envelope-from gnats) Date: Mon, 9 Apr 2012 12:20:15 GMT Message-Id: <201204091220.q39CKF0x011689@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: ONGS-OZAWA Cc: Subject: Re: kern/161511: [unionfs] Filesystem deadlocks when using multiple unionfs mounts on top of single filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ONGS-OZAWA List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 12:20:15 -0000 The following reply was made to PR kern/161511; it has been noted by GNATS. From: ONGS-OZAWA To: bug-followup@FreeBSD.org, gcooper@ixsystems.com Cc: Subject: Re: kern/161511: [unionfs] Filesystem deadlocks when using multiple unionfs mounts on top of single filesystem Date: Mon, 09 Apr 2012 21:17:14 +0900 This is a multi-part message in MIME format. --------------080703070504010006020003 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Please try this new patch that solves a dead lock issue of unionfs. # cd /usr/src/ # patch -p3 < attached_file -- ONGS Inc. Ozawa WWW: http://www.ongs.co.jp/ --------------080703070504010006020003 Content-Type: text/plain; name="unionfs_20120409.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="unionfs_20120409.diff" ZGlmZiAtdXJCTiAvdXNyL3NyYy5vcmlnL3N5cy9mcy91bmlvbmZzL3VuaW9uX3N1YnIuYyAv dXNyL3NyYy9zeXMvZnMvdW5pb25mcy91bmlvbl9zdWJyLmMKLS0tIC91c3Ivc3JjLm9yaWcv c3lzL2ZzL3VuaW9uZnMvdW5pb25fc3Vici5jCTIwMTItMDQtMDggMTQ6MDE6MjMuMDAwMDAw MDAwICswOTAwCisrKyAvdXNyL3NyYy9zeXMvZnMvdW5pb25mcy91bmlvbl9zdWJyLmMJMjAx Mi0wNC0wOSAxMTozMjoyOS4wMDAwMDAwMDAgKzA5MDAKQEAgLTM1MCwxOSArMzUwLDIyIEBA CiAJdXZwID0gdW5wLT51bl91cHBlcnZwOwogCWR2cCA9IHVucC0+dW5fZHZwOwogCXVucC0+ dW5fbG93ZXJ2cCA9IHVucC0+dW5fdXBwZXJ2cCA9IE5VTExWUDsKLQogCXZwLT52X3ZubG9j ayA9ICYodnAtPnZfbG9jayk7CiAJdnAtPnZfZGF0YSA9IE5VTEw7Ci0JbG9ja21ncih2cC0+ dl92bmxvY2ssIExLX0VYQ0xVU0lWRSB8IExLX0lOVEVSTE9DSywgVklfTVRYKHZwKSk7CisJ dnAtPnZfb2JqZWN0ID0gTlVMTDsKKwlWSV9VTkxPQ0sodnApOworCiAJaWYgKGx2cCAhPSBO VUxMVlApCi0JCVZPUF9VTkxPQ0sobHZwLCAwKTsKKwkJVk9QX1VOTE9DSyhsdnAsIExLX1JF TEVBU0UpOwogCWlmICh1dnAgIT0gTlVMTFZQKQotCQlWT1BfVU5MT0NLKHV2cCwgMCk7Ci0J dnAtPnZfb2JqZWN0ID0gTlVMTDsKKwkJVk9QX1VOTE9DSyh1dnAsIExLX1JFTEVBU0UpOwog CiAJaWYgKGR2cCAhPSBOVUxMVlAgJiYgdW5wLT51bl9oYXNoLmxlX3ByZXYgIT0gTlVMTCkK IAkJdW5pb25mc19yZW1fY2FjaGVkX3Zub2RlKHVucCwgZHZwKTsKIAorCWlmIChsb2NrbWdy KHZwLT52X3ZubG9jaywgTEtfRVhDTFVTSVZFLCBWSV9NVFgodnApKSAhPSAwKQorCQlwYW5p YygidGhlIGxvY2sgZm9yIGRlbGV0aW9uIGlzIHVuYWNxdWlyYWJsZS4iKTsKKwogCWlmIChs dnAgIT0gTlVMTFZQKSB7CiAJCXZmc2xvY2tlZCA9IFZGU19MT0NLX0dJQU5UKGx2cC0+dl9t b3VudCk7CiAJCXZyZWxlKGx2cCk7CkBAIC01NTAsNyArNTUzLDcgQEAKIAkJY24tPmNuX2Zs YWdzIHw9IChjbnAtPmNuX2ZsYWdzICYgU0FWRVNUQVJUKTsKIAogCXZyZWYoZHZwKTsKLQlW T1BfVU5MT0NLKGR2cCwgMCk7CisJVk9QX1VOTE9DSyhkdnAsIExLX1JFTEVBU0UpOwogCiAJ aWYgKChlcnJvciA9IHJlbG9va3VwKGR2cCwgdnBwLCBjbikpKSB7CiAJCXVtYV96ZnJlZShu YW1laV96b25lLCBjbi0+Y25fcG5idWYpOwpAQCAtOTU3LDcgKzk2MCw3IEBACiAJKnZwcCA9 IHZwOwogCiB1bmlvbmZzX3ZuX2NyZWF0ZV9vbl91cHBlcl9mcmVlX291dDE6Ci0JVk9QX1VO TE9DSyh1ZHZwLCAwKTsKKwlWT1BfVU5MT0NLKHVkdnAsIExLX1JFTEVBU0UpOwogCiB1bmlv bmZzX3ZuX2NyZWF0ZV9vbl91cHBlcl9mcmVlX291dDI6CiAJaWYgKGNuLmNuX2ZsYWdzICYg SEFTQlVGKSB7CmRpZmYgLXVyQk4gL3Vzci9zcmMub3JpZy9zeXMvZnMvdW5pb25mcy91bmlv bl92ZnNvcHMuYyAvdXNyL3NyYy9zeXMvZnMvdW5pb25mcy91bmlvbl92ZnNvcHMuYwotLS0g L3Vzci9zcmMub3JpZy9zeXMvZnMvdW5pb25mcy91bmlvbl92ZnNvcHMuYwkyMDEyLTA0LTA4 IDE0OjAxOjIzLjAwMDAwMDAwMCArMDkwMAorKysgL3Vzci9zcmMvc3lzL2ZzL3VuaW9uZnMv dW5pb25fdmZzb3BzLmMJMjAxMi0wNC0wOSAxMTozMjoyOS4wMDAwMDAwMDAgKzA5MDAKQEAg LTE2NSw3ICsxNjUsNyBAQAogCQl1aWQgPSB2YS52YV91aWQ7CiAJCWdpZCA9IHZhLnZhX2dp ZDsKIAl9Ci0JVk9QX1VOTE9DSyhtcC0+bW50X3Zub2RlY292ZXJlZCwgMCk7CisJVk9QX1VO TE9DSyhtcC0+bW50X3Zub2RlY292ZXJlZCwgTEtfUkVMRUFTRSk7CiAJaWYgKGVycm9yKQog CQlyZXR1cm4gKGVycm9yKTsKIApAQCAtMjUwLDcgKzI1MCw3IEBACiAJICogU2F2ZSByZWZl cmVuY2UKIAkgKi8KIAlpZiAoYmVsb3cpIHsKLQkJVk9QX1VOTE9DSyh1cHBlcnJvb3R2cCwg MCk7CisJCVZPUF9VTkxPQ0sodXBwZXJyb290dnAsIExLX1JFTEVBU0UpOwogCQl2bl9sb2Nr KGxvd2Vycm9vdHZwLCBMS19FWENMVVNJVkUgfCBMS19SRVRSWSk7CiAJCXVtcC0+dW1fbG93 ZXJ2cCA9IHVwcGVycm9vdHZwOwogCQl1bXAtPnVtX3VwcGVydnAgPSBsb3dlcnJvb3R2cDsK QEAgLTI4MSw3ICsyODEsNyBAQAogCS8qCiAJICogVW5sb2NrIHRoZSBub2RlCiAJICovCi0J Vk9QX1VOTE9DSyh1bXAtPnVtX3VwcGVydnAsIDApOworCVZPUF9VTkxPQ0sodW1wLT51bV91 cHBlcnZwLCBMS19SRUxFQVNFKTsKIAogCS8qCiAJICogR2V0IHRoZSB1bmlvbmZzIHJvb3Qg dm5vZGUuCmRpZmYgLXVyQk4gL3Vzci9zcmMub3JpZy9zeXMvZnMvdW5pb25mcy91bmlvbl92 bm9wcy5jIC91c3Ivc3JjL3N5cy9mcy91bmlvbmZzL3VuaW9uX3Zub3BzLmMKLS0tIC91c3Iv c3JjLm9yaWcvc3lzL2ZzL3VuaW9uZnMvdW5pb25fdm5vcHMuYwkyMDEyLTA0LTA4IDE0OjAx OjIzLjAwMDAwMDAwMCArMDkwMAorKysgL3Vzci9zcmMvc3lzL2ZzL3VuaW9uZnMvdW5pb25f dm5vcHMuYwkyMDEyLTA0LTA5IDExOjMyOjI5LjAwMDAwMDAwMCArMDkwMApAQCAtNzUsMjEg Kzc1LDYgQEAKIAlLQVNTRVJUKCgodnApLT52X29wID09ICZ1bmlvbmZzX3Zub2Rlb3BzKSwg XAogCSAgICAoInVuaW9uZnM6IGl0IGlzIG5vdCB1bmlvbmZzLXZub2RlIikpCiAKLS8qIGxv Y2ttZ3IgbG9jayA8LT4gcmV2ZXJzZSB0YWJsZSAqLwotc3RydWN0IGxrX2xyX3RhYmxlIHsK LQlpbnQJbG9jazsKLQlpbnQJcmV2bG9jazsKLX07Ci0KLXN0YXRpYyBzdHJ1Y3QgbGtfbHJf dGFibGUgdW5fbGx0W10gPSB7Ci0Je0xLX1NIQVJFRCwgTEtfUkVMRUFTRX0sCi0Je0xLX0VY Q0xVU0lWRSwgTEtfUkVMRUFTRX0sCi0Je0xLX1VQR1JBREUsIExLX0RPV05HUkFERX0sCi0J e0xLX0RPV05HUkFERSwgTEtfVVBHUkFERX0sCi0JezAsIDB9Ci19OwotCi0KIHN0YXRpYyBp bnQKIHVuaW9uZnNfbG9va3VwKHN0cnVjdCB2b3BfY2FjaGVkbG9va3VwX2FyZ3MgKmFwKQog ewpAQCAtMTQxLDcgKzEyNiw3IEBACiAJCWlmICh1ZHZwICE9IE5VTExWUCkgewogCQkJZHRt cHZwID0gdWR2cDsKIAkJCWlmIChsZHZwICE9IE5VTExWUCkKLQkJCQlWT1BfVU5MT0NLKGxk dnAsIDApOworCQkJCVZPUF9VTkxPQ0sobGR2cCwgTEtfUkVMRUFTRSk7CiAJCX0KIAkJZWxz ZQogCQkJZHRtcHZwID0gbGR2cDsKQEAgLTE0OSw3ICsxMzQsNyBAQAogCQllcnJvciA9IFZP UF9MT09LVVAoZHRtcHZwLCAmdnAsIGNucCk7CiAKIAkJaWYgKGR0bXB2cCA9PSB1ZHZwICYm IGxkdnAgIT0gTlVMTFZQKSB7Ci0JCQlWT1BfVU5MT0NLKHVkdnAsIDApOworCQkJVk9QX1VO TE9DSyh1ZHZwLCBMS19SRUxFQVNFKTsKIAkJCXZuX2xvY2soZHZwLCBMS19FWENMVVNJVkUg fCBMS19SRVRSWSk7CiAJCX0KIApAQCAtMTYxLDEwICsxNDYsMTAgQEAKIAkJCSAqLwogCQkJ aWYgKG5hbWVpb3AgPT0gREVMRVRFICB8fCBuYW1laW9wID09IFJFTkFNRSB8fAogCQkJICAg IChjbnAtPmNuX2xrZmxhZ3MgJiBMS19UWVBFX01BU0spKQotCQkJCVZPUF9VTkxPQ0sodnAs IDApOworCQkJCVZPUF9VTkxPQ0sodnAsIExLX1JFTEVBU0UpOwogCQkJdnJlbGUodnApOwog Ci0JCQlWT1BfVU5MT0NLKGR2cCwgMCk7CisJCQlWT1BfVU5MT0NLKGR2cCwgTEtfUkVMRUFT RSk7CiAJCQkqKGFwLT5hX3ZwcCkgPSBkdW5wLT51bl9kdnA7CiAJCQl2cmVmKGR1bnAtPnVu X2R2cCk7CiAKQEAgLTIwMiw3ICsxODcsNyBAQAogCQkJfQogCQkJaWYgKG5hbWVpb3AgPT0g REVMRVRFIHx8IG5hbWVpb3AgPT0gUkVOQU1FIHx8CiAJCQkgICAgKGNucC0+Y25fbGtmbGFn cyAmIExLX1RZUEVfTUFTSykpCi0JCQkJVk9QX1VOTE9DSyh1dnAsIDApOworCQkJCVZPUF9V TkxPQ0sodXZwLCBMS19SRUxFQVNFKTsKIAkJfQogCiAJCS8qIGNoZWNrIHdoaXRlb3V0ICov CkBAIC0yNDYsNyArMjMxLDcgQEAKIAkJCQlyZXR1cm4gKGxlcnJvcik7CiAJCQl9CiAJCQlp ZiAoY25wLT5jbl9sa2ZsYWdzICYgTEtfVFlQRV9NQVNLKQotCQkJCVZPUF9VTkxPQ0sobHZw LCAwKTsKKwkJCQlWT1BfVU5MT0NLKGx2cCwgTEtfUkVMRUFTRSk7CiAJCX0KIAl9CiAKQEAg LTI4MSw3ICsyNjYsNyBAQAogCQkJZ290byB1bmlvbmZzX2xvb2t1cF9vdXQ7CiAKIAkJaWYg KExLX1NIQVJFRCA9PSAoY25wLT5jbl9sa2ZsYWdzICYgTEtfVFlQRV9NQVNLKSkKLQkJCVZP UF9VTkxPQ0sodnAsIDApOworCQkJVk9QX1VOTE9DSyh2cCwgTEtfUkVMRUFTRSk7CiAJCWlm IChMS19FWENMVVNJVkUgIT0gVk9QX0lTTE9DS0VEKHZwKSkgewogCQkJdm5fbG9jayh2cCwg TEtfRVhDTFVTSVZFIHwgTEtfUkVUUlkpOwogCQkJbG9ja2ZsYWcgPSAxOwpAQCAtMjg5LDcg KzI3NCw3IEBACiAJCWVycm9yID0gdW5pb25mc19ta3NoYWRvd2RpcihNT1VOVFRPVU5JT05G U01PVU5UKGR2cC0+dl9tb3VudCksCiAJCSAgICB1ZHZwLCBWVE9VTklPTkZTKHZwKSwgY25w LCB0ZCk7CiAJCWlmIChsb2NrZmxhZyAhPSAwKQotCQkJVk9QX1VOTE9DSyh2cCwgMCk7CisJ CQlWT1BfVU5MT0NLKHZwLCBMS19SRUxFQVNFKTsKIAkJaWYgKGVycm9yICE9IDApIHsKIAkJ CVVOSU9ORlNERUJVRygidW5pb25mc19sb29rdXA6IFVuYWJsZSB0byBjcmVhdGUgc2hhZG93 IGRpci4iKTsKIAkJCWlmICgoY25wLT5jbl9sa2ZsYWdzICYgTEtfVFlQRV9NQVNLKSA9PSBM S19FWENMVVNJVkUpCkBAIC0zODYsNyArMzcxLDcgQEAKIAkJaWYgKHZwLT52X3R5cGUgPT0g VlNPQ0spCiAJCQkqKGFwLT5hX3ZwcCkgPSB2cDsKIAkJZWxzZSB7Ci0JCQlWT1BfVU5MT0NL KHZwLCAwKTsKKwkJCVZPUF9VTkxPQ0sodnAsIExLX1JFTEVBU0UpOwogCQkJZXJyb3IgPSB1 bmlvbmZzX25vZGVnZXQoYXAtPmFfZHZwLT52X21vdW50LCB2cCwgTlVMTFZQLAogCQkJICAg IGFwLT5hX2R2cCwgYXAtPmFfdnBwLCBjbnAsIGN1cnRocmVhZCk7CiAJCQl2cmVsZSh2cCk7 CkBAIC00NjAsNyArNDQ1LDcgQEAKIAkJaWYgKHZwLT52X3R5cGUgPT0gVlNPQ0spCiAJCQkq KGFwLT5hX3ZwcCkgPSB2cDsKIAkJZWxzZSB7Ci0JCQlWT1BfVU5MT0NLKHZwLCAwKTsKKwkJ CVZPUF9VTkxPQ0sodnAsIExLX1JFTEVBU0UpOwogCQkJZXJyb3IgPSB1bmlvbmZzX25vZGVn ZXQoYXAtPmFfZHZwLT52X21vdW50LCB2cCwgTlVMTFZQLAogCQkJICAgIGFwLT5hX2R2cCwg YXAtPmFfdnBwLCBjbnAsIGN1cnRocmVhZCk7CiAJCQl2cmVsZSh2cCk7CkBAIC02MTksNyAr NjA0LDcgQEAKIAl1bmlvbmZzX3RyeXJlbV9ub2RlX3N0YXR1cyh1bnAsIHVuc3ApOwogCiAJ aWYgKGxvY2tlZCAhPSAwKQotCQlWT1BfVU5MT0NLKGFwLT5hX3ZwLCAwKTsKKwkJVk9QX1VO TE9DSyhhcC0+YV92cCwgTEtfUkVMRUFTRSk7CiAKIAlVTklPTkZTX0lOVEVSTkFMX0RFQlVH KCJ1bmlvbmZzX2Nsb3NlOiBsZWF2ZSAoJWQpXG4iLCBlcnJvcik7CiAKQEAgLTkxNCw3ICs4 OTksNyBAQAogCXVuaW9uZnNfZ2V0X25vZGVfc3RhdHVzKHVucCwgYXAtPmFfdGQsICZ1bnNw KTsKIAlvdnAgPSAodW5zcC0+dW5zX3VwcGVyX29wZW5jbnQgPyB1bnAtPnVuX3VwcGVydnAg OiB1bnAtPnVuX2xvd2VydnApOwogCXVuaW9uZnNfdHJ5cmVtX25vZGVfc3RhdHVzKHVucCwg dW5zcCk7Ci0JVk9QX1VOTE9DSyhhcC0+YV92cCwgMCk7CisJVk9QX1VOTE9DSyhhcC0+YV92 cCwgTEtfUkVMRUFTRSk7CiAKIAlpZiAob3ZwID09IE5VTExWUCkKIAkJcmV0dXJuIChFQkFE Rik7CkBAIC05NDEsNyArOTI2LDcgQEAKIAl1bmlvbmZzX2dldF9ub2RlX3N0YXR1cyh1bnAs IGFwLT5hX3RkLCAmdW5zcCk7CiAJb3ZwID0gKHVuc3AtPnVuc191cHBlcl9vcGVuY250ID8g dW5wLT51bl91cHBlcnZwIDogdW5wLT51bl9sb3dlcnZwKTsKIAl1bmlvbmZzX3RyeXJlbV9u b2RlX3N0YXR1cyh1bnAsIHVuc3ApOwotCVZPUF9VTkxPQ0soYXAtPmFfdnAsIDApOworCVZP UF9VTkxPQ0soYXAtPmFfdnAsIExLX1JFTEVBU0UpOwogCiAJaWYgKG92cCA9PSBOVUxMVlAp CiAJCXJldHVybiAoRUJBREYpOwpAQCAtMTAwMSw3ICs5ODYsNyBAQAogCQl1bXAgPSBOVUxM OwogCQl2cCA9IHV2cCA9IGx2cCA9IE5VTExWUDsKIAkJLyogc2VhcmNoIHZub2RlICovCi0J CVZPUF9VTkxPQ0soYXAtPmFfdnAsIDApOworCQlWT1BfVU5MT0NLKGFwLT5hX3ZwLCBMS19S RUxFQVNFKTsKIAkJZXJyb3IgPSB1bmlvbmZzX3JlbG9va3VwKHVkdnAsICZ2cCwgY25wLCAm Y24sIHRkLAogCQkgICAgY25wLT5jbl9uYW1lcHRyLCBzdHJsZW4oY25wLT5jbl9uYW1lcHRy KSwgREVMRVRFKTsKIAkJaWYgKGVycm9yICE9IDAgJiYgZXJyb3IgIT0gRU5PRU5UKSB7CkBA IC0xMjA0LDcgKzExODksNyBAQAogCQkJaWYgKChlcnJvciA9IHZuX2xvY2soZnZwLCBMS19F WENMVVNJVkUpKSAhPSAwKQogCQkJCWdvdG8gdW5pb25mc19yZW5hbWVfYWJvcnQ7CiAJCQll cnJvciA9IHVuaW9uZnNfY29weWZpbGUodW5wLCAxLCBmY25wLT5jbl9jcmVkLCB0ZCk7Ci0J CQlWT1BfVU5MT0NLKGZ2cCwgMCk7CisJCQlWT1BfVU5MT0NLKGZ2cCwgTEtfUkVMRUFTRSk7 CiAJCQlpZiAoZXJyb3IgIT0gMCkKIAkJCQlnb3RvIHVuaW9uZnNfcmVuYW1lX2Fib3J0Owog CQkJYnJlYWs7CkBAIC0xMjEyLDcgKzExOTcsNyBAQAogCQkJaWYgKChlcnJvciA9IHZuX2xv Y2soZnZwLCBMS19FWENMVVNJVkUpKSAhPSAwKQogCQkJCWdvdG8gdW5pb25mc19yZW5hbWVf YWJvcnQ7CiAJCQllcnJvciA9IHVuaW9uZnNfbWtzaGFkb3dkaXIodW1wLCByZmR2cCwgdW5w LCBmY25wLCB0ZCk7Ci0JCQlWT1BfVU5MT0NLKGZ2cCwgMCk7CisJCQlWT1BfVU5MT0NLKGZ2 cCwgTEtfUkVMRUFTRSk7CiAJCQlpZiAoZXJyb3IgIT0gMCkKIAkJCQlnb3RvIHVuaW9uZnNf cmVuYW1lX2Fib3J0OwogCQkJYnJlYWs7CkBAIC0xMjY5LDEzICsxMjU0LDEzIEBACiAJCWlm ICgoZXJyb3IgPSB2bl9sb2NrKGZkdnAsIExLX0VYQ0xVU0lWRSkpICE9IDApCiAJCQlnb3Rv IHVuaW9uZnNfcmVuYW1lX2Fib3J0OwogCQllcnJvciA9IHVuaW9uZnNfcmVsb29rdXBfZm9y X2RlbGV0ZShmZHZwLCBmY25wLCB0ZCk7Ci0JCVZPUF9VTkxPQ0soZmR2cCwgMCk7CisJCVZP UF9VTkxPQ0soZmR2cCwgTEtfUkVMRUFTRSk7CiAJCWlmIChlcnJvciAhPSAwKQogCQkJZ290 byB1bmlvbmZzX3JlbmFtZV9hYm9ydDsKIAogCQkvKiBMb2NrZSBvZiB0dnAgaXMgY2FuY2Vs ZWQgaW4gb3JkZXIgdG8gYXZvaWQgcmVjdXJzaXZlIGxvY2suICovCiAJCWlmICh0dnAgIT0g TlVMTFZQICYmIHR2cCAhPSB0ZHZwKQotCQkJVk9QX1VOTE9DSyh0dnAsIDApOworCQkJVk9Q X1VOTE9DSyh0dnAsIExLX1JFTEVBU0UpOwogCQllcnJvciA9IHVuaW9uZnNfcmVsb29rdXBf Zm9yX3JlbmFtZSh0ZHZwLCB0Y25wLCB0ZCk7CiAJCWlmICh0dnAgIT0gTlVMTFZQICYmIHR2 cCAhPSB0ZHZwKQogCQkJdm5fbG9jayh0dnAsIExLX0VYQ0xVU0lWRSB8IExLX1JFVFJZKTsK QEAgLTEyOTMsMTEgKzEyNzgsMTEgQEAKIAl9CiAKIAlpZiAobHRkdnAgIT0gTlVMTFZQKQot CQlWT1BfVU5MT0NLKGx0ZHZwLCAwKTsKKwkJVk9QX1VOTE9DSyhsdGR2cCwgTEtfUkVMRUFT RSk7CiAJaWYgKHRkdnAgIT0gcnRkdnApCiAJCXZyZWxlKHRkdnApOwogCWlmIChsdHZwICE9 IE5VTExWUCkKLQkJVk9QX1VOTE9DSyhsdHZwLCAwKTsKKwkJVk9QX1VOTE9DSyhsdHZwLCBM S19SRUxFQVNFKTsKIAlpZiAodHZwICE9IHJ0dnAgJiYgdHZwICE9IE5VTExWUCkgewogCQlp ZiAocnR2cCA9PSBOVUxMVlApCiAJCQl2cHV0KHR2cCk7CkBAIC0xMzcxLDcgKzEzNTYsNyBA QAogCQl9CiAKIAkJaWYgKChlcnJvciA9IFZPUF9NS0RJUih1ZHZwLCAmdXZwLCBjbnAsIGFw LT5hX3ZhcCkpID09IDApIHsKLQkJCVZPUF9VTkxPQ0sodXZwLCAwKTsKKwkJCVZPUF9VTkxP Q0sodXZwLCBMS19SRUxFQVNFKTsKIAkJCWNucC0+Y25fbGtmbGFncyA9IExLX0VYQ0xVU0lW RTsKIAkJCWVycm9yID0gdW5pb25mc19ub2RlZ2V0KGFwLT5hX2R2cC0+dl9tb3VudCwgdXZw LCBOVUxMVlAsCiAJCQkgICAgYXAtPmFfZHZwLCBhcC0+YV92cHAsIGNucCwgdGQpOwpAQCAt MTQ2Nyw3ICsxNDUyLDcgQEAKIAlpZiAodWR2cCAhPSBOVUxMVlApIHsKIAkJZXJyb3IgPSBW T1BfU1lNTElOSyh1ZHZwLCAmdXZwLCBjbnAsIGFwLT5hX3ZhcCwgYXAtPmFfdGFyZ2V0KTsK IAkJaWYgKGVycm9yID09IDApIHsKLQkJCVZPUF9VTkxPQ0sodXZwLCAwKTsKKwkJCVZPUF9V TkxPQ0sodXZwLCBMS19SRUxFQVNFKTsKIAkJCWNucC0+Y25fbGtmbGFncyA9IExLX0VYQ0xV U0lWRTsKIAkJCWVycm9yID0gdW5pb25mc19ub2RlZ2V0KGFwLT5hX2R2cC0+dl9tb3VudCwg dXZwLCBOVUxMVlAsCiAJCQkgICAgYXAtPmFfZHZwLCBhcC0+YV92cHAsIGNucCwgdGQpOwpA QCAtMTQ5MCw2ICsxNDc1LDcgQEAKIAlzdHJ1Y3QgdW5pb25mc19ub2RlICp1bnA7CiAJc3Ry dWN0IHVuaW9uZnNfbm9kZV9zdGF0dXMgKnVuc3A7CiAJc3RydWN0IHVpbyAgICAgKnVpbzsK KwlzdHJ1Y3Qgdm5vZGUgICAqdnA7CiAJc3RydWN0IHZub2RlICAgKnV2cDsKIAlzdHJ1Y3Qg dm5vZGUgICAqbHZwOwogCXN0cnVjdCB0aHJlYWQgICp0ZDsKQEAgLTE1MDUsNDEgKzE0OTEs NDkgQEAKIAllcnJvciA9IDA7CiAJZW9mZmxhZyA9IDA7CiAJbG9ja2VkID0gMDsKLQl1bnAg PSBWVE9VTklPTkZTKGFwLT5hX3ZwKTsKIAl1aW8gPSBhcC0+YV91aW87Ci0JdXZwID0gdW5w LT51bl91cHBlcnZwOwotCWx2cCA9IHVucC0+dW5fbG93ZXJ2cDsKKwl1dnAgPSBOVUxMVlA7 CisJbHZwID0gTlVMTFZQOwogCXRkID0gdWlvLT51aW9fdGQ7CiAJbmNvb2tpZXNfYmsgPSAw OwogCWNvb2tpZXNfYmsgPSBOVUxMOwogCi0JaWYgKGFwLT5hX3ZwLT52X3R5cGUgIT0gVkRJ UikKKwl2cCA9IGFwLT5hX3ZwOworCWlmICh2cC0+dl90eXBlICE9IFZESVIpCiAJCXJldHVy biAoRU5PVERJUik7CiAKLQkvKiBjaGVjayBvcGFxdWUgKi8KLQlpZiAodXZwICE9IE5VTExW UCAmJiBsdnAgIT0gTlVMTFZQKSB7Ci0JCWlmICgoZXJyb3IgPSBWT1BfR0VUQVRUUih1dnAs ICZ2YSwgYXAtPmFfY3JlZCkpICE9IDApCi0JCQlnb3RvIHVuaW9uZnNfcmVhZGRpcl9leGl0 OwotCQlpZiAodmEudmFfZmxhZ3MgJiBPUEFRVUUpCi0JCQlsdnAgPSBOVUxMVlA7Ci0JfQot CiAJLyogY2hlY2sgdGhlIG9wZW4gY291bnQuIHVuaW9uZnMgbmVlZHMgdG8gb3BlbiBiZWZv cmUgcmVhZGRpci4gKi8KLQlpZiAoVk9QX0lTTE9DS0VEKGFwLT5hX3ZwKSAhPSBMS19FWENM VVNJVkUpIHsKLQkJdm5fbG9jayhhcC0+YV92cCwgTEtfVVBHUkFERSB8IExLX1JFVFJZKTsK KwlpZiAoVk9QX0lTTE9DS0VEKHZwKSAhPSBMS19FWENMVVNJVkUpIHsKKwkJaWYgKHZuX2xv Y2sodnAsIExLX1VQR1JBREUpICE9IDApCisJCQl2bl9sb2NrKHZwLCBMS19FWENMVVNJVkUg fCBMS19SRVRSWSk7CiAJCWxvY2tlZCA9IDE7CiAJfQotCXVuaW9uZnNfZ2V0X25vZGVfc3Rh dHVzKHVucCwgdGQsICZ1bnNwKTsKLQlpZiAoKHV2cCAhPSBOVUxMVlAgJiYgdW5zcC0+dW5z X3VwcGVyX29wZW5jbnQgPD0gMCkgfHwKLQkgICAgKGx2cCAhPSBOVUxMVlAgJiYgdW5zcC0+ dW5zX2xvd2VyX29wZW5jbnQgPD0gMCkpIHsKLQkJdW5pb25mc190cnlyZW1fbm9kZV9zdGF0 dXModW5wLCB1bnNwKTsKKwl1bnAgPSBWVE9VTklPTkZTKHZwKTsKKwlpZiAodW5wID09IE5V TEwpCiAJCWVycm9yID0gRUJBREY7CisJZWxzZSB7CisJCXV2cCA9IHVucC0+dW5fdXBwZXJ2 cDsKKwkJbHZwID0gdW5wLT51bl9sb3dlcnZwOworCQl1bmlvbmZzX2dldF9ub2RlX3N0YXR1 cyh1bnAsIHRkLCAmdW5zcCk7CisJCWlmICgodXZwICE9IE5VTExWUCAmJiB1bnNwLT51bnNf dXBwZXJfb3BlbmNudCA8PSAwKSB8fAorCQkJKGx2cCAhPSBOVUxMVlAgJiYgdW5zcC0+dW5z X2xvd2VyX29wZW5jbnQgPD0gMCkpIHsKKwkJCXVuaW9uZnNfdHJ5cmVtX25vZGVfc3RhdHVz KHVucCwgdW5zcCk7CisJCQllcnJvciA9IEVCQURGOworCQl9CiAJfQotCWlmIChsb2NrZWQg PT0gMSkKLQkJdm5fbG9jayhhcC0+YV92cCwgTEtfRE9XTkdSQURFIHwgTEtfUkVUUlkpOwor CWlmIChsb2NrZWQpCisJCXZuX2xvY2sodnAsIExLX0RPV05HUkFERSB8IExLX1JFVFJZKTsK IAlpZiAoZXJyb3IgIT0gMCkKIAkJZ290byB1bmlvbmZzX3JlYWRkaXJfZXhpdDsKIAorCS8q IGNoZWNrIG9wYXF1ZSAqLworCWlmICh1dnAgIT0gTlVMTFZQICYmIGx2cCAhPSBOVUxMVlAp IHsKKwkJaWYgKChlcnJvciA9IFZPUF9HRVRBVFRSKHV2cCwgJnZhLCBhcC0+YV9jcmVkKSkg IT0gMCkKKwkJCWdvdG8gdW5pb25mc19yZWFkZGlyX2V4aXQ7CisJCWlmICh2YS52YV9mbGFn cyAmIE9QQVFVRSkKKwkJCWx2cCA9IE5VTExWUDsKKwl9CisKIAkvKiB1cHBlciBvbmx5ICov CiAJaWYgKHV2cCAhPSBOVUxMVlAgJiYgbHZwID09IE5VTExWUCkgewogCQllcnJvciA9IFZP UF9SRUFERElSKHV2cCwgdWlvLCBhcC0+YV9jcmVkLCBhcC0+YV9lb2ZmbGFnLApAQCAtMTc0 MywxOCArMTczNyw2NiBAQAogfQogCiBzdGF0aWMgaW50Ci11bmlvbmZzX2dldF9sbHRfcmV2 bG9jayhpbnQgZmxhZ3MpCit1bmlvbmZzX2lzbG9ja2VkKHN0cnVjdCB2b3BfaXNsb2NrZWRf YXJncyAqYXApCiB7Ci0JaW50IGNvdW50OworCXN0cnVjdCB1bmlvbmZzX25vZGUgKnVucDsK IAotCWZsYWdzICY9IExLX1RZUEVfTUFTSzsKLQlmb3IgKGNvdW50ID0gMDsgdW5fbGx0W2Nv dW50XS5sb2NrICE9IDA7IGNvdW50KyspIHsKLQkJaWYgKGZsYWdzID09IHVuX2xsdFtjb3Vu dF0ubG9jaykgewotCQkJcmV0dXJuIHVuX2xsdFtjb3VudF0ucmV2bG9jazsKLQkJfQorCUtB U1NFUlRfVU5JT05GU19WTk9ERShhcC0+YV92cCk7CisKKwl1bnAgPSBWVE9VTklPTkZTKGFw LT5hX3ZwKTsKKwlpZiAodW5wID09IE5VTEwpCisJCXJldHVybiAodm9wX3N0ZGlzbG9ja2Vk KGFwKSk7CisKKwlpZiAodW5wLT51bl91cHBlcnZwICE9IE5VTExWUCkKKwkJcmV0dXJuIChW T1BfSVNMT0NLRUQodW5wLT51bl91cHBlcnZwKSk7CisJaWYgKHVucC0+dW5fbG93ZXJ2cCAh PSBOVUxMVlApCisJCXJldHVybiAoVk9QX0lTTE9DS0VEKHVucC0+dW5fbG93ZXJ2cCkpOwor CXJldHVybiAodm9wX3N0ZGlzbG9ja2VkKGFwKSk7Cit9CisKK3N0YXRpYyBpbnQKK3VuaW9u ZnNfZ2V0X2xsdF9yZXZsb2NrKHN0cnVjdCB2bm9kZSAqdnAsIGludCBmbGFncykKK3sKKwlp bnQgcmV2bG9jazsKKworCXJldmxvY2sgPSAwOworCisJc3dpdGNoIChmbGFncyAmIExLX1RZ UEVfTUFTSykgeworCWNhc2UgTEtfU0hBUkVEOgorCQlpZiAoVk9QX0lTTE9DS0VEKHZwKSA9 PSBMS19FWENMVVNJVkUpCisJCQlyZXZsb2NrID0gTEtfVVBHUkFERTsKKwkJZWxzZQorCQkJ cmV2bG9jayA9IExLX1JFTEVBU0U7CisJCWJyZWFrOworCWNhc2UgTEtfRVhDTFVTSVZFOgor CWNhc2UgTEtfVVBHUkFERToKKwkJcmV2bG9jayA9IExLX1JFTEVBU0U7CisJCWJyZWFrOwor CWNhc2UgTEtfRE9XTkdSQURFOgorCQlyZXZsb2NrID0gTEtfVVBHUkFERTsKKwkJYnJlYWs7 CisJZGVmYXVsdDoKKwkJYnJlYWs7CiAJfQogCi0JcmV0dXJuIDA7CisJcmV0dXJuIChyZXZs b2NrKTsKK30KKworLyoKKyAqIFRoZSBzdGF0ZSBvZiBhbiBhY3F1aXJlZCBsb2NrIGlzIGFk anVzdGVkIHNpbWlsYXJseSB0bworICogdGhlIHRpbWUgb2YgZXJyb3IgZ2VuZXJhdGluZy4g CisgKiBmbGFnczogTEtfUkVMRUFTRSBvciBMS19VUEdSQURFCisgKi8KK3N0YXRpYyB2b2lk Cit1bmlvbmZzX3JldmxvY2soc3RydWN0IHZub2RlICp2cCwgaW50IGZsYWdzKQoreworCWlm IChmbGFncyAmIExLX1JFTEVBU0UpCisJCVZPUF9VTkxPQ0sodnAsIGZsYWdzKTsKKwllbHNl IHsKKwkJLyogVVBHUkFERSAqLworCQlpZiAodm5fbG9jayh2cCwgZmxhZ3MpICE9IDApCisJ CQl2bl9sb2NrKHZwLCBMS19FWENMVVNJVkUgfCBMS19SRVRSWSk7CisJfQogfQogCiBzdGF0 aWMgaW50CkBAIC0xNzYzLDYgKzE4MDUsNyBAQAogCWludAkJZXJyb3I7CiAJaW50CQlmbGFn czsKIAlpbnQJCXJldmxvY2s7CisJaW50CQlpbnRlcmxvY2s7CiAJaW50CQl1aG9sZDsKIAlz dHJ1Y3QgbW91bnQgICAqbXA7CiAJc3RydWN0IHVuaW9uZnNfbW91bnQgKnVtcDsKQEAgLTE3 NzQsMTUgKzE4MTcsMTMgQEAKIAlLQVNTRVJUX1VOSU9ORlNfVk5PREUoYXAtPmFfdnApOwog CiAJZXJyb3IgPSAwOworCWludGVybG9jayA9IDE7CiAJdWhvbGQgPSAwOwogCWZsYWdzID0g YXAtPmFfZmxhZ3M7CiAJdnAgPSBhcC0+YV92cDsKIAogCWlmIChMS19SRUxFQVNFID09IChm bGFncyAmIExLX1RZUEVfTUFTSykgfHwgIShmbGFncyAmIExLX1RZUEVfTUFTSykpCi0JCXJl dHVybiAoVk9QX1VOTE9DSyh2cCwgZmxhZ3MpKTsKLQotCWlmICgocmV2bG9jayA9IHVuaW9u ZnNfZ2V0X2xsdF9yZXZsb2NrKGZsYWdzKSkgPT0gMCkKLQkJcGFuaWMoInVua25vd24gbG9j ayB0eXBlOiAweCV4IiwgZmxhZ3MgJiBMS19UWVBFX01BU0spOworCQlyZXR1cm4gKFZPUF9V TkxPQ0sodnAsIGZsYWdzIHwgTEtfUkVMRUFTRSkpOwogCiAJaWYgKChmbGFncyAmIExLX0lO VEVSTE9DSykgPT0gMCkKIAkJVklfTE9DSyh2cCk7CkBAIC0xNzk4LDYgKzE4MzksOSBAQAog CWx2cCA9IHVucC0+dW5fbG93ZXJ2cDsKIAl1dnAgPSB1bnAtPnVuX3VwcGVydnA7CiAKKwlp ZiAoKHJldmxvY2sgPSB1bmlvbmZzX2dldF9sbHRfcmV2bG9jayh2cCwgZmxhZ3MpKSA9PSAw KQorCQlwYW5pYygidW5rbm93biBsb2NrIHR5cGU6IDB4JXgiLCBmbGFncyAmIExLX1RZUEVf TUFTSyk7CisKIAlpZiAoKG1wLT5tbnRfa2Vybl9mbGFnICYgTU5US19NUFNBRkUpICE9IDAg JiYKIAkgICAgKHZwLT52X2lmbGFnICYgVklfT1dFSU5BQ1QpICE9IDApCiAJCWZsYWdzIHw9 IExLX05PV0FJVDsKQEAgLTE4MTEsNiArMTg1NSwyMyBAQAogCQlmbGFncyB8PSBMS19DQU5S RUNVUlNFOwogCiAJaWYgKGx2cCAhPSBOVUxMVlApIHsKKwkJaWYgKHV2cCAhPSBOVUxMVlAg JiYgZmxhZ3MgJiBMS19VUEdSQURFKSB7CisJCQkvKiBTaGFyZSBMb2NrIGlzIG9uY2UgcmVs ZWFzZWQgYW5kIGEgZGVhZGxvY2sgaXMgYXZvaWRlZC4gICovCisJCQlWSV9MT0NLX0ZMQUdT KHV2cCwgTVRYX0RVUE9LKTsKKwkJCXZob2xkbCh1dnApOworCQkJdWhvbGQgPSAxOworCQkJ VklfVU5MT0NLKHZwKTsKKwkJCVZPUF9VTkxPQ0sodXZwLCBMS19SRUxFQVNFIHwgTEtfSU5U RVJMT0NLKTsKKwkJCVZJX0xPQ0sodnApOworCQkJdW5wID0gVlRPVU5JT05GUyh2cCk7CisJ CQlpZiAodW5wID09IE5VTEwpIHsKKwkJCQkvKiB2bm9kZSBpcyByZWxlYXNlZC4gKi8KKwkJ CQlWSV9VTkxPQ0sodnApOworCQkJCVZPUF9VTkxPQ0sobHZwLCBMS19SRUxFQVNFKTsKKwkJ CQl2ZHJvcCh1dnApOworCQkJCXJldHVybiAoRUJVU1kpOworCQkJfQorCQl9CiAJCVZJX0xP Q0tfRkxBR1MobHZwLCBNVFhfRFVQT0spOwogCQlmbGFncyB8PSBMS19JTlRFUkxPQ0s7CiAJ CXZob2xkbChsdnApOwpAQCAtMTgyMywxOSArMTg4NCwyOCBAQAogCQlWSV9MT0NLKHZwKTsK IAkJdW5wID0gVlRPVU5JT05GUyh2cCk7CiAJCWlmICh1bnAgPT0gTlVMTCkgeworCQkJLyog dm5vZGUgaXMgcmVsZWFzZWQuICovCiAJCQlWSV9VTkxPQ0sodnApOwogCQkJaWYgKGVycm9y ID09IDApCi0JCQkJVk9QX1VOTE9DSyhsdnAsIDApOworCQkJCVZPUF9VTkxPQ0sobHZwLCBM S19SRUxFQVNFKTsKIAkJCXZkcm9wKGx2cCk7CisJCQlpZiAodWhvbGQgIT0gMCkKKwkJCQl2 ZHJvcCh1dnApOwogCQkJcmV0dXJuICh2b3Bfc3RkbG9jayhhcCkpOwogCQl9CiAJfQogCiAJ aWYgKGVycm9yID09IDAgJiYgdXZwICE9IE5VTExWUCkgeworCQlpZiAodWhvbGQgJiYgZmxh Z3MgJiBMS19VUEdSQURFKSB7CisJCQlmbGFncyAmPSB+TEtfVFlQRV9NQVNLOworCQkJZmxh Z3MgfD0gTEtfRVhDTFVTSVZFOworCQl9CiAJCVZJX0xPQ0tfRkxBR1ModXZwLCBNVFhfRFVQ T0spOwogCQlmbGFncyB8PSBMS19JTlRFUkxPQ0s7Ci0JCXZob2xkbCh1dnApOwotCQl1aG9s ZCA9IDE7CisJCWlmICh1aG9sZCA9PSAwKSB7CisJCQl2aG9sZGwodXZwKTsKKwkJCXVob2xk ID0gMTsKKwkJfQogCiAJCVZJX1VOTE9DSyh2cCk7CiAJCWFwLT5hX2ZsYWdzICY9IH5MS19J TlRFUkxPQ0s7CkBAIC0xODQ1LDMwICsxOTE1LDI3IEBACiAJCVZJX0xPQ0sodnApOwogCQl1 bnAgPSBWVE9VTklPTkZTKHZwKTsKIAkJaWYgKHVucCA9PSBOVUxMKSB7CisJCQkvKiB2bm9k ZSBpcyByZWxlYXNlZC4gKi8KIAkJCVZJX1VOTE9DSyh2cCk7Ci0JCQlpZiAoZXJyb3IgPT0g MCkgewotCQkJCVZPUF9VTkxPQ0sodXZwLCAwKTsKLQkJCQlpZiAobHZwICE9IE5VTExWUCkK LQkJCQkJVk9QX1VOTE9DSyhsdnAsIDApOwotCQkJfQotCQkJaWYgKGx2cCAhPSBOVUxMVlAp Ci0JCQkJdmRyb3AobHZwKTsKKwkJCWlmIChlcnJvciA9PSAwKQorCQkJCVZPUF9VTkxPQ0so dXZwLCBMS19SRUxFQVNFKTsKIAkJCXZkcm9wKHV2cCk7CisJCQlpZiAobHZwICE9IE5VTExW UCkgeworCQkJCVZPUF9VTkxPQ0sobHZwLCBMS19SRUxFQVNFKTsKKwkJCQl2ZHJvcChsdnAp OworCQkJfQogCQkJcmV0dXJuICh2b3Bfc3RkbG9jayhhcCkpOwogCQl9Ci0KIAkJaWYgKGVy cm9yICE9IDAgJiYgbHZwICE9IE5VTExWUCkgeworCQkJLyogcm9sbGJhY2sgKi8KIAkJCVZJ X1VOTE9DSyh2cCk7Ci0JCQlpZiAoKHJldmxvY2sgJiBMS19UWVBFX01BU0spID09IExLX1JF TEVBU0UpCi0JCQkJVk9QX1VOTE9DSyhsdnAsIHJldmxvY2spOwotCQkJZWxzZQotCQkJCXZu X2xvY2sobHZwLCByZXZsb2NrIHwgTEtfUkVUUlkpOwotCQkJZ290byB1bmlvbmZzX2xvY2tf YWJvcnQ7CisJCQl1bmlvbmZzX3JldmxvY2sobHZwLCByZXZsb2NrKTsKKwkJCWludGVybG9j ayA9IDA7CiAJCX0KIAl9CiAKLQlWSV9VTkxPQ0sodnApOwotdW5pb25mc19sb2NrX2Fib3J0 OgorCWlmIChpbnRlcmxvY2spCisJCVZJX1VOTE9DSyh2cCk7CiAJaWYgKGx2cCAhPSBOVUxM VlApCiAJCXZkcm9wKGx2cCk7CiAJaWYgKHVob2xkICE9IDApCkBAIC0yMDEzLDcgKzIwODAs NyBAQAogCQkJdW5pb25mc190cnlyZW1fbm9kZV9zdGF0dXModW5wLCB1bnNwKTsKIAl9CiAK LQlWT1BfVU5MT0NLKHZwLCAwKTsKKwlWT1BfVU5MT0NLKHZwLCBMS19SRUxFQVNFKTsKIAog CWVycm9yID0gVk9QX0FEVkxPQ0sodXZwLCBhcC0+YV9pZCwgYXAtPmFfb3AsIGFwLT5hX2Zs LCBhcC0+YV9mbGFncyk7CiAKQEAgLTIwMjIsNyArMjA4OSw3IEBACiAJcmV0dXJuIGVycm9y OwogCiB1bmlvbmZzX2FkdmxvY2tfYWJvcnQ6Ci0JVk9QX1VOTE9DSyh2cCwgMCk7CisJVk9Q X1VOTE9DSyh2cCwgTEtfUkVMRUFTRSk7CiAKIAlVTklPTkZTX0lOVEVSTkFMX0RFQlVHKCJ1 bmlvbmZzX2FkdmxvY2s6IGxlYXZlICglZClcbiIsIGVycm9yKTsKIApAQCAtMjE1MCw3ICsy MjE3LDggQEAKIAllcnJvciA9IFZPUF9PUEVORVhUQVRUUih0dnAsIGFwLT5hX2NyZWQsIGFw LT5hX3RkKTsKIAogCWlmIChlcnJvciA9PSAwKSB7Ci0JCXZuX2xvY2sodnAsIExLX1VQR1JB REUgfCBMS19SRVRSWSk7CisJCWlmICh2bl9sb2NrKHZwLCBMS19VUEdSQURFKSAhPSAwKQor CQkJdm5fbG9jayh2cCwgTEtfRVhDTFVTSVZFIHwgTEtfUkVUUlkpOwogCQlpZiAodHZwID09 IHVucC0+dW5fdXBwZXJ2cCkKIAkJCXVucC0+dW5fZmxhZyB8PSBVTklPTkZTX09QRU5FWFRV OwogCQllbHNlCkBAIC0yMTg2LDcgKzIyNTQsOCBAQAogCWVycm9yID0gVk9QX0NMT1NFRVhU QVRUUih0dnAsIGFwLT5hX2NvbW1pdCwgYXAtPmFfY3JlZCwgYXAtPmFfdGQpOwogCiAJaWYg KGVycm9yID09IDApIHsKLQkJdm5fbG9jayh2cCwgTEtfVVBHUkFERSB8IExLX1JFVFJZKTsK KwkJaWYgKHZuX2xvY2sodnAsIExLX1VQR1JBREUpICE9IDApCisJCQl2bl9sb2NrKHZwLCBM S19FWENMVVNJVkUgfCBMS19SRVRSWSk7CiAJCWlmICh0dnAgPT0gdW5wLT51bl91cHBlcnZw KQogCQkJdW5wLT51bl9mbGFnICY9IH5VTklPTkZTX09QRU5FWFRVOwogCQllbHNlCkBAIC0y NDM1LDYgKzI1MDQsNyBAQAogCS52b3BfZ2V0ZXh0YXR0ciA9CXVuaW9uZnNfZ2V0ZXh0YXR0 ciwKIAkudm9wX2dldHdyaXRlbW91bnQgPQl1bmlvbmZzX2dldHdyaXRlbW91bnQsCiAJLnZv cF9pbmFjdGl2ZSA9CQl1bmlvbmZzX2luYWN0aXZlLAorCS52b3BfaXNsb2NrZWQgPQkJdW5p b25mc19pc2xvY2tlZCwKIAkudm9wX2lvY3RsID0JCXVuaW9uZnNfaW9jdGwsCiAJLnZvcF9s aW5rID0JCXVuaW9uZnNfbGluaywKIAkudm9wX2xpc3RleHRhdHRyID0JdW5pb25mc19saXN0 ZXh0YXR0ciwK --------------080703070504010006020003-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 14:14:31 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 79E16106564A; Mon, 9 Apr 2012 14:14:31 +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 4CF7E8FC08; Mon, 9 Apr 2012 14:14:31 +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 q39EEVtq021426; Mon, 9 Apr 2012 14:14:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q39EEVdk021422; Mon, 9 Apr 2012 14:14:31 GMT (envelope-from linimon) Date: Mon, 9 Apr 2012 14:14:31 GMT Message-Id: <201204091414.q39EEVdk021422@freefall.freebsd.org> To: linimon@FreeBSD.org, mohans@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/118318: [nfs] NFS server hangs under special circumstances 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, 09 Apr 2012 14:14:31 -0000 Synopsis: [nfs] NFS server hangs under special circumstances Responsible-Changed-From-To: mohans->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 9 14:13:30 UTC 2012 Responsible-Changed-Why: Reassign. mohans never explicitly requested this PR, and now mail to him is bouncing. To submitter: is this aging PR still valid? http://www.freebsd.org/cgi/query-pr.cgi?pr=118318 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 16:04: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 8E7E41065674 for ; Mon, 9 Apr 2012 16:04:15 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 43E3E8FC0A for ; Mon, 9 Apr 2012 16:04:15 +0000 (UTC) Received: (qmail 70421 invoked by uid 99); 9 Apr 2012 16:04:09 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Apr 2012 16:04:09 +0000 Received: from localhost (HELO lp-shahaf.local) (127.0.0.1) (smtp-auth username danielsh, mechanism login) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Apr 2012 16:04:09 +0000 Date: Mon, 9 Apr 2012 19:04:03 +0300 From: Daniel Shahaf To: Jaakko Heinonen Message-ID: <20120409160403.GF5515@lp-shahaf.local> References: <201204010740.q317eHiP076471@freefall.freebsd.org> <20120402230303.GJ4711@daniel3.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120402230303.GJ4711@daniel3.local> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-fs@FreeBSD.org, infrastructure-private@apache.org Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device 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, 09 Apr 2012 16:04:15 -0000 Daniel Shahaf wrote on Tue, Apr 03, 2012 at 02:03:03 +0300: > Jaakko Heinonen wrote on Sun, Apr 01, 2012 at 07:40:17 +0000: > > The following reply was made to PR kern/155411; it has been noted by GNATS. > > > > From: Jaakko Heinonen > > To: pgollucci@FreeBSD.org > > Cc: bug-followup@FreeBSD.org, delphij@FreeBSD.org > > Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : > > No space left on device > > Date: Sun, 1 Apr 2012 10:37:28 +0300 > > > > It seems that r227802 hasn't been MFCd to stable/9. Can you test with > > the head version or apply r227802 to stable/9? > > > > I've just applied r227802 to one of our 9.0-RELEASE boxes which ran into > the issue. If there is any problem I'll report back. > > FreeBSD aurora.apache.org 9.0-RELEASE+r227802 FreeBSD 9.0-RELEASE+r227802 #1: Mon Apr 2 21:52:02 UTC 2012 root@aurora.apache.org:/usr/obj/usr/src/sys/ASF amd64 > Looks good so far: aurora,2:~% df -h /tmp Filesystem Size Used Avail Capacity Mounted on tmpfs 7.6G 72k 7.6G 0% /tmp > > -- > > Jaakko > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 16:12:23 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 B7AEC1065674; Mon, 9 Apr 2012 16:12:23 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8B12F8FC0C; Mon, 9 Apr 2012 16:12:23 +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 q39GCN8M030138; Mon, 9 Apr 2012 16:12:23 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q39GCNTQ030134; Mon, 9 Apr 2012 16:12:23 GMT (envelope-from jh) Date: Mon, 9 Apr 2012 16:12:23 GMT Message-Id: <201204091612.q39GCNTQ030134@freefall.freebsd.org> To: pgollucci@FreeBSD.org, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device 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, 09 Apr 2012 16:12:23 -0000 Synopsis: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device State-Changed-From-To: open->patched State-Changed-By: jh State-Changed-When: Mon Apr 9 16:11:15 UTC 2012 State-Changed-Why: Fixed in head (r227802) and stable/9 (r233769). http://www.freebsd.org/cgi/query-pr.cgi?pr=155411 From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 12:28:09 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F2E6106566C for ; Tue, 10 Apr 2012 12:28:09 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by mx1.freebsd.org (Postfix) with SMTP id B8E438FC0C for ; Tue, 10 Apr 2012 12:28:08 +0000 (UTC) Received: from [98.139.91.65] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 12:28:08 -0000 Received: from [98.139.44.64] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 12:27:08 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 12:27:08 -0000 X-Yahoo-Newman-Id: 555953.12903.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 28850 invoked from network); 10 Apr 2012 12:27:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334060828; bh=ckZ3csC0apNE2KZfxSghD0m+3nGBbW3fgULRNRJr2qQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=ATHZiqgr1xRf8f6pG+FMvuKFI2C1v2VOi3SiWvpnRwUaVhwpdCybkR5IukRaRfjxjX2bsqD0aIDP04vMlZV0NoSJHwBSmJwD9yuFXNanv2ant3/7wSMUia+BmimtUmeIj0hTRGndXu2YTn4lUBCwqOVatb5bghYkHQ+AMHXA0rM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ew_8sgwVM1kyP7aYFPOAV7fE1jS4Z25gEbrwWWvYZLKc6PC Z3RhuvCyICn66I.C6ldaFt2nxROvJ5u5RPrlLfScGbT4ma07umTDgUXen9us rJE2hmz2HALkixcXdMK1zUFF4kZ5NRc89vn_Dwrdwyow2PDap591GqnrioDi 66JITerAEoLooF8DX80aNnNzaG8xerAsTIQouVfeO9uklrM4u7.nv5fvrY_O Bh8F7f8bQovP.IT0UIGFJeC4OzHecTtlFF2PSQvuz8jrwQe.2_693lFWiMRE PvXjdaO9qEjBW3WUUHKb2RAGGOMFi9AsE5Lie228ERJ6DOjs38eXxtq8lXUS _u3WQGvHkWAiCQRKR9Mmyr5JamWWGnmNGe.XxcsLv44RGF38dd1nbI0yUF5Y 6Q8cUh_I9sml8U6LN12f4WKphxoaZVTJV9dr1yawRPDDP5L3pkf.guE1qhgn q.2Rb61hcKn5Y5HTUSrR_yimYnb8GL9vYS6OPYegxMq23OVM33z0- X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- Received: from smtp.irbisnet.com (andriy@174.113.73.248 with login) by smtp108.rog.mail.gq1.yahoo.com with SMTP; 10 Apr 2012 05:27:07 -0700 PDT Received: from [192.168.0.9] (Andriy-Bakays-iPhone.local [192.168.0.9]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 705902F62C; Tue, 10 Apr 2012 08:27:06 -0400 (EDT) References: <4F69A3C1.7040305@omnilan.de> <20120321100905.GN5886@equilibrium.bsdes.net> <4F69B1B0.3040005@FreeBSD.org> In-Reply-To: <4F69B1B0.3040005@FreeBSD.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <44AFA6EF-D29A-4F50-B3F7-E543AEC81416@irbisnet.com> X-Mailer: iPhone Mail (9B176) From: Andriy Bakay Date: Tue, 10 Apr 2012 08:27:03 -0400 To: "Andrey V. Elsukov" Cc: Victor Balada Diaz , FreeBSD current , "fs@freebsd.org" , Harald Schmalzbauer Subject: Re: Idea for GEOM and policy based file encryption 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, 10 Apr 2012 12:28:09 -0000 On 2012-03-21, at 6:47, "Andrey V. Elsukov" wrote: > On 21.03.2012 14:09, Victor Balada Diaz wrote: >> You would need to modify UFS, or maybe do something like CFS[1]. CFS works >> as an NFS server and you could modify it to only cipher the needed files. >> >> Also you could write a simple FS on FUSE, but last time i checked, our >> FUSE support had some problems. >> > > Yet another link: > http://www.arg0.net/encfs > > -- > WBR, Andrey V. Elsukov > _______________________________________________ > 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" Or you can check PEFS kernel module for FreeBSD. It is in the ports. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 16:34:18 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 A841C106564A for ; Tue, 10 Apr 2012 16:34:18 +0000 (UTC) (envelope-from yarl-baudig@mailoo.org) Received: from foxnic.zionetrix.net (foxnic.zionetrix.net [212.85.154.181]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE9B8FC12 for ; Tue, 10 Apr 2012 16:34:17 +0000 (UTC) Received: by foxnic.zionetrix.net (Postfix, from userid 5001) id B10F717990; Tue, 10 Apr 2012 18:28:37 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on foxnic.zionetrix.net X-Spam-Level: X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE,USER_IN_WHITELIST autolearn=ham version=3.3.1 Received: from www.mailoo.org (localhost [127.0.0.1]) by foxnic.zionetrix.net (Postfix) with ESMTP id EB6FC1797B for ; Tue, 10 Apr 2012 18:28:36 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 10 Apr 2012 18:28:36 +0200 From: yarl-baudig@mailoo.org To: Message-ID: X-Sender: yarl-baudig@mailoo.org User-Agent: Roundcube Webmail/0.7.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: an issue 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, 10 Apr 2012 16:34:18 -0000 Hello, I got an issue on the installation of FreeBSD 9.0, went to irc and somebody asked me to send this: http://pastebin.com/gL9sjcmV Thank you! From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 08: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 3677A106564A for ; Wed, 11 Apr 2012 08:16:20 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B4FB68FC0A for ; Wed, 11 Apr 2012 08:16:19 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so607738bkc.13 for ; Wed, 11 Apr 2012 01:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=pJmWKN+d4IUM7/flrQBtf36wB76o8JkWhRqfd0tTTYM=; b=nigeOB1W7nJrxXEb8NCGw1qnFhSEREYePhKKCxw3KJNIEYZhrWgu6qiG1UnCqGfqty 6AErsbugl97DFnh7r9klKm0Y/wKMOzlNr6ZZX42KqgcmmuBYErj2+k+HSgp3EV9seEcG em8zFnMWN7wk1tJMpH+n+e2lLFrOYiq5OX7Y31KUae9oxD/NeqcjzRbB1bP0/zQ/tsrE 2/mCjOKJwBMO60ju3WuITqyNdTqM2KmtBTAaKGD0/oM7xf5+0OJ7/6EVLkVq2mlh87L+ FEDVEqxpd+QylOA3bUY8Q1TCMM5KnogAGECAceLj2bBZaNAPaYT+xKU/4nn63QD+FDCr 9TEg== Received: by 10.205.130.133 with SMTP id hm5mr5530271bkc.115.1334132178823; Wed, 11 Apr 2012 01:16:18 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.202.142 with HTTP; Wed, 11 Apr 2012 01:15:48 -0700 (PDT) In-Reply-To: References: From: Chris Rees Date: Wed, 11 Apr 2012 08:15:48 +0000 X-Google-Sender-Auth: WaRCA49U-HcjTlaoJjMd92WhXYo Message-ID: To: yarl-baudig@mailoo.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: an issue 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, 11 Apr 2012 08:16:20 -0000 On 10 April 2012 16:28, wrote: > > > Hello, I got an issue on the installation of FreeBSD 9.0, went to > irc and somebody asked me to send this: > > http://pastebin.com/gL9sjcmV > Main issue we discussed here was receiving: ATA status 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) RES: 51 84 00 00 00 00 00 00 00 01 00 Retrying command when he tried to newfs the ada0s2a partition for root. It's 9.0-RELEASE. Chris From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 14:12:19 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 0A8B81065788 for ; Wed, 11 Apr 2012 14:12:19 +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 B8DE88FC1A for ; Wed, 11 Apr 2012 14:12:18 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1SHyHr-000HYP-7S for freebsd-fs@freebsd.org; Wed, 11 Apr 2012 18:12:43 +0400 Date: Wed, 11 Apr 2012 18:12:43 +0400 From: Slawa Olhovchenkov To: freebsd-fs@freebsd.org Message-ID: <20120411141243.GR32749@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Subject: zfs & gmirror == DIRTY mirror on reboot 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, 11 Apr 2012 14:12:19 -0000 Can some one fixing kern/113957#replay4? Creating ZFS over gmirror causing gmirror DIRTY on correct reboot. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 14:21:38 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 CECFD106564A for ; Wed, 11 Apr 2012 14:21:38 +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 867488FC08 for ; Wed, 11 Apr 2012 14:21:38 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHyQN-0005EG-3m for freebsd-fs@freebsd.org; Wed, 11 Apr 2012 16:21:31 +0200 Received: from dyn1222-81.wlan.ic.ac.uk ([129.31.222.81]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 16:21:31 +0200 Received: from johannes by dyn1222-81.wlan.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 16:21:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Wed, 11 Apr 2012 15:21:17 +0100 Lines: 58 Message-ID: References: <201203022136.q22LaTvj037524@chez.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1222-81.wlan.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 In-Reply-To: <201203022136.q22LaTvj037524@chez.mckusick.com> 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, 11 Apr 2012 14:21:38 -0000 On 02/03/2012 21:36, Kirk McKusick wrote: >> 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. I got one of these as well: fsync: giving up on dirty 0xfffffe000d00bd20: tag devfs, type VCHR usecount 1, writecount 0, refcount 638 mountedhere 0xfffffe0003d23600 flags (VV_COPYONWRITE) v_object 0xfffffe0003e44ca8 ref 0 pages 2538 lock type devfs: EXCL by thread 0xfffffe001c075460 (pid 11645) dev ufs/var This happened during snapshot creation for backup with dump(8). So far machine is running fine. Subsequent snapshots succeeded. This is on: FreeBSD XXX 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1 r227793M: Mon Dec 5 22:57:54 GMT 2011 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 No journaling, just plain old UFS 2 with softupdates. Plenty of free space available. Johannes From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 15:43: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 21D08106564A for ; Wed, 11 Apr 2012 15:43:15 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A115E8FC0C for ; Wed, 11 Apr 2012 15:43:14 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1085839bkc.13 for ; Wed, 11 Apr 2012 08:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=yQduIKBDGDvzDxh3hOn8zKNT/jwRrhRfAgB5jrdvZnI=; b=RTUCyG0FPuwB84NFbQh01+GPXNpRERkvIsXIRpZ/2UgJyhZOEf3XDjXRZ0u2Fjya1P 4iwWZlANEovsztPbWUtd4Pu1cjrrsMZUepoSuxHvRWRCp4SQPG1WggnB35njHvc7BjcY P2aG83YdUAw86HsPAPIbjx4sK/fB1n/ukyP/OojtN01b6vuEAW5AvhX3TctJpH+2TLaF HBXyhdTqELruTYqDWpnti5PUMzWOUNCr5aMfNqRF6EEpmfJ8wQJzO9JbG6WaSkNo5CvJ dxZG8bAEreaijebd+UyoSO3L+keLNNI/s5mMDZZvW9sKKpC9ugGShVCQ4lSzR2YQ4ms8 tDzg== Received: by 10.204.128.65 with SMTP id j1mr6238619bks.74.1334158993736; Wed, 11 Apr 2012 08:43:13 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.202.142 with HTTP; Wed, 11 Apr 2012 08:42:43 -0700 (PDT) In-Reply-To: References: From: Chris Rees Date: Wed, 11 Apr 2012 15:42:43 +0000 X-Google-Sender-Auth: JCpYHbb8vGfFP415ewJef3sAx1U Message-ID: To: yarl-baudig@mailoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: an issue 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, 11 Apr 2012 15:43:15 -0000 On 11 April 2012 08:15, Chris Rees wrote: > On 10 April 2012 16:28, =A0 wrote: >> >> >> Hello, I got an issue on the installation of FreeBSD 9.0, went to >> irc and somebody asked me to send this: >> >> http://pastebin.com/gL9sjcmV >> > > Main issue we discussed here was receiving: > > ATA status 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) > RES: 51 84 00 00 00 00 00 00 00 01 00 > Retrying command > > when he tried to newfs the ada0s2a partition for root. > > It's 9.0-RELEASE. I might suggest trying an ISO snapshot of 9-STABLE: 32-bit: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-RELENG_9-20120411-JPS= NAP 64-bit: http://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.0-RELENG_9-20120411-J= PSNAP There was a recent thread (though I can't find it now :/) about some ATA issues similiar to this, which were fixed in STABLE but were too late to be merged to RELEASE. If you would like something to try, I'd try those. Chris From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 08:34: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 929E9106564A for ; Thu, 12 Apr 2012 08:34:48 +0000 (UTC) (envelope-from kraduk@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 4F8BD8FC08 for ; Thu, 12 Apr 2012 08:34:48 +0000 (UTC) Received: by yhgm50 with SMTP id m50so1115833yhg.13 for ; Thu, 12 Apr 2012 01:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZxXnFe/GarNmEdY4ocFM+lGIGLfWg522oPYTxQuxBuY=; b=Xi07xJdDTj+vmo9eBBdfbcluLY2LFS5mO2LiEaJ+mJdoQf9PCyqi7Pe797zNGLRNrT kTTY1rAcbzvGTJ3Yb4j8RBl+bsBKTQaO8Nkt9y0nHucRq+IKzG9R8bEX+a4swKuqBaTg jF2nngK7xmHSNreQlkg1initPUqk+sh/LWPJRL+iwY+hGzgOmPSD9BsA45P8TSry7Ap9 3af8CcnkdJNDU9tkSEH7EQAGsWyeOtSeWu9HpH1xR7c6xOEthi6RVw06cHpMN0swp7U1 dTmhgNVLPOoevPWv/aNRm2AVOxlHVqlENaTGp3WvdDVjCwYLViPg6P9PB419IcE9YC0/ deKA== MIME-Version: 1.0 Received: by 10.50.197.164 with SMTP id iv4mr1444956igc.73.1334219687293; Thu, 12 Apr 2012 01:34:47 -0700 (PDT) Received: by 10.50.129.35 with HTTP; Thu, 12 Apr 2012 01:34:47 -0700 (PDT) In-Reply-To: <20120411141243.GR32749@zxy.spb.ru> References: <20120411141243.GR32749@zxy.spb.ru> Date: Thu, 12 Apr 2012 09:34:47 +0100 Message-ID: From: krad To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: zfs & gmirror == DIRTY mirror on reboot 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, 12 Apr 2012 08:34:48 -0000 On 11 April 2012 15:12, Slawa Olhovchenkov wrote: > Can some one fixing kern/113957#replay4? > Creating ZFS over gmirror causing gmirror DIRTY on correct reboot. > _______________________________________________ > 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" this seams like a bizarre configuration. Why not let zfs do the mirroring as its more efficient in many ways? From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 08:39: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 D350A106568B for ; Thu, 12 Apr 2012 08:39:42 +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 8ADC58FC1B for ; Thu, 12 Apr 2012 08:39:42 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1SIFZW-000F4V-2H; Thu, 12 Apr 2012 12:40:06 +0400 Date: Thu, 12 Apr 2012 12:40:06 +0400 From: Slawa Olhovchenkov To: krad Message-ID: <20120412084006.GA32749@zxy.spb.ru> References: <20120411141243.GR32749@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 Subject: Re: zfs & gmirror == DIRTY mirror on reboot 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, 12 Apr 2012 08:39:42 -0000 On Thu, Apr 12, 2012 at 09:34:47AM +0100, krad wrote: > On 11 April 2012 15:12, Slawa Olhovchenkov wrote: > > Can some one fixing kern/113957#replay4? > > Creating ZFS over gmirror causing gmirror DIRTY on correct reboot. > > _______________________________________________ > > 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" > > > this seams like a bizarre configuration. Why not let zfs do the > mirroring as its more efficient in many ways? I am need to reliable boot (toleranted to bad blocks in boot area, boot1/boot2). reliable boot => mirror in bios. PREC S100 don't have on-disk information about mirror => gmirror on OS level. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 08:58:09 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 5C7591065670 for ; Thu, 12 Apr 2012 08:58:09 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id E291C8FC19 for ; Thu, 12 Apr 2012 08:58:08 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MTrTY-1Sikxt2IXg-00QWMY; Thu, 12 Apr 2012 10:58:01 +0200 Message-ID: <4F869919.9060802@brockmann-consult.de> Date: Thu, 12 Apr 2012 10:58:01 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120411141243.GR32749@zxy.spb.ru> <20120412084006.GA32749@zxy.spb.ru> In-Reply-To: <20120412084006.GA32749@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:sMy/7xwemXeOyVgfoRUocXaBqWqeAg97UZEbbmljNl5 wgr2RPhagHBkA+/T8W0uXjLb/u74RKu10lONShu86vc+J5QWlW Ka8nqTAD94sfKBNmcLV6qstZTxeNwxELZo9jG+osbSqxcu1alH hMTf0ST+hHhb72gxLJUc1xRDrp0uLRzMsX33emelv1cnrm3BES hei/BsaTAuKq1vXG/1a69WKI4ROREKA+pE2qu8+x0u2CYKpgHG YeANS4kQnwJXOWz9vQmMAIBRtPSFHcrYhC5EzEM1LEbVBDJaOo VTM+UAtO4OxUluQpNTzjM5UcG+7zXfTFU4oZScvoeLQozBVl3m ntqG/tFjRWTBBYp52gw0cUG9UmrWdIpIF2U+H5/8m Subject: Re: zfs & gmirror == DIRTY mirror on reboot 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, 12 Apr 2012 08:58:09 -0000 On 04/12/2012 10:40 AM, Slawa Olhovchenkov wrote: > On Thu, Apr 12, 2012 at 09:34:47AM +0100, krad wrote: > >> On 11 April 2012 15:12, Slawa Olhovchenkov wrote: >>> Can some one fixing kern/113957#replay4? >>> Creating ZFS over gmirror causing gmirror DIRTY on correct reboot. >> this seams like a bizarre configuration. Why not let zfs do the >> mirroring as its more efficient in many ways? > I am need to reliable boot (toleranted to bad blocks in boot area, boot1/boot2). > reliable boot => mirror in bios. > PREC S100 don't have on-disk information about mirror => gmirror on OS > level. What's wrong with mirroring your / and /boot with zfs, and then if the bootcode blocks get broken, just do the bootcode commands again: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 gmirroring your bootcode won't do anything more than this would, since it is static content. (Or are you not talking about bootcode?) > _______________________________________________ > 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 Apr 12 22:20: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 7467D106564A for ; Thu, 12 Apr 2012 22:20: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 5E2CA8FC18 for ; Thu, 12 Apr 2012 22:20: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 q3CMKEVr024096 for ; Thu, 12 Apr 2012 22: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 q3CMKEC1024095; Thu, 12 Apr 2012 22:20:14 GMT (envelope-from gnats) Date: Thu, 12 Apr 2012 22:20:14 GMT Message-Id: <201204122220.q3CMKEC1024095@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Patrick Proniewski Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Patrick Proniewski List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 22:20:14 -0000 The following reply was made to PR kern/156781; it has been noted by GNATS. From: Patrick Proniewski To: bug-followup@FreeBSD.org, bmeyer@mesoft.com.au Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, Date: Fri, 13 Apr 2012 00:15:40 +0200 Same problem here: FreeBSD mybox 8.1-RELEASE-p5 FreeBSD 8.1-RELEASE-p5 #0: Tue Sep 27 = 16:49:00 UTC 2011 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 ls of some .zfs directories returns the "Bad file descriptor" error. zfs list still shows every snapshots, and daily snapshot = creation/rotation works as expected. I tried to unmount the faulty zfs volume, but the system froze, I had to = reboot the server.= From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 07:30:21 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 CCDE21065672 for ; Fri, 13 Apr 2012 07:30:21 +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 B799C8FC15 for ; Fri, 13 Apr 2012 07:30:21 +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 q3D7ULQp059772 for ; Fri, 13 Apr 2012 07:30:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3D7ULdV059769; Fri, 13 Apr 2012 07:30:21 GMT (envelope-from gnats) Date: Fri, 13 Apr 2012 07:30:21 GMT Message-Id: <201204130730.q3D7ULdV059769@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Peter Maloney Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Maloney List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 07:30:21 -0000 The following reply was made to PR kern/156781; it has been noted by GNATS. From: Peter Maloney To: bug-followup@FreeBSD.org, bmeyer@mesoft.com.au Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, Date: Fri, 13 Apr 2012 09:25:16 +0200 Is the faulty dataset shared over NFS? If so, is it the new NFS server (default in 9.0 I think) or the old (default in 8.2)? My ZFS over NFS on 8-STABLE has slightly similar problems on the NFS client side, but only when viewed by a Linux client. A simple "ls -l" on the .zfs/snapshot directory on a Linux client hangs the dataset. And these lines show up in /var/log/messages when reloading the NFS server: Apr 12 10:08:38 [hostname] mountd[54479]: can't delete exports for /tank/[...]/.zfs/snapshot/replication-20120411112000: Invalid argument And an "ls" without "-l" on a Linux client shows that the ones mentioned in messages are files and the rest are directories (Linux shells generally color them blue and append a / for directories). I can only guess that they may be related. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 12:20: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 D9ADF1065672 for ; Fri, 13 Apr 2012 12:20:53 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from smtp.tuxis.nl (smtp.tuxis.nl [IPv6:2a03:7900:2:0:31:3:104:34]) by mx1.freebsd.org (Postfix) with ESMTP id 461EB8FC20 for ; Fri, 13 Apr 2012 12:20:53 +0000 (UTC) Received: from [2a03:7900:2:0:31:3:104:46] (port=34803 helo=go.tuxis.net) by smtp.tuxis.nl with esmtp (Exim 4.71) (envelope-from ) id 1SIfUi-0004tS-7w for freebsd-fs@freebsd.org; Fri, 13 Apr 2012 14:20:52 +0200 Received: from localhost (localhost [127.0.0.1]) by go.tuxis.net (Postfix) with ESMTP id 27E1B20581 for ; Fri, 13 Apr 2012 14:21:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at www.hyperdesktop.nl Received: from go.tuxis.net ([127.0.0.1]) by localhost (go.tuxis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmCIJvr5LuS1 for ; Fri, 13 Apr 2012 14:21:13 +0200 (CEST) Received: from www.hyperdesktop.nl (unknown [IPv6:::1]) by go.tuxis.net (Postfix) with ESMTP id C65BF2057F for ; Fri, 13 Apr 2012 14:21:13 +0200 (CEST) Message-ID: <1334319673.4f881a39b32a8@www.hyperdesktop.nl> Date: Fri, 13 Apr 2012 14:21:13 +0200 From: Mark Schouten To: "freebsd-fs@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced by Group-Office 3.7.42 X-Mailer: Group-Office 3.7.42 X-Priority: 3 (Normal) Subject: ZFS and disk usage 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, 13 Apr 2012 12:20:53 -0000 Hi, I'm having some issues with a FreeBSD box using ZFS to se= rve iscsi to other boxes. [root@storage ~]# zpool list N= AME SIZE USED AVAIL CAP HEALTH ALTROOT storage 1.77T = 431G 1.34T 23% ONLINE - As you can see, the zpool is at o= nly 23% of it's capacity. However, if you get a list of filesystems with= "zfs list", you see that there is only 138GB free space left. [root= @storage ~]# zfs list NAME USED = AVAIL REFER MOUNTPOINT storage 1.60= T 138G 431G /storage storage/ZFS_FS_1 2= 0G 158G 16K - storage/ZFS_FS_2 20G 15= 8G 16K -=20 storage/ZFS_FS_3 100G 238G = 16K -=20 storage/ZFS_FS_4 20G 158G 16K = -=20 storage/ZFS_FS_5 1G 139G 16K -= =20 storage/ZFS_FS_6 400G 538G 16K - = storage/ZFS_FS_7 20G 158G 16K -=20 s= torage/ZFS_FS_8 400G 538G 16K -=20 storag= e/ZFS_FS_9 20G 158G 16K -=20 storage/ZFS= _FS_10 20G 158G 16K -=20 storage/ZFS_FS_11= 20G 158G 16K -=20 storage/ZFS_FS_12 = 150G 288G 16K -=20 storage/ZFS_FS_13 = 20G 158G 16K -=20 These are fiesystems that= are created with the following command. zfs create -V ${size}GB ${Z= FS_ROOT}/${diskname} Now, it seems that zpool only counts the d= ata that is actually written on the disk, and that zfs counts both the s= um of the individual filesystems *and* the data actually written on disk= . If I was to create a new filesystem of 138GB, the filesystem would be = full, eventhough that that's not the case. This seems weird, but= I'm not sure if it's me doing something wrong, or if its a bug. Please = enlighten me, thanks. Some more info: [root@sto= rage ~]# uname -a FreeBSD storage.storage 8.2-RELEASE FreeBSD 8.2-RE= LEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/u= sr/obj/usr/src/sys/GENERIC amd64 [root@storage ~]# zpool get a= ll storage NAME PROPERTY VALUE SOURCE storage s= ize 1.77T - storage used 431G -= storage available 1.34T - storage capacity 2= 3% - storage altroot - default storage= health ONLINE - storage guid 1090519474454= 5589060 default storage version 15 default sto= rage bootfs - default storage delegation on = default storage autoreplace off default sto= rage cachefile - default storage failmode wai= t default storage listsnapshots off default= [root@storage ~]# zfs get all storage NAME PROPERTY= VALUE SOURCE storage type = filesystem - storage creation Tue Ma= y 10 11:59 2011 - storage used 1.60T = - storage available 138G - s= torage referenced 431G - storage comp= ressratio 1.00x - storage mounted = yes - storage quota none = default storage reservation none = default storage recordsize 128K = default storage mountpoint /storage d= efault storage sharenfs off default= storage checksum on default s= torage compression off default storage= atime on default storage devi= ces on default storage exec = on default storage setuid = on default storage readonly = off default storage jailed off = default storage snapdir hidden = default storage aclmode groupmask = default storage aclinherit restricted d= efault storage canmount on default= storage shareiscsi off default s= torage xattr off temporary stora= ge copies 1 default storage ve= rsion 4 - storage utf8only = off - storage normalization none= - storage casesensitivity sensitive = - storage vscan off defau= lt storage nbmand off default= storage sharesmb off default s= torage refquota none default storage= refreservation none default storage prim= arycache all default storage secondaryc= ache all default storage usedbysnapshots = 0 - storage usedbydataset 431G = - storage usedbychildren 1.18T = - storage usedbyrefreservation 0 = - --=20 Dit bericht is verzonden via https://www.hyperdes= ktop.nl/. Alles, overal! Mark Schouten | Tuxis Internet Engine= ering KvK: 09218193 | http://www.tuxis.nl/ T: 0318 200208 | info= @tuxis.nl M: 06 53463918 | mark@tuxis.nl From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 13:11:08 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 2E78C106567E for ; Fri, 13 Apr 2012 13:11:08 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 53F8E8FC12 for ; Fri, 13 Apr 2012 13:11:06 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3105538bkc.13 for ; Fri, 13 Apr 2012 06:11:05 -0700 (PDT) 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=8a3+FSZSmiUrREBGkCZ/yreDd8uDtst2dim4AjwIlTU=; b=t2HZn29G8jWnNeZpo22VtwOl2dx4a93UsePwwgadCck2HikJ52y3eQTOJHyDmHZOaN FXAHQ/2l9gMEoe6d+nPVQg06Fl/lf/Xpte+O0iySV1H4DjWzviZvHjJyeSxOEvgs1I7x dzaqZRZR7gOOzAS3v9ZC0rtd2RW3Y1ULC7wbYhzwg9+EZ4HIiPGm+3wuM8JQULlOPI9n MPhUTwD5k1IG4KGAR6awy2Qi2FUQKqaT9gItAJX1Vadu7CfJJ73mx7QmnHKJiKJUNYwf EWJLtGJZAD70Ol2laetLb2w40c2ZqBmkS4xoTX01aWz0gT8MP8gNG6DqYvCUlgtnjEXV vZuA== Received: by 10.205.129.4 with SMTP id hg4mr501530bkc.16.1334322665120; Fri, 13 Apr 2012 06:11:05 -0700 (PDT) Received: from green.tandem.local (223-39-132-95.pool.ukrtel.net. [95.132.39.223]) by mx.google.com with ESMTPS id u16sm16493857bkf.10.2012.04.13.06.11.03 (version=SSLv3 cipher=OTHER); Fri, 13 Apr 2012 06:11:04 -0700 (PDT) Message-ID: <4F8825E5.3040809@gmail.com> Date: Fri, 13 Apr 2012 16:11:01 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Mark Schouten References: <1334319673.4f881a39b32a8@www.hyperdesktop.nl> In-Reply-To: <1334319673.4f881a39b32a8@www.hyperdesktop.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 13 Apr 2012 13:11:08 -0000 Mark Schouten wrote: > Hi, > > I'm having some issues with a FreeBSD box using ZFS to serve iscsi to other boxes. > > [root@storage ~]# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > storage 1.77T 431G 1.34T 23% ONLINE - > > As you can see, the zpool is at only 23% of it's capacity. However, if you get a list of filesystems with "zfs list", you see that there is only 138GB free space left. > [root@storage ~]# zfs list > NAME USED AVAIL REFER MOUNTPOINT > storage 1.60T 138G 431G /storage > storage/ZFS_FS_1 20G 158G 16K - > storage/ZFS_FS_2 20G 158G 16K - > storage/ZFS_FS_3 100G 238G 16K - > storage/ZFS_FS_4 20G 158G 16K - > storage/ZFS_FS_5 1G 139G 16K - > storage/ZFS_FS_6 400G 538G 16K - > storage/ZFS_FS_7 20G 158G 16K - > storage/ZFS_FS_8 400G 538G 16K - > storage/ZFS_FS_9 20G 158G 16K - > storage/ZFS_FS_10 20G 158G 16K - > storage/ZFS_FS_11 20G 158G 16K - > storage/ZFS_FS_12 150G 288G 16K - > storage/ZFS_FS_13 20G 158G 16K - > > These are fiesystems that are created with the following command. > zfs create -V ${size}GB ${ZFS_ROOT}/${diskname} `zfs create -V` withous `-s` creates reserved volume that eats all needed space immediately. Technically zfs pool is filled only for 23%, but logically you have only 138G left unassigned. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 13:28:11 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 16192106566B for ; Fri, 13 Apr 2012 13:28:11 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from smtp.tuxis.nl (smtp.tuxis.nl [IPv6:2a03:7900:2:0:31:3:104:34]) by mx1.freebsd.org (Postfix) with ESMTP id 9F02E8FC16 for ; Fri, 13 Apr 2012 13:28:10 +0000 (UTC) Received: from [2a03:7900:2:0:31:3:104:46] (port=34978 helo=go.tuxis.net) by smtp.tuxis.nl with esmtp (Exim 4.71) (envelope-from ) id 1SIgXp-000587-S6 for freebsd-fs@freebsd.org; Fri, 13 Apr 2012 15:28:09 +0200 Received: from localhost (localhost [127.0.0.1]) by go.tuxis.net (Postfix) with ESMTP id 05B9620BBF for ; Fri, 13 Apr 2012 15:28:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at www.hyperdesktop.nl Received: from go.tuxis.net ([127.0.0.1]) by localhost (go.tuxis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E3IjYW2p96a for ; Fri, 13 Apr 2012 15:28:28 +0200 (CEST) Received: from www.hyperdesktop.nl (unknown [IPv6:::1]) by go.tuxis.net (Postfix) with ESMTP id 1575420BBE for ; Fri, 13 Apr 2012 15:28:28 +0200 (CEST) Message-ID: <1334323707.4f8829fbe801e@www.hyperdesktop.nl> Date: Fri, 13 Apr 2012 15:28:27 +0200 From: Mark Schouten To: Volodymyr Kostyrko MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced by Group-Office 3.7.42 In-Reply-To: <4F8825E5.3040809@gmail.com> References: <4F8825E5.3040809@gmail.com> X-Mailer: Group-Office 3.7.42 X-Priority: 3 (Normal) Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 13 Apr 2012 13:28:11 -0000 Hi, Op Vrijdag, 13-04-2012 om 15:11 schreef Volodymyr Kostyrk= o: > > These are fiesystems that are created with the following comm= and. > > zfs create -V ${size}GB ${ZFS_ROOT}/${diskname}= >=20 > `zfs create -V` withous `-s` creates reserved volume that e= ats all=20 > needed space immediately. Technically zfs pool is filled = only for 23%,=20 > but logically you have only 138G left unassigne= d. I understand. However, the created volumes should use a total= of 1211GB. That's not 1.6TB like zfs list says. But 1211 + 431 (referre= d) does come close to 1.6TB.n And 1.6 TB still isn't the 1.77TB that's i= n the zpool. I have this feeling that zfs has reserved the spac= e for each volume, but counts data written to the volumes in usage of th= e main filesystem. Mainly because zfs list shows me that the volumes hav= e only 16KB referenced, where /storage has 431GB referenced. --= =20 Dit bericht is verzonden via https://www.hyperdesktop.nl/. Alles, = overal! Mark Schouten | Tuxis Internet Engineering KvK: = 09218193 | http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl M= : 06 53463918 | mark@tuxis.nl From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 13:32: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 AD3B1106566B for ; Fri, 13 Apr 2012 13:32:32 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2148FC16 for ; Fri, 13 Apr 2012 13:32:32 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MKMjK-1SKL2P0cII-001poz; Fri, 13 Apr 2012 15:32:31 +0200 Message-ID: <4F882AEE.8040706@brockmann-consult.de> Date: Fri, 13 Apr 2012 15:32:30 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <1334319673.4f881a39b32a8@www.hyperdesktop.nl> In-Reply-To: <1334319673.4f881a39b32a8@www.hyperdesktop.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:tnmtxUxwi8xg3xoMpvpPlKqmvQjGTRFWHnXHVuLqx0l dn2T/O3chCbRaFzWBCMFcnds83sX4fd2RUeXOfJoi9GuLF2qtJ OlRaoGaHRzZ9vwQIle6yeyFgR+SKWdP3OBNnJsqbU6NWNh7jGm wT00kN+FrMMIWARvSwkGADTPwTnsdColmJnvfDWf0uVJ0GXhSh inp8dErnWn0mgu7nIJFkO4w1m71Sa9DM97aHd1eVq5eOEamfu1 uvFEpW9/1QFWl6X/1P3PSO57kgVlJ1oIteLd6PJ2QbVUcQpa04 OxK75C0QAyW0WPTxheAUJcGA9d2KAgTURsji7WupDIJSmdsihf fc7aNFzlryq+ApPssr4W+CDzpz1MGPXAF8jOMzDXf Subject: Re: ZFS and disk usage 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, 13 Apr 2012 13:32:32 -0000 Please run this (my script I call zfsdf): zfs list -o name,used,referenced,usedbychildren,usedbydataset,usedbysnapshots,available,mountpoint,quota,reserv,refquota,refreserv "$@" | sed -r "s/none/ -/g" zpool list -o name,size,allocated,free,capacity It may give some small hints (similar to zfs get all but for all datasets, telling about refquota, snap used, etc.), but... I think it won't tell us enough, and the problem is 8.2-RELEASE. You should definitely upgrade to 8-STABLE, or 8.3-rc2. [with regression testing of course, but not as much as you would need for 9.x] [btw, I found that 8-STABLE in Sept 2011 would hang renaming snapshots with ZVOLS, but not 8-STABLE from Feb 2012, so be extra careful with zvols] On my 8-STABLE systems, the numbers make sense: semi-new system: # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 37.7T 10.2T 67.5K /tank # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 63.2T 49.0T 14.3T 77% 1.00x ONLINE - # bc scale=5 37.7/(10.2+37.7) .78705 year old system (scripts create and destroy 1 recursive snapshot every 20 minutes): # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 14.5T 17.5T 5.99G /tank # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 43.5T 19.4T 24.1T 44% 1.00x ONLINE - # bc scale=5 14.5/(14.5+17.5) .45312 On 04/13/2012 02:21 PM, Mark Schouten wrote: > Hi, > > I'm having some issues with a FreeBSD box using ZFS to serve iscsi to other boxes. > > [root@storage ~]# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > storage 1.77T 431G 1.34T 23% ONLINE - > > As you can see, the zpool is at only 23% of it's capacity. However, if you get a list of filesystems with "zfs list", you see that there is only 138GB free space left. > [root@storage ~]# zfs list > NAME USED AVAIL REFER MOUNTPOINT > storage 1.60T 138G 431G /storage > storage/ZFS_FS_1 20G 158G 16K - > storage/ZFS_FS_2 20G 158G 16K - > storage/ZFS_FS_3 100G 238G 16K - > storage/ZFS_FS_4 20G 158G 16K - > storage/ZFS_FS_5 1G 139G 16K - > storage/ZFS_FS_6 400G 538G 16K - > storage/ZFS_FS_7 20G 158G 16K - > storage/ZFS_FS_8 400G 538G 16K - > storage/ZFS_FS_9 20G 158G 16K - > storage/ZFS_FS_10 20G 158G 16K - > storage/ZFS_FS_11 20G 158G 16K - > storage/ZFS_FS_12 150G 288G 16K - > storage/ZFS_FS_13 20G 158G 16K - > > These are fiesystems that are created with the following command. > zfs create -V ${size}GB ${ZFS_ROOT}/${diskname} > > Now, it seems that zpool only counts the data that is actually written on the disk, and that zfs counts both the sum of the individual filesystems *and* the data actually written on disk. If I was to create a new filesystem of 138GB, the filesystem would be full, eventhough that that's not the case. > > This seems weird, but I'm not sure if it's me doing something wrong, or if its a bug. Please enlighten me, thanks. > > > > Some more info: > [root@storage ~]# uname -a > FreeBSD storage.storage 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 > > [root@storage ~]# zpool get all storage > NAME PROPERTY VALUE SOURCE > storage size 1.77T - > storage used 431G - > storage available 1.34T - > storage capacity 23% - > storage altroot - default > storage health ONLINE - > storage guid 10905194744545589060 default > storage version 15 default > storage bootfs - default > storage delegation on default > storage autoreplace off default > storage cachefile - default > storage failmode wait default > storage listsnapshots off default > > [root@storage ~]# zfs get all storage > NAME PROPERTY VALUE SOURCE > storage type filesystem - > storage creation Tue May 10 11:59 2011 - > storage used 1.60T - > storage available 138G - > storage referenced 431G - > storage compressratio 1.00x - > storage mounted yes - > storage quota none default > storage reservation none default > storage recordsize 128K default > storage mountpoint /storage default > storage sharenfs off default > storage checksum on default > storage compression off default > storage atime on default > storage devices on default > storage exec on default > storage setuid on default > storage readonly off default > storage jailed off default > storage snapdir hidden default > storage aclmode groupmask default > storage aclinherit restricted default > storage canmount on default > storage shareiscsi off default > storage xattr off temporary > storage copies 1 default > storage version 4 - > storage utf8only off - > storage normalization none - > storage casesensitivity sensitive - > storage vscan off default > storage nbmand off default > storage sharesmb off default > storage refquota none default > storage refreservation none default > storage primarycache all default > storage secondarycache all default > storage usedbysnapshots 0 - > storage usedbydataset 431G - > storage usedbychildren 1.18T - > storage usedbyrefreservation 0 - > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 15:27:36 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 058721065670 for ; Fri, 13 Apr 2012 15:27:36 +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 B021E8FC0A for ; Fri, 13 Apr 2012 15:27:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SIiPF-0000Y4-06 for freebsd-fs@freebsd.org; Fri, 13 Apr 2012 17:27:25 +0200 Received: from dyn1200-198.wlan.ic.ac.uk ([129.31.200.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2012 17:27:24 +0200 Received: from johannes by dyn1200-198.wlan.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2012 17:27:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Fri, 13 Apr 2012 16:27:10 +0100 Lines: 29 Message-ID: References: <4F8825E5.3040809@gmail.com> <1334323707.4f8829fbe801e@www.hyperdesktop.nl> 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: dyn1200-198.wlan.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 In-Reply-To: <1334323707.4f8829fbe801e@www.hyperdesktop.nl> Subject: Re: ZFS and disk usage 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, 13 Apr 2012 15:27:36 -0000 On 13/04/2012 14:28, Mark Schouten wrote: > Hi, > > Op Vrijdag, 13-04-2012 om 15:11 schreef Volodymyr Kostyrko: >>> These are fiesystems that are created with the following >>> command. zfs create -V ${size}GB ${ZFS_ROOT}/${diskname} >> >> `zfs create -V` withous `-s` creates reserved volume that eats all >> needed space immediately. Technically zfs pool is filled only for >> 23%, but logically you have only 138G left unassigned. > > I understand. However, the created volumes should use a total of > 1211GB. That's not 1.6TB like zfs list says. But 1211 + 431 > (referred) does come close to 1.6TB.n And 1.6 TB still isn't the > 1.77TB that's in the zpool. > > I have this feeling that zfs has reserved the space for each volume, > but counts data written to the volumes in usage of the main > filesystem. Mainly because zfs list shows me that the volumes have > only 16KB referenced, where /storage has 431GB referenced. Without checking the numbers myself... Note that zpool and zfs do not agree on (free) space accounting: zpool shows "raw" space, whereas zfs includes metadata overhead for itself. Small rant: I dont understand why zpool and zfs show different things. If you have an integrated storage stack then why not show consistent numbers? Is there any use for this extra (mis-)information that zpool-vs-zfs provides? From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 15:44:38 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 6BC8B1065670 for ; Fri, 13 Apr 2012 15:44:38 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 230048FC08 for ; Fri, 13 Apr 2012 15:44:38 +0000 (UTC) Received: by vbmv11 with SMTP id v11so3052552vbm.13 for ; Fri, 13 Apr 2012 08:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=smubtlmDMJ9/dT9aOYcMi3OPr1XEMPtx8PeLECiGAX4=; b=hNYmEHLIxh3IxtegpIJVd7zLPuL8JUaMUaDAQ0JneEMSbqZg/C8xzbMqCjTJZgv0Tu Fl5ljfpvTKTaWHo8J1PCm7csydKTjOTd7PpYMfCw964fwnt47ldwZEvQa34i8y+Jy7lC fjr7dCvNmV7UFMsPjPNyYfDpXrYnZ810QcNZpT/yN7nPYmZPNZPj48DZc+5fdIny38We qsydSVKdRArOBZIELgUkqrcNPO5BWaxFwJqzAY0m+hDOeZEenIK5NXt2ioSB2kOOMJCd aiGQZFonK8yoLJiSji17wnQXRVqJY18MMoAlx2BPLhHvT/hoQOQg67IEwMmp4X0Dy6T3 MBMA== MIME-Version: 1.0 Received: by 10.52.24.170 with SMTP id v10mr801601vdf.74.1334331877327; Fri, 13 Apr 2012 08:44:37 -0700 (PDT) Received: by 10.52.181.129 with HTTP; Fri, 13 Apr 2012 08:44:37 -0700 (PDT) In-Reply-To: References: <4F8825E5.3040809@gmail.com> <1334323707.4f8829fbe801e@www.hyperdesktop.nl> Date: Fri, 13 Apr 2012 16:44:37 +0100 Message-ID: From: Tom Evans To: Johannes Totz Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and disk usage 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, 13 Apr 2012 15:44:38 -0000 On Fri, Apr 13, 2012 at 4:27 PM, Johannes Totz wrote: > Small rant: I dont understand why zpool and zfs show different things. > If you have an integrated storage stack then why not show consistent > numbers? Is there any use for this extra (mis-)information that > zpool-vs-zfs provides? > They are supposed to be different things. `zpool list` shows the size of the raw storage in the pool, where as `zfs list` shows the size of file systems on that storage. zpool deals with raw storage blocks, why would it talk about the size of the overlying filesystem? Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 15:45:57 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 8FF401065672 for ; Fri, 13 Apr 2012 15:45:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65B1C8FC08 for ; Fri, 13 Apr 2012 15:45:57 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so4088409pbc.13 for ; Fri, 13 Apr 2012 08:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2cEcNaNeRgDUkf7yxvv6bA5hFlH0/zvrefjxfGgojVw=; b=KqChCcHe47Rc6SfyuwnJ1NGllmlb+1/QRhzGXbZCzr5MGNZxiR73N+yvPalATO/c3e 4KkdTc7YtKzEVgbF+GL1ZZv5EoIps5v7ULTeuY+4vm9XnDNbUOmPE62aDn+bmnBtCCma B6912NPOaHuysVek71FENxtBUUy6e0WWjPLXfAxi3VI6CLKPqpuKaZRPUtd3bSAXPrxr KHbKBEfoZOBFkpNMMpwI/mipMvypm8xDeqVmhXFrhSZNnigsT6XPfmpL1kM6M7fDbPHV W1SGQ4ZIcdNSuD+QAXrRKX9tZd8xsjBBSDXZH1hRekOTEApIi0Vl5Wdst48bIw+O+6ts zwYw== MIME-Version: 1.0 Received: by 10.68.202.234 with SMTP id kl10mr5623092pbc.52.1334331957003; Fri, 13 Apr 2012 08:45:57 -0700 (PDT) Received: by 10.68.42.7 with HTTP; Fri, 13 Apr 2012 08:45:56 -0700 (PDT) In-Reply-To: References: <4F8825E5.3040809@gmail.com> <1334323707.4f8829fbe801e@www.hyperdesktop.nl> Date: Fri, 13 Apr 2012 08:45:56 -0700 Message-ID: From: Freddie Cash To: Johannes Totz Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and disk usage 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, 13 Apr 2012 15:45:57 -0000 On Fri, Apr 13, 2012 at 8:27 AM, Johannes Totz wrote: > Without checking the numbers myself... > Note that zpool and zfs do not agree on (free) space accounting: zpool > shows "raw" space, whereas zfs includes metadata overhead for itself. > > Small rant: I dont understand why zpool and zfs show different things. > If you have an integrated storage stack then why not show consistent > numbers? Is there any use for this extra (mis-)information that > zpool-vs-zfs provides? There's a great posting about the differences in the zfs-discuss mailing list archives, although I can't find a reference to it at the moment. Going from memory, the breakdown is something like: zpool shows "raw storage available to the pool across all vdevs", without counting any redundancy. This should be approx. "size of drives * num of drives". zfs shows "storage space available for use", after removing all redundancy, extra space for metadata, checksums, etc. This is what's available for programs to use, before compression and dedupe take effect. df shows "storage space available to userspace programs" after all compressions, dedupe, metadata, checksums, etc have been removed. This is the actual space that users can access. "ls -l" shows the "size of files" (as in, uncompressed, rehydrated, the size it would be if you copied it to a floppy). They each work on different layers of the storage stack (DMU, ZPL, userspace, etc). Hence, they show different values. But once you think about what each layer of the stack is doing ... the numbers make perfect sense. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 15:49:42 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 F38A9106566C for ; Fri, 13 Apr 2012 15:49:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id C61BF8FC0A for ; Fri, 13 Apr 2012 15:49:41 +0000 (UTC) Received: by dadz14 with SMTP id z14so13337539dad.17 for ; Fri, 13 Apr 2012 08:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pf1cG1MXpTrue2jaxnsqmGMp7sB5pDAvYi8IjIPzS4M=; b=KTAWN6gOn2T6+Do5Z2VNrx0gTrMCHfZMAnGDuEKdWZzmtbVHR9byLzgHDNvfrLvOTD pybvPnJaREeJg5P2BQ7IZDP9jfbsjH9AHTgG5spZIH/0HGa38DvSqbmbSC5hlweZ4JXf tgcgfq/nvrfk49HiJvTxk/keVRSbXyvSeaug1P84aFw0opA/JcLO4evSQqjzx60O+n0x hPiWTnDnBDdcSyeBMuCML0ri67D7aVsQScbdufs598KQm/vy2QwyJlhSaxEzIeb3fX7+ Z9UYAUusa0dAC+8Pccyt0gQWzZ3Tnj94Z6S1kIkWeZhbiOpl2VjEnGqWPuHe3ecIkQ4j XQ8g== MIME-Version: 1.0 Received: by 10.68.132.36 with SMTP id or4mr5547653pbb.115.1334332180575; Fri, 13 Apr 2012 08:49:40 -0700 (PDT) Received: by 10.68.42.7 with HTTP; Fri, 13 Apr 2012 08:49:40 -0700 (PDT) In-Reply-To: References: <4F8825E5.3040809@gmail.com> <1334323707.4f8829fbe801e@www.hyperdesktop.nl> Date: Fri, 13 Apr 2012 08:49:40 -0700 Message-ID: From: Freddie Cash To: Johannes Totz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and disk usage 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, 13 Apr 2012 15:49:42 -0000 On Fri, Apr 13, 2012 at 8:45 AM, Freddie Cash wrote: > On Fri, Apr 13, 2012 at 8:27 AM, Johannes Totz wrote: >> Without checking the numbers myself... >> Note that zpool and zfs do not agree on (free) space accounting: zpool >> shows "raw" space, whereas zfs includes metadata overhead for itself. >> >> Small rant: I dont understand why zpool and zfs show different things. >> If you have an integrated storage stack then why not show consistent >> numbers? Is there any use for this extra (mis-)information that >> zpool-vs-zfs provides? > > There's a great posting about the differences in the zfs-discuss > mailing list archives, although I can't find a reference to it at the > moment. =C2=A0Going from memory, the breakdown is something like: Here's one of them: http://mail.opensolaris.org/pipermail/zfs-discuss/2010-April/040180.html Message details: On Sun, Apr 18, 2010 at 20:08, Harry Putnam wrote: > Seems like you can get some pretty large discrepancies in sizes of > pools. and directories. They all answer different things, sure, but they're all things that an administrator might want to know. > zpool list "How many bytes are in use on the storage device? How many unallocated bytes are there?" > zfs list "If I have to ship this filesystem to another box (uncompressed and not deduped) how many bytes is that?" > du "How many bytes are used to store the contents of the files in this directo= ry?" and "ls -l": "How many bytes are addressable in this file?" > Do no other administrators feel the > need to know accurate sizes? It's important to consider what you want this data for. Considering upgrading your storage to get more room? Check out "zpool list". Need to know whether accounting or engineering is using more space? Look at "zfs list". Looking at a sparse or compressed file, and want to know how many bytes are allocated to it? "du" does the trick. Planning to email someone a file, and want to know if it'll fit in their 10MB quota? "ls -l" is the relevant command. In short, there are many commands because there are many answers, and many questions. No single tool has all the information available to it. Will --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 16:33:07 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 BC5AA10657E0 for ; Fri, 13 Apr 2012 16:33:07 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3B11D8FC16 for ; Fri, 13 Apr 2012 16:33:07 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3318508bkc.13 for ; Fri, 13 Apr 2012 09:33:06 -0700 (PDT) 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=J2fwRC65NXKgXBV6QDoybrP0uwANnIf95Xj4qsa4fmY=; b=ba+rtGHka3dyj0J9tFt5MDX3dDb2AOcA1AE3ayL49NRjXflgeuzmD+FwE5Z8p/bpdE /jyf3XUJn4xiQ+NZdKqYj5LIJv+9p1XUgzWIEILn1N1d5/OBx7gdZ5nYIyZeMZTEZryZ 9zCP+Cu8PrvWINHDHwhH6Cg4TEth6rQDrAgIKGtE9PPHn27CacAuQKInMzRuhINmxRQM iMZpV1lYpp6sf1MV6msxjqQ18GKrzqtIRL0SzbecpIovmLHDAJUJg1ZduUYDYc8CGlaL ihhTcsGlzj33NGAgJlZEIV9jUuqOCmYdNDsJnkhUdm1Wf2mdZOIuIuXzhONSZLDEIbPX LZ3g== Received: by 10.204.133.216 with SMTP id g24mr656144bkt.104.1334334786216; Fri, 13 Apr 2012 09:33:06 -0700 (PDT) Received: from green.tandem.local (223-39-132-95.pool.ukrtel.net. [95.132.39.223]) by mx.google.com with ESMTPS id jr13sm17319734bkb.14.2012.04.13.09.33.02 (version=SSLv3 cipher=OTHER); Fri, 13 Apr 2012 09:33:05 -0700 (PDT) Message-ID: <4F88553B.5030005@gmail.com> Date: Fri, 13 Apr 2012 19:32:59 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Mark Schouten References: <4F8825E5.3040809@gmail.com> <1334323707.4f8829fbe801e@www.hyperdesktop.nl> In-Reply-To: <1334323707.4f8829fbe801e@www.hyperdesktop.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 13 Apr 2012 16:33:07 -0000 Mark Schouten wrote: > Hi, > > Op Vrijdag, 13-04-2012 om 15:11 schreef Volodymyr Kostyrko: >>> These are fiesystems that are created with the following command. >>> zfs create -V ${size}GB ${ZFS_ROOT}/${diskname} >> >> `zfs create -V` withous `-s` creates reserved volume that eats all >> needed space immediately. Technically zfs pool is filled only for 23%, >> but logically you have only 138G left unassigned. > > I understand. However, the created volumes should use a total of 1211GB. That's not 1.6TB like zfs list says. But 1211 + 431 (referred) does come close to 1.6TB.n And 1.6 TB still isn't the 1.77TB that's in the zpool. After reinventing calculator I'm just puzzled and shamed. This looks strange. Indeed not just a single byte from this files should count directly for the main filesystem. Just curious, what `ls -la /storage/' and `ls -la /storage/.zfs/s*` show? > > I have this feeling that zfs has reserved the space for each volume, but counts data written to the volumes in usage of the main filesystem. Mainly because zfs list shows me that the volumes have only 16KB referenced, where /storage has 431GB referenced. > -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 19:20: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 BB754106566B for ; Fri, 13 Apr 2012 19:20:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5798FC15 for ; Fri, 13 Apr 2012 19:20: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 q3DJKDvZ035949 for ; Fri, 13 Apr 2012 19:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3DJKDYo035948; Fri, 13 Apr 2012 19:20:13 GMT (envelope-from gnats) Date: Fri, 13 Apr 2012 19:20:13 GMT Message-Id: <201204131920.q3DJKDYo035948@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Patrick Proniewski Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Patrick Proniewski List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:20:13 -0000 The following reply was made to PR kern/156781; it has been noted by GNATS. From: Patrick Proniewski To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, Date: Fri, 13 Apr 2012 21:12:39 +0200 No sharing, nothing fancy, only ZFS and snapshot on a server. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 04:13:32 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 949C5106564A; Sat, 14 Apr 2012 04:13:32 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 048C98FC12; Sat, 14 Apr 2012 04:13:31 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id C3749D8D82; Sat, 14 Apr 2012 06:13:22 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Ut97wpc9CmkH; Sat, 14 Apr 2012 06:13:21 +0200 (CEST) Received: from [172.17.136.194] (adsl-66-120-169-242.dsl.sntc01.pacbell.net [66.120.169.242]) by smtp.semihalf.com (Postfix) with ESMTPSA id 82913D8D7C; Sat, 14 Apr 2012 06:13:20 +0200 (CEST) Message-ID: <4F88F966.5030300@semihalf.com> Date: Sat, 14 Apr 2012 06:13:26 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4F7A6A0B.5000308@semihalf.com> In-Reply-To: <4F7A6A0B.5000308@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: geom@FreeBSD.org, fs@FreeBSD.org Subject: Re: Review of projects/nand branch 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, 14 Apr 2012 04:13:32 -0000 Hi Marcel, Please find updated status of fixing bugs inlined. W dniu 2012-04-03 05:10, Grzegorz Bernacki pisze: > W dniu 2012-04-02 23:37, Marcel Moolenaar pisze: >> Grzegorz, >> >> I reviewed the changes on the projects/nand branch and in general >> it's of high quality and any problems, improvements and/or cleanups >> can be addressed after it gets merged into -current, with the >> following caveat: >> 1. Changes to sys/kern, sys/geom and sys/sys should be reviewed and >> approved by people on fs@freebsd.org and/or geom@freebsd.org. I >> saw comments from pjd already for example. Changes to geom has been reverted. We are working on remove rest of changes from sys/kern and sys/sys >> >> 2. Please address the following points before merging onto head: >> >> o In include/Makefile: fs/fifofs is removed. Deliberate? I applied incorrectly created patch. It was fixed with merge from HEAD. >> >> o In sbin/Makefile: we should have a distinct MK_NANDFS option >> for use by the file system code. - Is a separate MK_NANDFS knob really needed? Other filesystems don't seem to follow this route - The sys/fs/nandfs is only included per kernel config option, other userspace components per MK_NAND - Do you really think it is useful to have NAND framework built without NANDFS and vice versa, the FS without userland tools for it? >> o In sbin/nandfs/nandfs.8: could elaborate for what one could >> use the snapshots. Will be fixed >> o In sbin/nandfs/nandfs.h: define NANDFS_H. Fixed >> o In sbin/nandfs/nandfs.c: usage() is wrong. >> o In sbin/nandfs/Makefile: $FreeBSD$ is missing. Fixed >> o In sbin/mount_nandfs/mount_nandfs.8: copyright notice seems >> bogusly copied. Also, cleanerd is gone so it needs updating. >> o In sbin/mount_nandfs/mount_nandfs.c: cleanerd is gone, so >> this file could do with a some cleanups. >> o In sbin/mount_nandfs/Makefile: $FreeBSD$ is missing. mount_nandfs have been removed. >> o In sbin/mount/mntopts.h: cleanerd is gone, so should not be >> needed anymore. Fixed >> o In sbin/newfs_nandfs/newfs_nandfs.c: we have CRC32 code for >> re-use. No need to implement again. Will be fixed later. >> >> o In sbin/newfs_nandfs/Makefile: missing DPADD. Fixed >> >> o In share/mk/bsd.own.mk: Add NANDFS as well. May also want to >> add NANDSIM separately. >> o In share/man/man5/Makefile: should be NANDFS. Both above will be fixed soon. >> >> o In usr.sbin/nandtool/Makefile: missing $FreeBSD$ >> o In usr.sbin/nandsim/Makefile: missing $FreeBSD$ Both above are fixed >> o usr.sbin/Makefile should have nandtool and nandsim when >> MK_NAND is defined. >> o In lib/Makefile: should be MK_NANDFS; not MK_NAND. >> o In lib/libstand/nandfs.c: should use common CRC32 impl. >> o In lib/libstand/Makefile: should be MK_NANDFS; not MK_NAND. >> o Please get buy-in for changes to sys/kern/vfs_vnops.c, >> sys/kern/vfs_bio.c and sys/kern/vfs_subr.c from people >> on fs@freebsd.org. >> o In sys/modules/Makefile: always build nandfs module. Make >> nandsim module dependent on MK_NAND or MK_NANDSIM if added. All above will be fixed soon. >> >> o Please get buy-in for changes to sys/geom/geom_dev.c, >> sys/geom/geom_disk.c, sys/geom/geom_disk.h, sys/geom/geom.h >> and sys/geom/geom_slice.c from people on geom@freebsd.org. Geom changes has been removed. >> >> o Please get buy-in for changes to sys/sys/disk.h and >> sys/sys/bio.h from people on either fs@freebsd.org or >> geom@freebsd.org. Those changes has been removed. >> >> I also have a general usability question relating snapshots. >> Currently snapshots are read-only. A useful feature in the >> embedded space is to make a snapshot, attempt a software >> update and revert to the snapshot if and when the update fails >> or gets aborted. Is it possible to extend the snapshot feature >> in the future to allow for this use case (i.e. ignore any and >> all modifications that happened after a snapshot was made and >> mount the snapshot R/W as representing the current/latest state >> of the file system)? We are working on this. thanks, Grzesiek From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 15:38:06 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 845801065672; Sat, 14 Apr 2012 15:38:06 +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 6AF428FC0A; Sat, 14 Apr 2012 15:38:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA01007; Sat, 14 Apr 2012 18:37:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SJ52z-0008Ut-FB; Sat, 14 Apr 2012 18:37:57 +0300 Message-ID: <4F8999D2.1080902@FreeBSD.org> Date: Sat, 14 Apr 2012 18:37:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 14 Apr 2012 15:38:06 -0000 I would like to ask for a review and/or testing of the following three patches: http://people.freebsd.org/~avg/zfsboot.patches.diff These patches add support for booting from an arbitrary filesystem of any detected ZFS pool. A filesystem could be selected in zfsboot and thus will affectfrom where zfsloader would be loaded. zfsboot passes information about the boot pool and filesystem to zfsloader, which uses those for loaddev and default value of currdev. A different pool+filesystem could be selected in zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set and is not derived from fstab, then it gets set to the selected boot filesystem. This should could be used as a foundation for the support of Solaris-like boot environment selection. I believe that other people have already developed scripts utilizing ZFS capabilities to provide other aspects of management of boot environments. I am particularly interested in reviews of my attempt to make ZFS boot support arch-independent. The arches, of course, would have to add some code to make use of that support. Currently I only enabled it for x86. Thank you very much! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 15:44:38 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2006106566C; Sat, 14 Apr 2012 15:44:38 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6C00C8FC16; Sat, 14 Apr 2012 15:44:38 +0000 (UTC) Received: from dhcp-192-168-2-14.wifi.xcllnt.net (atm.xcllnt.net [70.36.220.6]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q3EFiRom057697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 14 Apr 2012 08:44:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <4F88F966.5030300@semihalf.com> Date: Sat, 14 Apr 2012 08:44:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7A6A0B.5000308@semihalf.com> <4F88F966.5030300@semihalf.com> To: Grzegorz Bernacki X-Mailer: Apple Mail (2.1257) Cc: geom@FreeBSD.org, fs@FreeBSD.org Subject: Re: Review of projects/nand branch 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, 14 Apr 2012 15:44:38 -0000 On Apr 13, 2012, at 9:13 PM, Grzegorz Bernacki wrote: Hi Gregorz, It was good to finally meet you! >>> o In sbin/Makefile: we should have a distinct MK_NANDFS option >>> for use by the file system code. >=20 > - Is a separate MK_NANDFS knob really needed? Other filesystems don't = seem to > follow this route > - The sys/fs/nandfs is only included per kernel config option, other = userspace > components per MK_NAND > - Do you really think it is useful to have NAND framework built = without NANDFS > and vice versa, the FS without userland tools for it? I don't think it's *really* needed per se, but since nandfs is a useful file system on any kind of storage media, I can see that people may want the file system, but not the NAND framework bits. I thought that keeping the distinction between the 2 (as we do in the kernel with "options NANDFS" and "device nand") is probably a good thing. I leave it up to you. It's not of any real significance either way... Thanks for taking care of all the review comments! Cheers, --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 17:35:40 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 2A301106566C; Sat, 14 Apr 2012 17:35:40 +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 116B28FC0A; Sat, 14 Apr 2012 17:35:38 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA01605; Sat, 14 Apr 2012 20:35:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SJ6sr-0008br-8i; Sat, 14 Apr 2012 20:35:37 +0300 Message-ID: <4F89B567.6090008@FreeBSD.org> Date: Sat, 14 Apr 2012 20:35:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4F8999D2.1080902@FreeBSD.org> In-Reply-To: <4F8999D2.1080902@FreeBSD.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 14 Apr 2012 17:35:40 -0000 on 14/04/2012 18:37 Andriy Gapon said the following: > > I would like to ask for a review and/or testing of the following three patches: > http://people.freebsd.org/~avg/zfsboot.patches.diff > > These patches add support for booting from an arbitrary filesystem of any > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > affectfrom where zfsloader would be loaded. zfsboot passes information about > the boot pool and filesystem to zfsloader, which uses those for loaddev and > default value of currdev. A different pool+filesystem could be selected in > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > and is not derived from fstab, then it gets set to the selected boot filesystem. A note for prospective testers: the patched loader expect to be started by the patched zfs boot as it passes an additional parameter for a filesystem guid. I should probably add some way to distinguish between the older and newer zfs boot blocks. Maybe an extra bit in bootflags? What do you think? > This should could be used as a foundation for the support of Solaris-like boot > environment selection. I believe that other people have already developed > scripts utilizing ZFS capabilities to provide other aspects of management of > boot environments. > > I am particularly interested in reviews of my attempt to make ZFS boot support > arch-independent. The arches, of course, would have to add some code to make > use of that support. Currently I only enabled it for x86. > > Thank you very much! -- Andriy Gapon