From owner-freebsd-fs@FreeBSD.ORG Mon Feb 10 04:26:35 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 28D057AF; Mon, 10 Feb 2014 04:26:35 +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 F17D81D11; Mon, 10 Feb 2014 04:26:34 +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 s1A4QYmf037541; Mon, 10 Feb 2014 04:26:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1A4QYln037540; Mon, 10 Feb 2014 04:26:34 GMT (envelope-from linimon) Date: Mon, 10 Feb 2014 04:26:34 GMT Message-Id: <201402100426.s1A4QYln037540@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/186574: [zfs] zpool history hangs (infinite loop) 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, 10 Feb 2014 04:26:35 -0000 Old Synopsis: zpool history hangs (infinite loop) New Synopsis: [zfs] zpool history hangs (infinite loop) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 10 04:26:16 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=186574 From owner-freebsd-fs@FreeBSD.ORG Mon Feb 10 11:06: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 70D0BEC for ; Mon, 10 Feb 2014 11:06:46 +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 4FB781FD1 for ; Mon, 10 Feb 2014 11:06:46 +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 s1AB6kdl080027 for ; Mon, 10 Feb 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1AB6jYU080025 for freebsd-fs@FreeBSD.org; Mon, 10 Feb 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Feb 2014 11:06:45 GMT Message-Id: <201402101106.s1AB6jYU080025@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, 10 Feb 2014 11:06:46 -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/186574 fs [zfs] zpool history hangs (infinite loop) o kern/186515 fs [gptboot] Doesn't boot with GPT when # of entries over o kern/185858 fs [zfs] zvol clone can't see new device 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 337 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 10 19:30:01 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 23DD3899 for ; Mon, 10 Feb 2014 19:30:01 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC4481F88 for ; Mon, 10 Feb 2014 19:30:00 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so6597541pab.32 for ; Mon, 10 Feb 2014 11:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=y6ZtYdgxiNPkjwA2g6iGXyDKUsZeytmQs+1u0TagVMk=; b=IAZKekKbvKBPIfzX9CThJNyqTcFxKD2s40dPhzNZgydF2Cqxy+95vq/1n0fij64kub ElVYvAO9WQrctV+fA4LBJQq5vK03IE9G24foBUEpYHjioCd0ysO4xXfv7lbbBbfFFNJ5 eSwZT3NeOxMUt9itg74+qTCafIbMioFw5WeWMRRfsaDKYicsl5G8Vy8bNuA6gSIUJPdg LmXbwSX5LJtrJ0DaY4j277QWn6XUMkbUUBUHgGxaMgjY/81+kMxXa2JP0XBMo5NJdAWV K9QAt88onkKXNvSPnZLlPmxHEjCn4epSr0imAQsW7vATfM71sgfw5ry1J8NOChdsWbfW FxjQ== MIME-Version: 1.0 X-Received: by 10.66.65.204 with SMTP id z12mr27368992pas.60.1392060600582; Mon, 10 Feb 2014 11:30:00 -0800 (PST) Sender: dan.uber@gmail.com Received: by 10.68.144.167 with HTTP; Mon, 10 Feb 2014 11:30:00 -0800 (PST) Date: Mon, 10 Feb 2014 14:30:00 -0500 X-Google-Sender-Auth: YtU788uePNlJhycfwtJb0XOZFFY Message-ID: Subject: Greetings Noble BSD Gods From: Dan Uber To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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, 10 Feb 2014 19:30:01 -0000 I am but a simple mortal respectfully inquiring about the future potential of the ZFS spacemap_histogram feature offering write support. I have a 30TB array that was spawned in FreeNAS (foolish mistake, yes, I know) that I would really love to migrate to FreeBSD 10, but I'm getting the following when I try to import it. root@Galaxy:/home/ub3r # zpool import Galaxy This pool uses the following feature(s) not supported by this system: com.delphix:spacemap_histogram (Spacemaps maintain space histograms.) All unsupported features are only required for writing to the pool. The pool can be imported using '-o readonly=on'. cannot import 'Galaxy': unsupported version or feature At first I thought this might be something easy to implement myself, then I was informed that only the FreeBSD-FS Overlords are capable of dabbling in such witchcraft. Thank you for your time, I greatly appreciate it. Take care, -Dan Uber From owner-freebsd-fs@FreeBSD.ORG Mon Feb 10 19:40:12 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 378DBB2F for ; Mon, 10 Feb 2014 19:40:12 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 069E410BA for ; Mon, 10 Feb 2014 19:40:11 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 448BC20F52 for ; Mon, 10 Feb 2014 14:40:10 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Mon, 10 Feb 2014 14:40:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=/uabMzetIX3rZMQ0n2ZqiqbRDpg=; b=shA g9w5I06C8YjtyhRE9Kl3NTHcW5C+QKdIdvKeIHbUhBrPNysdCfh+fScIPCTGPMuw Nsv8JW++zArCvVck2wkwS3vZtzCMisR1ZrdiweaNNYVOdsteEgsAfGzGuc//RVc5 pQrsebSDQytI4VYRE21kt/473dKEcKf+gIKZXkgw= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 1CCEF114717; Mon, 10 Feb 2014 14:40:10 -0500 (EST) Message-Id: <1392061210.4086.81684261.0AED389C@webmail.messagingengine.com> X-Sasl-Enc: SQnaIORZepO20BftqnyLkQIt/cjky84XYZtDTDPexz38 1392061210 From: Mark Felder To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-e72899be In-Reply-To: References: Subject: Re: Greetings Noble BSD Gods Date: Mon, 10 Feb 2014 13:40:10 -0600 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, 10 Feb 2014 19:40:12 -0000 On Mon, Feb 10, 2014, at 13:30, Dan Uber wrote: > I am but a simple mortal respectfully inquiring about the future > potential > of the ZFS spacemap_histogram feature offering write support. > > I have a 30TB array that was spawned in FreeNAS (foolish mistake, yes, I > know) that I would really love to migrate to FreeBSD 10, but I'm getting > the following when I try to import it. > > root@Galaxy:/home/ub3r # zpool import Galaxy > This pool uses the following feature(s) not supported by this system: > com.delphix:spacemap_histogram (Spacemaps maintain space > histograms.) > All unsupported features are only required for writing to the pool. > The pool can be imported using '-o readonly=on'. > cannot import 'Galaxy': unsupported version or feature > > At first I thought this might be something easy to implement myself, then > I > was informed that only the FreeBSD-FS Overlords are capable of dabbling > in > such witchcraft. > > Thank you for your time, I greatly appreciate it. > Did FreeNAS patch in spacemap_histogram before we did? I'm aware it exists in head/CURRENT, but didn't notice until now that it's missing from FreeBSD 10. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 10 19:41:42 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 8FA47BAC for ; Mon, 10 Feb 2014 19:41:42 +0000 (UTC) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BA391120 for ; Mon, 10 Feb 2014 19:41:41 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id 226161076; Mon, 10 Feb 2014 20:41:38 +0100 (CET) Date: Mon, 10 Feb 2014 20:41:38 +0100 From: Michael Moll To: Dan Uber Subject: Re: Greetings Noble BSD Gods Message-ID: <20140210194138.GA51697@darkthrone.kvedulv.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) 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: Mon, 10 Feb 2014 19:41:42 -0000 Hi, On Mon, Feb 10, 2014 at 02:30:00PM -0500, Dan Uber wrote: > This pool uses the following feature(s) not supported by this system: > com.delphix:spacemap_histogram (Spacemaps maintain space > histograms.) Seems like r258717 was not MFCed. Regards -- Michael Moll From owner-freebsd-fs@FreeBSD.ORG Mon Feb 10 23:33:57 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 51BF6B21 for ; Mon, 10 Feb 2014 23:33:57 +0000 (UTC) Received: from mail.umail29.cn4e.com (umail29.cn4e.com [219.239.95.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBBB1693 for ; Mon, 10 Feb 2014 23:33:55 +0000 (UTC) Received: from smail56.cn4e.com (smail56.cn4e.com [118.244.197.56]) by mail.umail29.cn4e.com (Postfix) with ESMTP id 195BE190896 for ; Tue, 11 Feb 2014 07:19:31 +0800 (CST) X-Bordeaux-Score: 350 X-Spam-Flag: NO Received: from norrtuv([118.228.151.153]) by smail56.cn4e.com(4.4.0.3a) with ESMTP id 5E2400010004.89.1392074360.780857; Tue, 11 Feb 2014 07:19:20 +0800 (CST) X-BQId: 5E2400010004.89.1392074360.780857.6 X-Bordeaux-Type: AUTHSMTP X-35BMId: 5E2400010004.89.1392074360.780857.6 X-Bordeaux-LOG: SA: TSMF, 3-350-1-83886080,3-350-1-83886080,3-350-1-83886080 eJzt3L1u01AYgOEssPAzcQEeYajl/DVpVKGEEmjVtC5pkJiQTmMHrDp2ajtRQP27UO6AK4CJBHw EOG1Ph9Su4veRrNPBw7d9PXmVPCj8Mf34o/vvuWXu77e3elqxWNdLpbperBZnT7mAfPh2i3fCoX Dc6rre9yq23veHWvtwr3egvfIDyxbjabNcfV7RK7qhl8WLOx8YQOoexueXeG+cxmd7u2Nqnh8E0 XiS2XDIzM9bvGMe3/kYAO6xR/F5mtgfrfe9ba1jvt3Zz2w0ZOj77CnpNd244Z3WOPpse5HTF5Hj e1o47vftMByMXS2lIQFk6ll8JvdH97Ddy2woZI77BwCVx/GZ3B97rZ2O9qZr7jU2Q+HaxkZzFDh eZAd93/UDN7LmH3i/zGxs3LH5/hCz+8Qouv6dkmEYpdQmAnDfPInPhfvH1kFP65mNTccb+M0ocE TkhPrQYmXkw3x/dLca7Q833ELNXc2ezv6l8ISrzVP6kT9NbT4A2Xsan3JvnMXn61avldlQyNzv/ dFpvDN3r3/nZGyPbUsToVZtlyqzy0hx9lT0+oZeLG+UjFqlvG7otbpRr9b0YmqTA0iL7B9nif1B /8g3+gcAFdk/kvuD/pFv9A8AKrJ/LNw/ZP/4Kpqh7+jhMcsiT+gfAFRk/0juD/pHvi27f3BPAVa P7B/n8d44p3+gQP8AoCb7R3J/0D/yjf4BQEX2j4X7h+wfoR1MnLBpn5BA8oT+AUBF9o/k/qB/5N uy+we/3AysHtk/LuK9cUH/QIH+AUBN9o/k/qB/5Bv9A4CK7B8L94//fv9q6LuWPxFrYuL3RcTqW H30DwAqsn8k9wf9I9+W3T8qqU0OIC30D1yF/gFARfaPy3hvXNI/UKB/AFCT/SO5P/5+/2O2PcJm KEZjz3I8V4wi27L7YhQINsgKo38AUJH9I7k/6B/5tuz+UU1tcgBpkf1j4f5B/8g1+gcAFfoHrkL /AKCi7B+DwLaPQmttEDbjP3U/+MTmWHH0DwAqvwBlNtSm X-Bordeaux-Detail: eJxzsrIKjgwOcfW1snIGI0MDYysrEyA2NeByQkh6QCQNDa2sLMytrIwNUGSByNHKysjAwMAIKGd lpZFXmpOjiawCqNkPZDgQAClzbEpGDaGiIQAK0ncF X-Bordeaux-Action-libantispam.so: Action: Relay[NEXT,10000,350:350:350] X-Bordeaux-Action-libspamsa.so: X-Bordeaux-Action-libclamav.so: X-Bordeaux-Action-libsmtpext.so: X-Bordeaux-Action-libpwdrate.so: Date: Tue, 11 Feb 2014 07:19:38 +0800 From: "NPC toner chip" To: "freebsd-fs" Subject: Samsung? SCX3400/3405/3405F/3405FW/3407 Message-ID: <201402110719388679011@printercolorltd.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sherry@printercolorltd.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:33:57 -0000 Hi!Dear , Happy new year!And wish your family and you all the best in 2014! I have some new chips for you,Please check our new price list attached: SAMSUNG MLT-D111S M2020/2020W, M2022/2022W, M2070/2070W, Riso ComColor 3010, 3050, 7010, 7050, 9050 Risograph ComColor 3010, 3050, 7010, 7050, 9050 Ricoh Aficio SP 100 100 E, 100SF SP100LA HP CE350A CE351A CE352A CE353A SAMSUNG MLT-R116 DRUM CHIPS SAMSUNG MLT-R204 DRUM CHIPS LEXMARK C746/C748 LEXMARK C935 LEXMARK C734 Lexmark t650 LEXMARK E360 LEXMARK E460 Lexmark E260 oki2731 OKI es3640 OKI C801/c821 OKI C610 OKI B710/B720/B730 Samsung MLT-D111S SAMSUNG MLT-D115L SAMSUNG MLT-D116L SAMSUNG MLT- D203 SAMSUNG MLT-D204 <-layout-grid-align: auto" class="MsoNormal"> our company has passed the certification of the ISO14001 and ISO9001!Please check our certification below! And our quality guarantee is for 12monthes with 100% replacement and return if there is any quality problem!You can check more certification about us on [1]www.toner-cartridge-chip.com.cn If you have any question,please let me know! best wishes! yours, Sherry Sales Manager Company:NPC, Nanchang Printer Color Technology Co., LtD Address: Room 602,Unit 1,Building 3,Hongcheng Road No.589,Nanchang City,Jiangxi province ,China Tel:86-0791-86207670 Fax:86-0791-86207670 Mobile:0086-13576261899 Post code:330046 MSN: [2]sherry@printercolorltd.com,admin@printercolorltd.com Skype:sherryhuang000001 Email: [3]sherry@printercolorltd.com,admin@printercolorltd.com, Web:http://printercolorltd.en.alibaba.com/ [4]http://www.printercolorltd.com [5]www.toner-cartridge-chip.com.cn online shop:http://www.aliexpress.com/store/401088 my Facebook address:https://www.facebook.com/npctonerchip CERTIFICATE:http://www.toner-cartridge-chip.com.cn/column/208392025/Cer tificates.html golden member:http://en.trade2cn.com/companyShop/11090211243708n.html;jsession id=D66F7EB010C669C88801D1AF46803D3B 03108068171/8068198 [6]https://twitter.com/NPCtonerchips [%Date][%Time][%FromEmail][%FromName][%FromName][%Email][%LastName][%Fi rstName][%FullName][%NickName][%Company][%Tel][%HomePage][%Other1][%Oth er2][%Other3][%Other4][%Other5][%Other3][%Other4][%Other5][%Other6][%Ot her7][%Other8][%Other9][%Other10] [MA_MailStatus.html?method=update&mid=5E2400010004.89.1392074360.780857 .6&from=sale09@printercolorltd.com&to=freebsd-fs@freebsd.org&serverdoma in=smail56.cn4e.com&status=read] References 1. http://www.toner-cartridge-chip.com.cn/ 2. mailto:sherry@printercolorltd.com,admin@printercolorltd.com 3. mailto:sherry@printercolorltd.com,admin@printercolorltd.com 4. http://www.printercolorltd.com/ 5. http://www.toner-cartridge-chip.com.cn/ 6. https://twitter.com/NPCtonerchips From owner-freebsd-fs@FreeBSD.ORG Fri Feb 14 11:53:51 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 9CBAF522; Fri, 14 Feb 2014 11:53:51 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BB9A01E41; Fri, 14 Feb 2014 11:53:47 +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 NAA13111; Fri, 14 Feb 2014 13:53:46 +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 1WEHKz-000NeT-V3; Fri, 14 Feb 2014 13:53:45 +0200 Message-ID: <52FE0378.7070608@FreeBSD.org> Date: Fri, 14 Feb 2014 13:52:24 +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: freebsd-fs Subject: Re: l2arc_feed_thread cpu utlization References: <52B2D8D6.8090306@FreeBSD.org> In-Reply-To: <52B2D8D6.8090306@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=x-viet-vps 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: Fri, 14 Feb 2014 11:53:51 -0000 on 19/12/2013 13:30 Andriy Gapon said the following: > > This is just a heads up, no patch yet. > > l2arc_feed_thread periodically wakes up and scans certain amount of ARC buffers > and writes eligible buffers to a cache device. > Number of scanned buffers is limited by a threshold on the amount of data in the > buffers seen. The threshold is applied on a per buffer list basis. In upstream > there are 4 relevant lists: (data, metadata) X (MFU, MRU). In FreeBSD each of > the lists was subdivided into 16 lists. This was done to reduce contention on > the locks that protect the lists. But as a side effect l2arc_feed_thread can > scan 16 times more data (~ buffers). > > So, if you have a rather large ARC and L2ARC and your buffers tend to be > sufficiently small, then you could observe l2arc_feed_thread burning a > noticeable amount of CPU. On some of our systems I observed it using up to 40% > of a single core. Scaling back the threshold by factor of 16 makes CPU > utilization go down by the same factor. > > I plan to commit this change to FreeBSD ZFS code. > Any comments are welcome. Here is what I have in mind: https://github.com/avg-I/freebsd/compare/wip;hc;l2arc_feed_thread_scan_rate The calculations in the macro look somewhat ugly, but they should be correct :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Feb 14 18:53:05 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 3C1F3C6E for ; Fri, 14 Feb 2014 18:53:05 +0000 (UTC) Received: from internet06.ebureau.com (internet06.ebureau.com [65.127.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 14ADF1A13 for ; Fri, 14 Feb 2014 18:53:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by internet06.ebureau.com (Postfix) with ESMTP id 88578A81900 for ; Fri, 14 Feb 2014 12:52:58 -0600 (CST) X-Virus-Scanned: amavisd-new at ebureau.com Received: from internet06.ebureau.com ([127.0.0.1]) by localhost (internet06.ebureau.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujf62jCyJ-7f for ; Fri, 14 Feb 2014 12:52:58 -0600 (CST) Received: from nail.office.ebureau.com (nail.office.ebureau.com [10.10.20.23]) by internet06.ebureau.com (Postfix) with ESMTPSA id 44BECA818F5 for ; Fri, 14 Feb 2014 12:52:58 -0600 (CST) From: Joe Moog Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Unable to clear a stuck device Message-Id: <537EE1DF-CDA1-4A08-A963-D312E104725E@ebureau.com> Date: Fri, 14 Feb 2014 12:52:58 -0600 To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) 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, 14 Feb 2014 18:53:05 -0000 We have a FreeBSD host (FreeBSD 9.1-PRERELEASE #0 r244125) configured = with a few ZFS storage volumes. Recently we attached an external volume = to the host, created a GELI-encrypted ZFS volume, and copied some data = to it. When completed, the device was not disconnected properly. Now, = any ZFS/zpool commands that attempt to touch that missing device are = left hanging in perpetuity on the host because it seems to think it can = still access the volume when in fact it cannot. This is not affecting = any other functions of the host besides a few scripts that are intended = to check the health of the attached volumes. Is there any way to clear the apparent presence of this missing device? = We tried to re-attach the volume and perform the necessary ZFS = export/import, but these commands now hang as well (the -f option has no = effect). No doubt a reboot would take care of it, but there are some = functions running on this host that we do not wish to interrupt, if at = all possible. Can anybody make a recommendation? Thanks Joe From owner-freebsd-fs@FreeBSD.ORG Fri Feb 14 20:23:27 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 AFA71983 for ; Fri, 14 Feb 2014 20:23:27 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8442F12E2 for ; Fri, 14 Feb 2014 20:23:27 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id rd3so12646602pab.5 for ; Fri, 14 Feb 2014 12:23:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=llOyIgKR6Wr/RDZCzBTBVNVgq0HJ8OpWDTWzMm/pXHA=; b=aHJm7+Jjojkhk4peoVGuXuUgJ3iw7Cs/gNyO2SbCDHKcriHV30xVEFyAjn0pE7Mql+ dLZqxLvFKffzeth9vKRecZDZKHE/4gZiZpYFP9J2QpxcUJN3gxn1/gWIsHXhCP0UG0yO LqFJqPtX33DyNkV0IzDyCHsDo31RKMZh1Sq/pkeZu+HlZylcmOtrXYUKWoxS9xOZd0me S3j2wl/7inOYyMG9Gq//4kVtIuJ7yciFfEtNGMN07esuiXPz9MEpQF/tfDIPEmvmYRIT 9GxnJ+Es9IwPIE3jqvbcfUEZOHh81SE+vI/iKJXJcXwb7kNEFyYV5eWqoe02Gr2/zmt7 53vA== X-Gm-Message-State: ALoCoQkjsW4fz+xUSenJnma/zmoMTyQGZFTmJp4rl1RKoy3jTmMdihUHupukXP8Y5mg1VA85sl66 MIME-Version: 1.0 X-Received: by 10.69.1.2 with SMTP id bc2mr11355305pbd.102.1392409400845; Fri, 14 Feb 2014 12:23:20 -0800 (PST) Received: by 10.70.44.165 with HTTP; Fri, 14 Feb 2014 12:23:20 -0800 (PST) In-Reply-To: <52FE0378.7070608@FreeBSD.org> References: <52B2D8D6.8090306@FreeBSD.org> <52FE0378.7070608@FreeBSD.org> Date: Fri, 14 Feb 2014 12:23:20 -0800 Message-ID: Subject: Re: l2arc_feed_thread cpu utlization From: Brendan Gregg To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-fs 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, 14 Feb 2014 20:23:27 -0000 G'Day Andriy, Thanks for the patch. If most of the data is in one list (anyone have statistics to confirm such a likelyhood? I know this happened a lot pre-list-split), then I think this means we only scan that at 1/32nd of the previous rate. It should solve the CPU issue, but could make warmup very slow. I think the feed algorithm needs to be rethought, although that can be done as future work. I'm trying to think of what simple that can be done right now to solve CPU usage and warmup rate. Lets say we keep this change, but in l2arc_write_buffers we maintain an extra copy of write_sz, say, list_write_sz, that is reset to zero for each list. Then, when we reach headroom and choose to abort, we can check list_write_sz and determine how fruitful the scanning has been so far. If that's greater than a threshold, then keep scanning, up to the full L2ARC_WRITE_SIZE for that list. That way, we've scanned only 1/32nd of the previous length as a test, and only if that is fruitful enough do we keep scanning. Again, it probably needs to be rethought, but something like that may work fine in the meantime. Brendan On Fri, Feb 14, 2014 at 3:52 AM, Andriy Gapon wrote: > on 19/12/2013 13:30 Andriy Gapon said the following: > > > > This is just a heads up, no patch yet. > > > > l2arc_feed_thread periodically wakes up and scans certain amount of ARC > buffers > > and writes eligible buffers to a cache device. > > Number of scanned buffers is limited by a threshold on the amount of > data in the > > buffers seen. The threshold is applied on a per buffer list basis. In > upstream > > there are 4 relevant lists: (data, metadata) X (MFU, MRU). In FreeBSD > each of > > the lists was subdivided into 16 lists. This was done to reduce > contention on > > the locks that protect the lists. But as a side effect > l2arc_feed_thread can > > scan 16 times more data (~ buffers). > > > > So, if you have a rather large ARC and L2ARC and your buffers tend to be > > sufficiently small, then you could observe l2arc_feed_thread burning a > > noticeable amount of CPU. On some of our systems I observed it using up > to 40% > > of a single core. Scaling back the threshold by factor of 16 makes CPU > > utilization go down by the same factor. > > > > I plan to commit this change to FreeBSD ZFS code. > > Any comments are welcome. > > Here is what I have in mind: > https://github.com/avg-I/freebsd/compare/wip;hc;l2arc_feed_thread_scan_rate > > The calculations in the macro look somewhat ugly, but they should be > correct :-) > > -- > Andriy Gapon > > _______________________________________________ > 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" > -- Brendan Gregg, Joyent http://dtrace.org/blogs/brendan From owner-freebsd-fs@FreeBSD.ORG Sat Feb 15 11:59: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 92776A94 for ; Sat, 15 Feb 2014 11:59:43 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E6E9310AC for ; Sat, 15 Feb 2014 11:59:42 +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 NAA28771; Sat, 15 Feb 2014 13:59:33 +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 1WEdu9-0002nG-73; Sat, 15 Feb 2014 13:59:33 +0200 Message-ID: <52FF566D.3060601@FreeBSD.org> Date: Sat, 15 Feb 2014 13:58:37 +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: Brendan Gregg Subject: Re: l2arc_feed_thread cpu utlization References: <52B2D8D6.8090306@FreeBSD.org> <52FE0378.7070608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs 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: Sat, 15 Feb 2014 11:59:43 -0000 on 14/02/2014 22:23 Brendan Gregg said the following: > G'Day Andriy, > > Thanks for the patch. If most of the data is in one list (anyone have statistics > to confirm such a likelyhood? I know this happened a lot pre-list-split), then I > think this means we only scan that at 1/32nd of the previous rate. It should > solve the CPU issue, but could make warmup very slow. Brendan, I do not have any stats, but I think that the data should be spread more or less evenly between the lists. I mean the 16 sub-lists for data and 16 sub-lists for metadata. First, a list is picked up based on hash and that _should_ produce more or less even distribution. Second, if the hash funciton is not good enough then whole list splitting is pointless. In either case this was just a quick hack on my part. > I think the feed algorithm needs to be rethought, although that can be done as > future work. I'm trying to think of what simple that can be done right now to > solve CPU usage and warmup rate. I completely agree with you. I do not particularly like the fact that the threshold is per sub-list in FreeBSD. I would prefer a more "wholisitic" threshold. > Lets say we keep this change, but in l2arc_write_buffers we maintain an extra > copy of write_sz, say, list_write_sz, that is reset to zero for each list. Then, > when we reach headroom and choose to abort, we can check list_write_sz and > determine how fruitful the scanning has been so far. If that's greater than a > threshold, then keep scanning, up to the full L2ARC_WRITE_SIZE for that list. > That way, we've scanned only 1/32nd of the previous length as a test, and only > if that is fruitful enough do we keep scanning. > > Again, it probably needs to be rethought, but something like that may work fine > in the meantime. This sounds interesting. I will think more about this. Thanks! > > On Fri, Feb 14, 2014 at 3:52 AM, Andriy Gapon > wrote: > > on 19/12/2013 13:30 Andriy Gapon said the following: > > > > This is just a heads up, no patch yet. > > > > l2arc_feed_thread periodically wakes up and scans certain amount of ARC > buffers > > and writes eligible buffers to a cache device. > > Number of scanned buffers is limited by a threshold on the amount of data > in the > > buffers seen. The threshold is applied on a per buffer list basis. In > upstream > > there are 4 relevant lists: (data, metadata) X (MFU, MRU). In FreeBSD each of > > the lists was subdivided into 16 lists. This was done to reduce contention on > > the locks that protect the lists. But as a side effect l2arc_feed_thread can > > scan 16 times more data (~ buffers). > > > > So, if you have a rather large ARC and L2ARC and your buffers tend to be > > sufficiently small, then you could observe l2arc_feed_thread burning a > > noticeable amount of CPU. On some of our systems I observed it using up > to 40% > > of a single core. Scaling back the threshold by factor of 16 makes CPU > > utilization go down by the same factor. > > > > I plan to commit this change to FreeBSD ZFS code. > > Any comments are welcome. > > Here is what I have in mind: > https://github.com/avg-I/freebsd/compare/wip;hc;l2arc_feed_thread_scan_rate > > The calculations in the macro look somewhat ugly, but they should be correct :-) > > -- > Andriy Gapon > > _______________________________________________ > 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 > " > > > > > -- > Brendan Gregg, Joyent http://dtrace.org/blogs/brendan -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Feb 15 20:22:10 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 DFAAE355 for ; Sat, 15 Feb 2014 20:22:09 +0000 (UTC) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B19231683 for ; Sat, 15 Feb 2014 20:22:09 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id w10so13260067pde.21 for ; Sat, 15 Feb 2014 12:22:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pDp+tN5MEa3JGD/kqHY3HyQ31anyAdbjqV8CyEAQ5Gw=; b=hzeG7jbUc4hPmAiIYAOCTZ7UtQCuyf+9bokl6xBdDdrXEzGhqGVMqTHFGldjSicleo QjCgqkHqimghIq6ppwVEt6F+EzD6LHuvinTiVEzZGkhq5WEAbm4TAbD+U/PIuyy9rSaZ 74yX/o03SRtsTEdd2sneWNMKv62fV59KHHyCsP7eDw1MF3E8/u1iYJ/kUwdjIXL78u32 gOwP0IdxujUSoOMDapcClvdbx87AQQ2BrlfGhlS48a+6POp46kAgQs5cbYBwoKdMCsp0 tOdJbcmeM3A/K2RpEhEUsy5V+kre72RYpcseZKhnKbrNwFbtqwK8aP7zJ0PwyZaR7iyo ObdQ== X-Gm-Message-State: ALoCoQkzTNi5QL6JVGQD7D+Qn/LP4+DaZsG/8+Apkd2oUCRupaJAjWQ8N9AoXxk7sg3uxT5TRDBI MIME-Version: 1.0 X-Received: by 10.67.22.100 with SMTP id hr4mr16897679pad.112.1392495723377; Sat, 15 Feb 2014 12:22:03 -0800 (PST) Received: by 10.70.44.165 with HTTP; Sat, 15 Feb 2014 12:22:03 -0800 (PST) In-Reply-To: <52FF566D.3060601@FreeBSD.org> References: <52B2D8D6.8090306@FreeBSD.org> <52FE0378.7070608@FreeBSD.org> <52FF566D.3060601@FreeBSD.org> Date: Sat, 15 Feb 2014 12:22:03 -0800 Message-ID: Subject: Re: l2arc_feed_thread cpu utlization From: Brendan Gregg To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-fs 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: Sat, 15 Feb 2014 20:22:10 -0000 G'Day Andriy, On Sat, Feb 15, 2014 at 3:58 AM, Andriy Gapon wrote: > on 14/02/2014 22:23 Brendan Gregg said the following: > > G'Day Andriy, > > > > Thanks for the patch. If most of the data is in one list (anyone have > statistics > > to confirm such a likelyhood? I know this happened a lot > pre-list-split), then I > > think this means we only scan that at 1/32nd of the previous rate. It > should > > solve the CPU issue, but could make warmup very slow. > > Brendan, > > I do not have any stats, but I think that the data should be spread more > or less > evenly between the lists. I mean the 16 sub-lists for data and 16 > sub-lists for > metadata. First, a list is picked up based on hash and that _should_ > produce > more or less even distribution. Second, if the hash funciton is not good > enough > then whole list splitting is pointless. > In either case this was just a quick hack on my part. > Ah, I'm sorry, I should have read more of the code earlier; I had assumed the split algorithm was something else, and I'm wrong. It should be even. So, based on get_buf_info(), I think we can DTrace how buf_hash() is mapped to the lists to get an idea of the distribution. Eg (on illumos, which has the same buf_hash() code): # dtrace -n 'fbt::buf_hash:return { @ = lquantize(arg1 & (32 - 1), 0, 32, 1); } tick-30s { exit(0); }' dtrace: description 'fbt::buf_hash:return ' matched 2 probes CPU ID FUNCTION:NAME 7 30 :tick-30s value ------------- Distribution ------------- count < 0 | 0 0 |@@ 20581 1 |@ 12578 2 |@ 6004 3 |@@ 15215 4 |@ 4660 5 | 2952 6 | 3678 7 |@@ 14091 8 | 2402 9 |@@ 20998 10 |@ 5805 11 |@ 6564 12 |@@@@ 35560 13 |@ 13021 14 | 4348 15 |@@ 17035 16 |@@ 15406 17 |@ 5512 18 |@ 13222 19 |@ 5488 20 |@ 5404 21 |@@ 13583 22 |@ 7453 23 |@ 4794 24 | 3738 25 |@@@ 24918 26 |@@ 15566 27 |@ 5324 28 |@ 12112 29 |@@ 13966 30 |@@ 16668 31 |@ 9904 >= 32 | 0 So that looks reasonably even - every bucket is in use. I think your patch should be good. Brendan -- Brendan Gregg, Joyent http://dtrace.org/blogs/brendan