From owner-freebsd-fs@FreeBSD.ORG Sun Feb 16 23:55:20 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 6E162B54; Sun, 16 Feb 2014 23:55:20 +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 401931A95; Sun, 16 Feb 2014 23:55:20 +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 s1GNtKqZ085379; Sun, 16 Feb 2014 23:55:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1GNtK68085378; Sun, 16 Feb 2014 23:55:20 GMT (envelope-from linimon) Date: Sun, 16 Feb 2014 23:55:20 GMT Message-Id: <201402162355.s1GNtK68085378@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/186645: [fusefs] Crash after unmounting wdfs 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: Sun, 16 Feb 2014 23:55:20 -0000 Old Synopsis: Crash after unmounting wdfs New Synopsis: [fusefs] Crash after unmounting wdfs Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 16 23:54:39 UTC 2014 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=186645 From owner-freebsd-fs@FreeBSD.ORG Sun Feb 16 23:55:58 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 D094FC0B; Sun, 16 Feb 2014 23:55:58 +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 A4CAD1AA8; Sun, 16 Feb 2014 23:55:58 +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 s1GNtwM2085433; Sun, 16 Feb 2014 23:55:58 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1GNtw6K085432; Sun, 16 Feb 2014 23:55:58 GMT (envelope-from linimon) Date: Sun, 16 Feb 2014 23:55:58 GMT Message-Id: <201402162355.s1GNtw6K085432@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/185963: [zfs] Kernel crash trying to import a damaged ZFS pool 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: Sun, 16 Feb 2014 23:55:58 -0000 Old Synopsis: Kernel crash trying to import a damaged ZFS pool New Synopsis: [zfs] Kernel crash trying to import a damaged ZFS pool Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 16 23:55:38 UTC 2014 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=185963 From owner-freebsd-fs@FreeBSD.ORG Mon Feb 17 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 98FAED22 for ; Mon, 17 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 7AF3511B4 for ; Mon, 17 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 s1HB6k3b033022 for ; Mon, 17 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 s1HB6jat033020 for freebsd-fs@FreeBSD.org; Mon, 17 Feb 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Feb 2014 11:06:45 GMT Message-Id: <201402171106.s1HB6jat033020@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, 17 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/186645 fs [fusefs] Crash after unmounting wdfs 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/185963 fs [zfs] Kernel crash trying to import a damaged ZFS pool 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 339 problems total. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 18 00:50:01 2014 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CE42886 for ; Tue, 18 Feb 2014 00:50: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 38EF3137D for ; Tue, 18 Feb 2014 00:50: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 s1I0o1rI002538 for ; Tue, 18 Feb 2014 00:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1I0o02r002537; Tue, 18 Feb 2014 00:50:00 GMT (envelope-from gnats) Date: Tue, 18 Feb 2014 00:50:00 GMT Message-Id: <201402180050.s1I0o02r002537@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Berend de Boer Subject: Re: kern/161424: [nullfs] __getcwd() calls fail when used on nullfs mount X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Berend de Boer List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:50:01 -0000 The following reply was made to PR kern/161424; it has been noted by GNATS. From: Berend de Boer To: bug-followup@FreeBSD.org, v.haisman@sh.cvut.cz Cc: Subject: Re: kern/161424: [nullfs] __getcwd() calls fail when used on nullfs mount Date: Tue, 18 Feb 2014 13:42:17 +1300 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nEvLt3fOkxeJGJidvrS3xWmuX8stFiA3E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can report this is still a problem on FreeBSD 10. --nEvLt3fOkxeJGJidvrS3xWmuX8stFiA3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTAqxpAAoJEKOfeD48G3g5clEQALgsiSO1BXEeOjtgicq+NgFj WsR+z7shNrbr81yhLSoyL870f+/JNUqOe6l68Cyf/ZrXMrgkkJpx7SlEFxCpczhM aOU4+03xHp21HY7rwuNMMJrZNqdD2BprICoKYELW2gd4/9cx+WXYKRInrccRO5xr ntpqdHZ/fFgSQut61a2VAY3/Z9Cj+DwggyX4vslxCWHeo9KNW5095te6VXU1x8IE GaP4SsivYLZqEvqN30f9GlZhozPXMtbQnboG4SlgHw0eNnuquqz1gsz9L9QuanC5 Z1MQzvn2dc8IXYpy0DZvWd6qEr2V9dqiQSJPfPkKe393Bz3uuIhxVIbsCEuXOSWM uE9zj+bYKr8TDVkKy8wJGaMiIyHPdQrWIwhMf7iA+V6LNpWxL+Aeo4V/+P6aWz6P IPaqWJrdcB01Tv/ACpx7K0B8HPiR4dlza+2GB8LRDhprYtKaG+vFyERxeUSnyl/O TW/PUvluB7jqa2MU+pJwmEsOZssNO2jhhvekMFuMkp3d7mHldZ369ZZAzMYlsMMA /LpqwoHh0U18KCjHvVQ3OgPW3RE/EDOQmnzdv6dU+pbbrKs40+SfTu4vFV2pQb1B sWxiKNAMEBZ40WQWVJxuxVeTeDuiwWfkWOug4CxiRSI8s+3+iv2uznK1aZk5Tva7 L56C2nlOwGNXbiyCqZ8F =7O3a -----END PGP SIGNATURE----- --nEvLt3fOkxeJGJidvrS3xWmuX8stFiA3E-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 04:22: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 9C40CA95; Wed, 19 Feb 2014 04:22:56 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 609901516; Wed, 19 Feb 2014 04:22:56 +0000 (UTC) Received: from [192.168.2.46] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s1J4Maur050308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 23:22:37 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: How to use zfs send -R without risking union mounts? From: John Nielsen In-Reply-To: <52D83909.3080809@bluerosetech.com> Date: Tue, 18 Feb 2014 21:22:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52D83909.3080809@bluerosetech.com> To: Darren Pilgrim X-Mailer: Apple Mail (2.1827) X-DCC--Metrics: ns1.jnielsen.net 1282; Body=3 Fuz1=3 Fuz2=3 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-fs , freebsd-questions 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, 19 Feb 2014 04:22:56 -0000 On Jan 16, 2014, at 12:54 PM, Darren Pilgrim = wrote: > When you send -R a filesystem, it very nicely retains all of the = properties. That also includes the mountpoint property. Setting = canmount=3Doff 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. >=20 > I want to create a backup using a process like: >=20 > Create the initial full backup: >=20 > zpool create backup /dev/gpt/backup > zfs create backup/tank > zfs send -R tank@yesterday | zfs recv -F backup/tank > zpool export backup >=20 > Then do incremental backups: >=20 > zpool import -N backup > zfs send -R -I tank@yesterday tank@today | zfs recv -F backup/tank > zpool export backup >=20 > 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: >=20 > mountpoint '/foo' exists and is not empty >=20 > 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. >=20 > 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. I've been working through this issue myself recently. My strategy is to = always run "zfs receive" with '-u' so the received filesystems won't be = mounted automatically, only use "zfs send -R" for the initial send", and = thereafter change each dataset's "canmount" property to "off", a la # zfs list -Ho name -r tank/backups/somehost | xargs -n 1 zfs set = canmount=3Doff I'd love to find a better solution, but that's been adequate so far. JN From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 10:36:35 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 D5A41F96 for ; Wed, 19 Feb 2014 10:36:35 +0000 (UTC) Received: from mail.myphotobook.de (mail.myphotobook.de [85.237.68.140]) by mx1.freebsd.org (Postfix) with ESMTP id 365D315F1 for ; Wed, 19 Feb 2014 10:36:34 +0000 (UTC) Received: (qmail 48091 invoked by uid 89); 19 Feb 2014 10:29:52 -0000 Received: from unknown (HELO umbrella.core) (k.kockro@myphotobook.de@87.234.224.68) by mail.myphotobook.de with AES128-SHA encrypted SMTP; 19 Feb 2014 10:29:52 -0000 Message-ID: <530487FD.10209@myphotobook.de> Date: Wed, 19 Feb 2014 11:31:25 +0100 From: Kai Kockro User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: ZFS directory not accessable Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit 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, 19 Feb 2014 10:36:35 -0000 Hello, i have an 9.2-STABLE r262153 installation on a T420s laptop. Its a ZROOT on a INTEL SSDSA2BW160G3L drive. I have a folder ( skype profil ), which is not accessable anymore. I can do ls, du and so on, but the states are in D+ after this. STRG + T shows: [user@host 11:01am] ~/.SkypeOLD/user_profil/>ls -f load: 0.13 cmd: ls 4883 [] 2.76r 0.00u 0.00s 0% 2124k load: 0.13 cmd: ls 4883 [] 3.50r 0.00u 0.00s 0% 2124k load: 0.13 cmd: ls 4883 [] 3.92r 0.00u 0.00s 0% 2124k load: 0.20 cmd: ls 4883 [] 4.13r 0.00u 0.00s 0% 2124k load: 0.20 cmd: ls 4883 [] 4.31r 0.00u 0.00s 0% 2124k What can i do? Any debug infos needed? Best, Kai -- Kai Kockro Leitung Operations myphotobook gmbh Oranienstrasse 183 10999 Berlin Tel.:+49 (0)30 616 508 100 Fax: +49 (0)30 616 508 200 Geschäftsführer: Vanessa Dill, Martin Lux Amtsgericht Charlottenburg; HRB 94377 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 10:40: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 920FFCA for ; Wed, 19 Feb 2014 10:40: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 62555166C for ; Wed, 19 Feb 2014 10:40: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 s1JAe1wO078336 for ; Wed, 19 Feb 2014 10:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1JAe1Rr078335; Wed, 19 Feb 2014 10:40:01 GMT (envelope-from gnats) Date: Wed, 19 Feb 2014 10:40:01 GMT Message-Id: <201402191040.s1JAe1Rr078335@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Andriy Gapon Subject: Re: kern/161424: [nullfs] __getcwd() calls fail when used on nullfs mount X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 10:40:01 -0000 The following reply was made to PR kern/161424; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, Berend de Boer Cc: Subject: Re: kern/161424: [nullfs] __getcwd() calls fail when used on nullfs mount Date: Wed, 19 Feb 2014 12:30:51 +0200 Can you provide all the steps required to reproduce the problem? The exact commands you execute to do mounting, to change to a directory, etc. I can not reproduce the problem by just nullfs mounting one directory over another, cd-ing into the mount and running your program. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 10:54: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 1431D3CB for ; Wed, 19 Feb 2014 10:54: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 617CD1781 for ; Wed, 19 Feb 2014 10:54: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 MAA17866; Wed, 19 Feb 2014 12:54: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 1WG4nP-000Kaq-GP; Wed, 19 Feb 2014 12:54:31 +0200 Message-ID: <53048D43.1010201@FreeBSD.org> Date: Wed, 19 Feb 2014 12:53:55 +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: Kai Kockro , freebsd-fs@FreeBSD.org Subject: Re: ZFS directory not accessable References: <530487FD.10209@myphotobook.de> In-Reply-To: <530487FD.10209@myphotobook.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 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: Wed, 19 Feb 2014 10:54:41 -0000 on 19/02/2014 12:31 Kai Kockro said the following: > Hello, > > i have an 9.2-STABLE r262153 installation on a T420s laptop. Its a ZROOT > on a INTEL SSDSA2BW160G3L drive. > > I have a folder ( skype profil ), which is not accessable anymore. I can > do ls, du and so on, but the states are in D+ after this. > > STRG + T shows: > > [user@host 11:01am] ~/.SkypeOLD/user_profil/>ls -f > load: 0.13 cmd: ls 4883 [] 2.76r 0.00u 0.00s 0% 2124k > load: 0.13 cmd: ls 4883 [] 3.50r 0.00u 0.00s 0% 2124k > load: 0.13 cmd: ls 4883 [] 3.92r 0.00u 0.00s 0% 2124k > load: 0.20 cmd: ls 4883 [] 4.13r 0.00u 0.00s 0% 2124k > load: 0.20 cmd: ls 4883 [] 4.31r 0.00u 0.00s 0% 2124k > > What can i do? Any debug infos needed? You can start with getting procstat -kk output for a stuck process. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 11:06:53 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 3001C8F0 for ; Wed, 19 Feb 2014 11:06:53 +0000 (UTC) Received: from mail.myphotobook.de (mail.myphotobook.de [85.237.68.140]) by mx1.freebsd.org (Postfix) with ESMTP id C39BC188B for ; Wed, 19 Feb 2014 11:06:52 +0000 (UTC) Received: (qmail 63095 invoked by uid 89); 19 Feb 2014 11:06:51 -0000 Received: from unknown (HELO umbrella.core) (k.kockro@myphotobook.de@87.234.224.68) by mail.myphotobook.de with AES128-SHA encrypted SMTP; 19 Feb 2014 11:06:51 -0000 Message-ID: <530490A8.70209@myphotobook.de> Date: Wed, 19 Feb 2014 12:08:24 +0100 From: Kai Kockro User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andriy Gapon , freebsd-fs@FreeBSD.org Subject: Re: ZFS directory not accessable References: <530487FD.10209@myphotobook.de> <53048D43.1010201@FreeBSD.org> In-Reply-To: <53048D43.1010201@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit 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, 19 Feb 2014 11:06:53 -0000 Hello Andriy, ps -p 4883 PID TT STAT TIME COMMAND 4883 1- D+ 0:00,00 ls -G -f procstat -kk 4883 PID TID COMM TDNAME KSTACK 4883 100558 ls - mi_switch+0x194 sleepq_wait+0x42 _sx_slock_hard+0x3b0 _sx_slock+0x3d zap_get_leaf_byblk+0xbd zap_deref_leaf+0x68 fzap_cursor_retrieve+0xe7 zap_cursor_retrieve+0x155 zfs_freebsd_readdir+0x2d8 VOP_READDIR_APV+0x78 kern_getdirentries+0x212 sys_getdirentries+0x23 amd64_syscall+0x5ea Xfast_syscall+0xf7 ps -p 5236 PID TT STAT TIME COMMAND 5236 3- D+ 0:00,00 ls -G -la procstat -kk 5236 PID TID COMM TDNAME KSTACK 5236 101104 ls - mi_switch+0x194 sleepq_wait+0x42 __lockmgr_args+0x9a0 vop_stdlock+0x39 VOP_LOCK1_APV+0x84 _vn_lock+0x47 vacl_get_acl+0x55 sys___acl_get_link+0x10d amd64_syscall+0x5ea Xfast_syscall+0xf7 Best, Kai Am 19.02.2014 11:53, schrieb Andriy Gapon: > on 19/02/2014 12:31 Kai Kockro said the following: >> Hello, >> >> i have an 9.2-STABLE r262153 installation on a T420s laptop. Its a ZROOT >> on a INTEL SSDSA2BW160G3L drive. >> >> I have a folder ( skype profil ), which is not accessable anymore. I can >> do ls, du and so on, but the states are in D+ after this. >> >> STRG + T shows: >> >> [user@host 11:01am] ~/.SkypeOLD/user_profil/>ls -f >> load: 0.13 cmd: ls 4883 [] 2.76r 0.00u 0.00s 0% 2124k >> load: 0.13 cmd: ls 4883 [] 3.50r 0.00u 0.00s 0% 2124k >> load: 0.13 cmd: ls 4883 [] 3.92r 0.00u 0.00s 0% 2124k >> load: 0.20 cmd: ls 4883 [] 4.13r 0.00u 0.00s 0% 2124k >> load: 0.20 cmd: ls 4883 [] 4.31r 0.00u 0.00s 0% 2124k >> >> What can i do? Any debug infos needed? > You can start with getting procstat -kk output for a stuck process. > -- Kai Kockro Leitung Operations myphotobook gmbh Oranienstrasse 183 10999 Berlin Tel.:+49 (0)30 616 508 100 Fax: +49 (0)30 616 508 200 Geschäftsführer: Vanessa Dill, Martin Lux Amtsgericht Charlottenburg; HRB 94377 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 11:20:53 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 AC6C0CAC for ; Wed, 19 Feb 2014 11:20:53 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E24F519FC for ; Wed, 19 Feb 2014 11:20:52 +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 NAA18273; Wed, 19 Feb 2014 13:20:44 +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 1WG5Cl-000KcR-PF; Wed, 19 Feb 2014 13:20:43 +0200 Message-ID: <53049354.3040700@FreeBSD.org> Date: Wed, 19 Feb 2014 13:19:48 +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: Kai Kockro , freebsd-fs@FreeBSD.org Subject: Re: ZFS directory not accessable References: <530487FD.10209@myphotobook.de> <53048D43.1010201@FreeBSD.org> <530490A8.70209@myphotobook.de> In-Reply-To: <530490A8.70209@myphotobook.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 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: Wed, 19 Feb 2014 11:20:53 -0000 on 19/02/2014 13:08 Kai Kockro said the following: > Hello Andriy, > > > ps -p 4883 > PID TT STAT TIME COMMAND > 4883 1- D+ 0:00,00 ls -G -f > > procstat -kk 4883 > PID TID COMM TDNAME KSTACK > 4883 100558 ls - mi_switch+0x194 > sleepq_wait+0x42 _sx_slock_hard+0x3b0 _sx_slock+0x3d > zap_get_leaf_byblk+0xbd zap_deref_leaf+0x68 fzap_cursor_retrieve+0xe7 > zap_cursor_retrieve+0x155 zfs_freebsd_readdir+0x2d8 VOP_READDIR_APV+0x78 > kern_getdirentries+0x212 sys_getdirentries+0x23 amd64_syscall+0x5ea > Xfast_syscall+0xf7 Can you please also obtain the following info? 1. Find out an inode number of the affected directory and its underlying ZFS filesystem, e.g. by using stat(1). Then execute `zdb -ddddddd `. 2. Run 'kgdb', issue 'tid 100558' command and 'bt' command. Examine the stack trace and try to get as much information as possible from frames with _sx_slock and zap_get_leaf_byblk calls. For pointers please print objects that they point to (e.g. 'print *ptr'). In particular I am interested in *sx, *zap, *l. > ps -p 5236 > PID TT STAT TIME COMMAND > 5236 3- D+ 0:00,00 ls -G -la > > procstat -kk 5236 > PID TID COMM TDNAME KSTACK > 5236 101104 ls - mi_switch+0x194 > sleepq_wait+0x42 __lockmgr_args+0x9a0 vop_stdlock+0x39 > VOP_LOCK1_APV+0x84 _vn_lock+0x47 vacl_get_acl+0x55 > sys___acl_get_link+0x10d amd64_syscall+0x5ea Xfast_syscall+0xf7 > > > > Best, > Kai > > Am 19.02.2014 11:53, schrieb Andriy Gapon: >> on 19/02/2014 12:31 Kai Kockro said the following: >>> Hello, >>> >>> i have an 9.2-STABLE r262153 installation on a T420s laptop. Its a ZROOT >>> on a INTEL SSDSA2BW160G3L drive. >>> >>> I have a folder ( skype profil ), which is not accessable anymore. I can >>> do ls, du and so on, but the states are in D+ after this. >>> >>> STRG + T shows: >>> >>> [user@host 11:01am] ~/.SkypeOLD/user_profil/>ls -f >>> load: 0.13 cmd: ls 4883 [] 2.76r 0.00u 0.00s 0% 2124k >>> load: 0.13 cmd: ls 4883 [] 3.50r 0.00u 0.00s 0% 2124k >>> load: 0.13 cmd: ls 4883 [] 3.92r 0.00u 0.00s 0% 2124k >>> load: 0.20 cmd: ls 4883 [] 4.13r 0.00u 0.00s 0% 2124k >>> load: 0.20 cmd: ls 4883 [] 4.31r 0.00u 0.00s 0% 2124k >>> >>> What can i do? Any debug infos needed? >> You can start with getting procstat -kk output for a stuck process. >> > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 11:39:46 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 1CAAA7CF for ; Wed, 19 Feb 2014 11:39:46 +0000 (UTC) Received: from mail.myphotobook.de (mail.myphotobook.de [85.237.68.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7951D1B4F for ; Wed, 19 Feb 2014 11:39:45 +0000 (UTC) Received: (qmail 78495 invoked by uid 89); 19 Feb 2014 11:39:44 -0000 Received: from unknown (HELO umbrella.core) (k.kockro@myphotobook.de@87.234.224.68) by mail.myphotobook.de with AES128-SHA encrypted SMTP; 19 Feb 2014 11:39:44 -0000 Message-ID: <5304985D.7030701@myphotobook.de> Date: Wed, 19 Feb 2014 12:41:17 +0100 From: Kai Kockro User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andriy Gapon , freebsd-fs@FreeBSD.org Subject: Re: ZFS directory not accessable References: <530487FD.10209@myphotobook.de> <53048D43.1010201@FreeBSD.org> <530490A8.70209@myphotobook.de> <53049354.3040700@FreeBSD.org> In-Reply-To: <53049354.3040700@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit 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, 19 Feb 2014 11:39:46 -0000 zdb -ddddddd umbrella/usr/home 1027 Dataset umbrella/usr/home [ZPL], ID 52, cr_txg 48, 100G, 114028 objects, rootbp DVA[0]=<0:6c023c400:200> DVA[1]=<0:c003b8a00:200> [L0 DMU objset] fletcher4 lzjb LE contiguous unique double size=800L/200P birth=2947973L/2947973P fill=114028 cksum=1d607c8fa9:939a0909e55:192c77959d738:310b5a95037557 Object lvl iblk dblk dsize lsize %full type 1027 1 16K 3.00K 2K 3.00K 100.00 ZFS directory (K=inherit) (Z=inherit) 168 bonus System attributes dnode flags: USED_BYTES USERUSED_ACCOUNTED dnode maxblkid: 0 path /user/.SkypeOLD/user_name uid 1001 gid 0 atime Tue Feb 11 12:45:46 2014 mtime Fri Feb 14 07:36:26 2014 ctime Fri Feb 14 13:43:50 2014 crtime Wed Feb 29 21:32:14 2012 gen 15787 mode 40755 size 41 parent 978 links 5 pflags 40800000144 Assertion failed: (uintptr_t)&((uint64_t *)(zap)->zap_u.zap_fat.zap_phys) [(1<<(((zap)->zap_u.zap_fat.zap_block_shift) - 3 - 1)) + (1<<(((zap)->zap_u.zap_fat.zap_block_shift) - 3 - 1))] - (uintptr_t)zap->zap_u.zap_fat.zap_phys == zap->zap_dbuf->db_size (0x800 == 0xc00), file /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c, line 450. Abbruch(core dumped) I did a bt on this core dump: (gdb) bt #0 0x0000000801c8f45c in thr_kill () from /lib/libc.so.7 #1 0x0000000801d338db in abort () from /lib/libc.so.7 #2 0x0000000801916ede in zap_lockdir () from /lib/libzpool.so.2 #3 0x0000000801917214 in zap_get_stats () from /lib/libzpool.so.2 #4 0x00000000004072e0 in ?? () #5 0x000000000040758a in ?? () #6 0x0000000000409dd6 in ?? () #7 0x000000000040a424 in ?? () #8 0x000000000040c0f8 in ?? () #9 0x0000000000404f11 in ?? () #10 0x000000080062d000 in ?? () #11 0x0000000000000000 in ?? () kgdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/umodem.ko...Reading symbols from /boot/kernel/umodem.ko.symbols...done. done. Loaded symbols for /boot/kernel/umodem.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:603 603 movq %r12,%rdi /* function */ (kgdb) tid 100558 [Switching to thread 426 (Thread 100558)]#0 sched_switch (td=0xfffffe000c00c920, newtd=0xfffffe0007212920, flags=) at /usr/src/sys/kern/sched_ule.c:1904 1904 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xfffffe000c00c920, newtd=0xfffffe0007212920, flags=) at /usr/src/sys/kern/sched_ule.c:1904 #1 0xffffffff808d6ee4 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:485 #2 0xffffffff809130a2 in sleepq_wait (wchan=0xfffffe00c0af0e00, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:621 #3 0xffffffff808d5d80 in _sx_slock_hard (sx=0xfffffe00c0af0e00, opts=, file=, line=) at /usr/src/sys/kern/kern_sx.c:926 #4 0xffffffff808d679d in _sx_slock (sx=, opts=, file=, line=) at sx.h:188 #5 0xffffffff818659ed in zap_get_leaf_byblk (zap=, blkid=9223372036854777145, tx=0x0, lt=RW_READER, lp=0xffffff824d2ce6e0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:524 #6 0xffffffff81865e28 in zap_deref_leaf (zap=0xfffffe00c0af0e00, h=, tx=0x0, lt=RW_READER, lp=0xffffff824d2ce6e0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:585 #7 0xffffffff818660f7 in fzap_cursor_retrieve (zap=0xfffffe00c0af0e00, zc=0xffffff824d2ce6d0, za=0xffffff824d2ce720) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1181 #8 0xffffffff8186abe5 in zap_cursor_retrieve (zc=0xffffff824d2ce6d0, za=0xffffff824d2ce720) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 #9 0xffffffff8189bbe8 in zfs_freebsd_readdir (ap=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2550 #10 0xffffffff80db2e28 in VOP_READDIR_APV (vop=0xffffffff8191a6c0, a=0xffffff824d2ce8e0) at vnode_if.c:1793 #11 0xffffffff809789f2 in kern_getdirentries (td=0xfffffe000c00c920, fd=, buf=0x80108e000 , count=4096, basep=0xffffff824d2ce9b8) at vnode_if.h:758 #12 0xffffffff80978cf3 in sys_getdirentries (td=, uap=0xffffff824d2cea70) at /usr/src/sys/kern/vfs_syscalls.c:4145 #13 0xffffffff80cb39aa in amd64_syscall (td=0xfffffe000c00c920, traced=0) at subr_syscall.c:135 #14 0xffffffff80c9e107 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #15 0x0000000800cffe7c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Thanks, Kai Am 19.02.2014 12:19, schrieb Andriy Gapon: > on 19/02/2014 13:08 Kai Kockro said the following: >> Hello Andriy, >> >> >> ps -p 4883 >> PID TT STAT TIME COMMAND >> 4883 1- D+ 0:00,00 ls -G -f >> >> procstat -kk 4883 >> PID TID COMM TDNAME KSTACK >> 4883 100558 ls - mi_switch+0x194 >> sleepq_wait+0x42 _sx_slock_hard+0x3b0 _sx_slock+0x3d >> zap_get_leaf_byblk+0xbd zap_deref_leaf+0x68 fzap_cursor_retrieve+0xe7 >> zap_cursor_retrieve+0x155 zfs_freebsd_readdir+0x2d8 VOP_READDIR_APV+0x78 >> kern_getdirentries+0x212 sys_getdirentries+0x23 amd64_syscall+0x5ea >> Xfast_syscall+0xf7 > Can you please also obtain the following info? > 1. Find out an inode number of the affected directory and its underlying ZFS > filesystem, e.g. by using stat(1). Then execute `zdb -ddddddd `. > > 2. Run 'kgdb', issue 'tid 100558' command and 'bt' command. > Examine the stack trace and try to get as much information as possible from > frames with _sx_slock and zap_get_leaf_byblk calls. For pointers please print > objects that they point to (e.g. 'print *ptr'). > In particular I am interested in *sx, *zap, *l. > >> ps -p 5236 >> PID TT STAT TIME COMMAND >> 5236 3- D+ 0:00,00 ls -G -la >> >> procstat -kk 5236 >> PID TID COMM TDNAME KSTACK >> 5236 101104 ls - mi_switch+0x194 >> sleepq_wait+0x42 __lockmgr_args+0x9a0 vop_stdlock+0x39 >> VOP_LOCK1_APV+0x84 _vn_lock+0x47 vacl_get_acl+0x55 >> sys___acl_get_link+0x10d amd64_syscall+0x5ea Xfast_syscall+0xf7 >> >> >> >> Best, >> Kai >> >> Am 19.02.2014 11:53, schrieb Andriy Gapon: >>> on 19/02/2014 12:31 Kai Kockro said the following: >>>> Hello, >>>> >>>> i have an 9.2-STABLE r262153 installation on a T420s laptop. Its a ZROOT >>>> on a INTEL SSDSA2BW160G3L drive. >>>> >>>> I have a folder ( skype profil ), which is not accessable anymore. I can >>>> do ls, du and so on, but the states are in D+ after this. >>>> >>>> STRG + T shows: >>>> >>>> [user@host 11:01am] ~/.SkypeOLD/user_profil/>ls -f >>>> load: 0.13 cmd: ls 4883 [] 2.76r 0.00u 0.00s 0% 2124k >>>> load: 0.13 cmd: ls 4883 [] 3.50r 0.00u 0.00s 0% 2124k >>>> load: 0.13 cmd: ls 4883 [] 3.92r 0.00u 0.00s 0% 2124k >>>> load: 0.20 cmd: ls 4883 [] 4.13r 0.00u 0.00s 0% 2124k >>>> load: 0.20 cmd: ls 4883 [] 4.31r 0.00u 0.00s 0% 2124k >>>> >>>> What can i do? Any debug infos needed? >>> You can start with getting procstat -kk output for a stuck process. >>> > -- Kai Kockro Leitung Operations myphotobook gmbh Oranienstrasse 183 10999 Berlin Tel.:+49 (0)30 616 508 100 Fax: +49 (0)30 616 508 200 Geschäftsführer: Vanessa Dill, Martin Lux Amtsgericht Charlottenburg; HRB 94377 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 19 14:47:47 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 9A9A0E5B for ; Wed, 19 Feb 2014 14:47:47 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) by mx1.freebsd.org (Postfix) with ESMTP id 59A691D32 for ; Wed, 19 Feb 2014 14:47:47 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 875C09DCAEF for ; Wed, 19 Feb 2014 15:47:40 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Possible ZFS bug? Insufficient sanity checks Date: Wed, 19 Feb 2014 15:47:35 +0100 Message-Id: To: "freebsd-fs@FreeBSD.org Filesystems" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) 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, 19 Feb 2014 14:47:47 -0000 Hello, Doing something stupid I managed to corrupt a ZFS pool. I think it = shouldn=B4t have been possible. I hope to reproduce it next week, but it's better to share just in case.=20 I know what I did was quite foolish, and no dolphins were hurt as it's = just a test machine. FreeBSD pruebassd 10.0-STABLE FreeBSD 10.0-STABLE #8: Wed Feb 12 = 09:32:29 UTC 2014 root@pruebassd:/usr/obj/usr/src/sys/PRUEBASSD2_10 = amd64 The pool has one RAIDZ vdev, with 6 OCZ Vertex 4 SSDs. The stupid manoeuvre was as follows: 1) Pick up one of the disks at random. 2) Extract it. So far so good. zpool warns that the pool is in degraded state, but = everythng works. 3) Take the disk to a different system. Insert it and create a new pool = on it. Just one disk, I was testing a data corruption issue with a "mfi" = adapter. 4) Do some tests. 5) Probably (not sure) destroy the newly created pool. 6) take the ssd to the original machine -> insert it And here the fun comes. 7) zpool online cashopul (the previously removed disk) 8) KABOOM! zpool warns of data corruption all over the place. -> most = files corrupted. My theory: When doing the "zpool online" ZFS just checked the disk = serial number or identification, and, being the same, *not verifying the = pool identity* it mixed it into the pool with disastrous consequences. What I think should have happened instead: - ZFS should verify the physical disk "identity" *and* verify that the = ZFS metadata on the disk indeed belongs to the pool on which it's being = "onlined". Again, I do know that I did something very foolish (I behave in a = foolish and careless way with that machine on purpose). I'll try to reproduce this next week (I'm waiting to receive some SAS = cables). Cheers, Borja. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 12:44:32 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 B2D6A346 for ; Thu, 20 Feb 2014 12:44:32 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E1391BE5 for ; Thu, 20 Feb 2014 12:44:32 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id C80541534C0 for ; Thu, 20 Feb 2014 13:44:28 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNwOVrNlFub7; Thu, 20 Feb 2014 13:44:27 +0100 (CET) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 2BC711534D1 for ; Thu, 20 Feb 2014 13:44:27 +0100 (CET) Message-ID: <5305F8B0.1060308@digiware.nl> Date: Thu, 20 Feb 2014 13:44:32 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: fs@freebsd.org Subject: What types of SSDs to use..... 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: Thu, 20 Feb 2014 12:44:32 -0000 Hi, I'm looking for advise and suggestions on what SSDs to use for the ZFS-systems I have and/or am building.... I know the difference between SLC en MLC , but beyond that I have not the best experience with all the older SSD I have lingering about here. Most of them just "disconnect" after a while. It could be because they have exceeded their wear level and just can not write any more. But than that has occurred rather fast. So what types SSD are others using for ZIL cache what is your experience with them Thanx, --WjW From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 13:06:10 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 91497A89 for ; Thu, 20 Feb 2014 13:06:10 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D7531DA0 for ; Thu, 20 Feb 2014 13:06:08 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50008446843.msg for ; Thu, 20 Feb 2014 13:06:05 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 20 Feb 2014 13:06:05 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1128321063=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: <783388CA2911497B98479F1187F49915@multiplay.co.uk> From: "Steven Hartland" To: "Willem Jan Withagen" , References: <5305F8B0.1060308@digiware.nl> Subject: Re: What types of SSDs to use..... Date: Thu, 20 Feb 2014 13:06:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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, 20 Feb 2014 13:06:10 -0000 The "disconnect" issue is generally related to Sandforce based devices. Its a lot better on later devices / firmware and does depend on the controller / MB they are connected to. We have ~ 1000 SSD's in production most being consumer grade Sandforce based and disks, from various manufactures, drops are still fairly rare now; I'd estimate ~ 1 or 2 per month. Samsung 840 Pro's seem pretty good too for consumer devices. Regards Steve ----- Original Message ----- From: "Willem Jan Withagen" To: Sent: Thursday, February 20, 2014 12:44 PM Subject: What types of SSDs to use..... > Hi, > > I'm looking for advise and suggestions on what SSDs to use for the > ZFS-systems I have and/or am building.... > > I know the difference between SLC en MLC , but beyond that I have not > the best experience with all the older SSD I have lingering about here. > > Most of them just "disconnect" after a while. > It could be because they have exceeded their wear level and just can not > write any more. But than that has occurred rather fast. > > So what types SSD are others using for > ZIL > cache > what is your experience with them > > Thanx, > --WjW > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 13:15:01 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 628FFDD6 for ; Thu, 20 Feb 2014 13:15:01 +0000 (UTC) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D9E21F99 for ; Thu, 20 Feb 2014 13:15:00 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 379B928428; Thu, 20 Feb 2014 14:14:53 +0100 (CET) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 50A5D28429; Thu, 20 Feb 2014 14:14:51 +0100 (CET) Message-ID: <5305FFCA.6070702@quip.cz> Date: Thu, 20 Feb 2014 14:14:50 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Willem Jan Withagen Subject: Re: What types of SSDs to use..... References: <5305F8B0.1060308@digiware.nl> In-Reply-To: <5305F8B0.1060308@digiware.nl> 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: Thu, 20 Feb 2014 13:15:01 -0000 Willem Jan Withagen wrote: > Hi, > > I'm looking for advise and suggestions on what SSDs to use for the > ZFS-systems I have and/or am building.... > > I know the difference between SLC en MLC , but beyond that I have not > the best experience with all the older SSD I have lingering about here. > > Most of them just "disconnect" after a while. > It could be because they have exceeded their wear level and just can not > write any more. But than that has occurred rather fast. If we are talking about cheap SSDs... we are using Samsung 840 Pro (MLC). We have them on MariaDB (MySQL) server for a few month. It is good to watch SMART of SSDs, mainly for Wear_Leveling_Count. You can see this (for example): ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 2176 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 5 177 Wear_Leveling_Count 0x0013 097 097 000 Pre-fail Always - 108 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0 187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 081 069 000 Old_age Always - 19 195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0 199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 2 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 10494506165 Miroslav Lachman From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:09:21 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 E93D52CC for ; Thu, 20 Feb 2014 14:09:21 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A435F14CA for ; Thu, 20 Feb 2014 14:09:21 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id E6B0B1534D1; Thu, 20 Feb 2014 15:09:11 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iktPGzFp0DdU; Thu, 20 Feb 2014 15:09:10 +0100 (CET) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 104A0153448; Thu, 20 Feb 2014 15:09:10 +0100 (CET) Message-ID: <53060C89.8040500@digiware.nl> Date: Thu, 20 Feb 2014 15:09:13 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Steven Hartland , fs@freebsd.org Subject: Re: What types of SSDs to use..... References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> In-Reply-To: <783388CA2911497B98479F1187F49915@multiplay.co.uk> 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: Thu, 20 Feb 2014 14:09:22 -0000 On 20-2-2014 14:06, Steven Hartland wrote: > The "disconnect" issue is generally related to Sandforce based devices. > > Its a lot better on later devices / firmware and does depend on the > controller / MB they are connected to. Any easy way to detect these? Or is it just a matter of reading the specsheets? Hoping that the controller chipset is mentioned. > We have ~ 1000 SSD's in production most being consumer grade Sandforce > based and disks, from various manufactures, drops are still fairly rare > now; I'd estimate ~ 1 or 2 per month. > > Samsung 840 Pro's seem pretty good too for consumer devices. I got these offered a few times, they are quite competatively priced. Thanx, --WjW From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:11:28 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 1AC3A3FA for ; Thu, 20 Feb 2014 14:11:28 +0000 (UTC) Received: from mta1-filtered.netlife.no (mail.netlife.no [62.92.26.226]) by mx1.freebsd.org (Postfix) with ESMTP id CA586156A for ; Thu, 20 Feb 2014 14:11:27 +0000 (UTC) Received: from amavis3.netlife.no (unknown [10.115.1.13]) by mta1-filtered.netlife.no (Postfix) with ESMTP id 293AD3125ED; Thu, 20 Feb 2014 15:02:29 +0100 (CET) X-Virus-Scanned: amavisd-new at netlife.no Received: from mta1-submission.netlife.no ([62.92.26.226]) by amavis3.netlife.no (amavis3.netlife.no [10.115.1.13]) (amavisd-new, port 10026) with ESMTP id s7L6DG0e6WmH; Thu, 20 Feb 2014 14:02:29 +0000 (UTC) Received: from [10.0.0.41] (unknown [195.1.220.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: erik@tefre.com) by mta1-submission.netlife.no (Postfix) with ESMTPSA id C2AE73125E6; Thu, 20 Feb 2014 15:02:28 +0100 (CET) Message-ID: <53060AF4.9070900@tefre.com> Date: Thu, 20 Feb 2014 15:02:28 +0100 From: Erik Stian Tefre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Willem Jan Withagen , fs@freebsd.org Subject: Re: What types of SSDs to use..... References: <5305F8B0.1060308@digiware.nl> In-Reply-To: <5305F8B0.1060308@digiware.nl> 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, 20 Feb 2014 14:11:28 -0000 > Hi, > > I'm looking for advise and suggestions on what SSDs to use for the > ZFS-systems I have and/or am building.... > > I know the difference between SLC en MLC , but beyond that I have not > the best experience with all the older SSD I have lingering about here. > > Most of them just "disconnect" after a while. > It could be because they have exceeded their wear level and just can not > write any more. But than that has occurred rather fast. > > So what types SSD are others using for > ZIL > cache > what is your experience with them > Intel SSDs are good. I've got some handfuls of x25-e, 320, DC S3500 and DC S3700 running in supermicro servers and none of them have ever failed or dropped out in any way. The x25-es have been hammered with database loads 24/7 since 2009 without any issues. I use DC S3500 for cache. DC S3700 is probably better for ZIL. (The 3700 has a higher write endurance HET-MLC, 10x the endurance of the S3500 I think and 4x the write IOPS.) Here's an interesting SSD stress test report by the way: http://www.extremetech.com/computing/173887-ssd-stress-testing-finds-intel-might-be-the-only-reliable-drive-manufacturer -- Erik From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:15:49 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 4CD6B5D1 for ; Thu, 20 Feb 2014 14:15:49 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DDFE015AA for ; Thu, 20 Feb 2014 14:15:48 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50008447060.msg for ; Thu, 20 Feb 2014 14:15:45 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 20 Feb 2014 14:15:45 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1128321063=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Willem Jan Withagen" , References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> <53060C89.8040500@digiware.nl> Subject: Re: What types of SSDs to use..... Date: Thu, 20 Feb 2014 14:15:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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, 20 Feb 2014 14:15:49 -0000 ----- Original Message ----- From: "Willem Jan Withagen" > On 20-2-2014 14:06, Steven Hartland wrote: >> The "disconnect" issue is generally related to Sandforce based devices. >> >> Its a lot better on later devices / firmware and does depend on the >> controller / MB they are connected to. > > Any easy way to detect these? Or is it just a matter of reading the > specsheets? Hoping that the controller chipset is mentioned. Its worse that that, its literally a try it an see. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:16:18 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 EB41164C for ; Thu, 20 Feb 2014 14:16:18 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C088515B0 for ; Thu, 20 Feb 2014 14:16:18 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id md12so1948956pbc.40 for ; Thu, 20 Feb 2014 06:16:12 -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=gQAoFNs4az8MCfInx+3Zn5iqpuYIHMv/tHjCTBO6Dmk=; b=AH++wJTeDztbIT8FNVkqPxwhgNqnYb8x3OMwoTXcQpTQ4Z0VtnoM2J08jRRkbfhB+g SRidmtYJS3j+ViSasK9pSrvcQbLmILnOh4VDfrMH6cERsJhzRny2ps2TQSYX7jP0l3va wbLcqDpD2IMxplwtu/Oo+uJ7Wro3q01Dm1Ad3S+Zf94iE2qoEzKSaJHzD3vh0yLZi89u 2wJ0s9d++0RykuvXXc2gw0pdYzZwuqz2STN3nIbKXsIfzm7OVTtMMsGFw2OR02fsVhgq M+buolP7RElWWZjIKTrBT15tjWgyNr23mulHLPv276g/gLtOekb5/QZWdj2zrTsHvAGs sgFQ== X-Gm-Message-State: ALoCoQl8MAtgbaGQO7azgHTbMNftw4HaOu45sRH5QtPAPODeXBl/BbKYoMvdAik1I5haJIZrl/pr MIME-Version: 1.0 X-Received: by 10.66.121.68 with SMTP id li4mr2325154pab.33.1392905772553; Thu, 20 Feb 2014 06:16:12 -0800 (PST) Received: by 10.69.21.33 with HTTP; Thu, 20 Feb 2014 06:16:12 -0800 (PST) In-Reply-To: <53060AF4.9070900@tefre.com> References: <5305F8B0.1060308@digiware.nl> <53060AF4.9070900@tefre.com> Date: Thu, 20 Feb 2014 15:16:12 +0100 Message-ID: Subject: Re: What types of SSDs to use..... From: Johan Kooijman To: Erik Stian Tefre Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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: Thu, 20 Feb 2014 14:16:19 -0000 I'd go with Intel's. We've been using SSD's from Intel for years now, both in ZFS and non-ZFS configurations and had no issues whatsoever. We also tried the route of trying cheaper ones, including the 840 Pro's, just to save money. Turned out that under really heavy workload (ZIL or massive databases) you really want Intel's, unless you like being in the datacenter to replace SSD's on a regular basis. My experience is based on Intel 320, 510/520, X25 and for a large part S3700's. Haven't used any other SSD for the last 18 months other than the S3700. On Thu, Feb 20, 2014 at 3:02 PM, Erik Stian Tefre wrote: > Hi, >> >> I'm looking for advise and suggestions on what SSDs to use for the >> ZFS-systems I have and/or am building.... >> >> I know the difference between SLC en MLC , but beyond that I have not >> the best experience with all the older SSD I have lingering about here. >> >> Most of them just "disconnect" after a while. >> It could be because they have exceeded their wear level and just can not >> write any more. But than that has occurred rather fast. >> >> So what types SSD are others using for >> ZIL >> cache >> what is your experience with them >> >> Intel SSDs are good. I've got some handfuls of x25-e, 320, DC S3500 and > DC S3700 running in supermicro servers and none of them have ever failed or > dropped out in any way. The x25-es have been hammered with database loads > 24/7 since 2009 without any issues. > > I use DC S3500 for cache. DC S3700 is probably better for ZIL. (The 3700 > has a higher write endurance HET-MLC, 10x the endurance of the S3500 I > think and 4x the write IOPS.) > > Here's an interesting SSD stress test report by the way: > http://www.extremetech.com/computing/173887-ssd-stress- > testing-finds-intel-might-be-the-only-reliable-drive-manufacturer > > -- > Erik > > _______________________________________________ > 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" > -- Met vriendelijke groeten / With kind regards, Johan Kooijman T +31(0) 6 43 44 45 27 F +31(0) 162 82 00 01 E mail@johankooijman.com From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:19:26 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 E9AB27C5 for ; Thu, 20 Feb 2014 14:19:26 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B89315CB for ; Thu, 20 Feb 2014 14:19:26 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so1377881lbi.11 for ; Thu, 20 Feb 2014 06:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kcuLvim5AwM0/FLuw+RYwpKLFPUV6L/2Ehv33GZYGak=; b=FTM1VZ7rko5Ojp61asaq8XbOJY9Bzgrb5quxg9j01mlJM85y0kpT4w8QFwA8Gf4pCa 73HtEnV9nw3PYHbPah+jhhMvYgLkBk+cYUwqX8MYyUczJLWGv0gcTfebmvWBNkX6R1eK XFIkeUEADGT+3hR1VOzCRfSgR95w6WH7w0sCrB0HqUtBXaEYl0F0yXL45DdlXF7oBEOM 1f4GVdCoqQYwKstbMbsu2q0RXfomU3sQSnwUinyzLpqsYUrGAxX1iabKDFnM2b+nRCnr pt8TRWk6VQcyq1cvOgO6vCngdERRaokgpBrQDn2Snl22dwuXRZlXUf8XVU6/oD42LYhV AwxQ== MIME-Version: 1.0 X-Received: by 10.152.36.70 with SMTP id o6mr1291878laj.7.1392905964227; Thu, 20 Feb 2014 06:19:24 -0800 (PST) Received: by 10.112.35.167 with HTTP; Thu, 20 Feb 2014 06:19:24 -0800 (PST) In-Reply-To: <53060C89.8040500@digiware.nl> References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> <53060C89.8040500@digiware.nl> Date: Thu, 20 Feb 2014 14:19:24 +0000 Message-ID: Subject: Re: What types of SSDs to use..... From: Tom Evans To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 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: Thu, 20 Feb 2014 14:19:27 -0000 On Thu, Feb 20, 2014 at 2:09 PM, Willem Jan Withagen wrote: > On 20-2-2014 14:06, Steven Hartland wrote: >> The "disconnect" issue is generally related to Sandforce based devices. >> >> Its a lot better on later devices / firmware and does depend on the >> controller / MB they are connected to. > > Any easy way to detect these? Or is it just a matter of reading the > specsheets? Hoping that the controller chipset is mentioned. > You can tell the old (SF-2000) chipset devices from their advertised read and write speeds - read will be 500+MBs, write will be 200-300MBs. This is because the "read speed" assumes you will be reading compressible data. I would avoid SF based drives if you can, I have had horrific experiences with OCZ Vertex 4 SSDs where they basically lock up if you do non-sequential access. Having said that, there are two parts to it, the controller and the firmware running on the controller; Intel SSDs using SF controllers, like the Intel 530, don't have such a bad reputation. Looking on wikipedia or tech review sites for a specific SSD should let you know what controller it uses, if it is not listed in the tech specs. I replaced my OCZ drives with Crucial M4, which use a Marvell controller. Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:20:32 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 9081A84E for ; Thu, 20 Feb 2014 14:20:32 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A8D4163F for ; Thu, 20 Feb 2014 14:20:31 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50008447113.msg for ; Thu, 20 Feb 2014 14:20:29 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 20 Feb 2014 14:20:29 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1128321063=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Johan Kooijman" , "Erik Stian Tefre" References: <5305F8B0.1060308@digiware.nl><53060AF4.9070900@tefre.com> Subject: Re: What types of SSDs to use..... Date: Thu, 20 Feb 2014 14:20:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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: Thu, 20 Feb 2014 14:20:32 -0000 ----- Original Message ----- From: "Johan Kooijman" To: "Erik Stian Tefre" Cc: Sent: Thursday, February 20, 2014 2:16 PM Subject: Re: What types of SSDs to use..... > I'd go with Intel's. We've been using SSD's from Intel for years now, both > in ZFS and non-ZFS configurations and had no issues whatsoever. > We also tried the route of trying cheaper ones, including the 840 Pro's, > just to save money. Turned out that under really heavy workload (ZIL or > massive databases) you really want Intel's, unless you like being in the > datacenter to replace SSD's on a regular basis. > > My experience is based on Intel 320, 510/520, X25 and for a large part > S3700's. Haven't used any other SSD for the last 18 months other than the > S3700. Intel 320, 510 and 520 still suffer from the drops. X25 are very slow I wouldn't recommend anyone use those. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:20:39 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 889508B7 for ; Thu, 20 Feb 2014 14:20:39 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4392D1642 for ; Thu, 20 Feb 2014 14:20:39 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id B46C31534D1; Thu, 20 Feb 2014 15:20:37 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN1UqqRlNMDP; Thu, 20 Feb 2014 15:20:35 +0100 (CET) Received: from [192.168.101.102] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id E48AB153448; Thu, 20 Feb 2014 15:20:33 +0100 (CET) Message-ID: <53060F37.7030203@digiware.nl> Date: Thu, 20 Feb 2014 15:20:39 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Steven Hartland , fs@freebsd.org Subject: Re: What types of SSDs to use..... References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> <53060C89.8040500@digiware.nl> In-Reply-To: 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: Thu, 20 Feb 2014 14:20:39 -0000 On 20-2-2014 15:15, Steven Hartland wrote: > > ----- Original Message ----- From: "Willem Jan Withagen" > > >> On 20-2-2014 14:06, Steven Hartland wrote: >>> The "disconnect" issue is generally related to Sandforce based devices. >>> >>> Its a lot better on later devices / firmware and does depend on the >>> controller / MB they are connected to. >> >> Any easy way to detect these? Or is it just a matter of reading the >> specsheets? Hoping that the controller chipset is mentioned. > > Its worse that that, its literally a try it an see. Seeing is: The devices just drops of the Sata-channel?? That is what happens with me with certain older Corsair stuff. --WjW From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:23:10 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 59CA9BE9 for ; Thu, 20 Feb 2014 14:23:10 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E759F1673 for ; Thu, 20 Feb 2014 14:23:09 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50008447125.msg for ; Thu, 20 Feb 2014 14:23:01 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 20 Feb 2014 14:23:01 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1128321063=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: <65C4D81622BE4331A9DD9FE2A293B303@multiplay.co.uk> From: "Steven Hartland" To: "Tom Evans" , "Willem Jan Withagen" References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> <53060C89.8040500@digiware.nl> Subject: Re: What types of SSDs to use..... Date: Thu, 20 Feb 2014 14:23:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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: Thu, 20 Feb 2014 14:23:10 -0000 ----- Original Message ----- From: "Tom Evans" To: "Willem Jan Withagen" Cc: Sent: Thursday, February 20, 2014 2:19 PM Subject: Re: What types of SSDs to use..... > On Thu, Feb 20, 2014 at 2:09 PM, Willem Jan Withagen wrote: >> On 20-2-2014 14:06, Steven Hartland wrote: >>> The "disconnect" issue is generally related to Sandforce based devices. >>> >>> Its a lot better on later devices / firmware and does depend on the >>> controller / MB they are connected to. >> >> Any easy way to detect these? Or is it just a matter of reading the >> specsheets? Hoping that the controller chipset is mentioned. >> > > You can tell the old (SF-2000) chipset devices from their advertised > read and write speeds - read will be 500+MBs, write will be > 200-300MBs. This is because the "read speed" assumes you will be > reading compressible data. > > I would avoid SF based drives if you can, I have had horrific > experiences with OCZ Vertex 4 SSDs where they basically lock up if you > do non-sequential access. Having said that, there are two parts to it, > the controller and the firmware running on the controller; Intel SSDs > using SF controllers, like the Intel 530, don't have such a bad > reputation. > > Looking on wikipedia or tech review sites for a specific SSD should > let you know what controller it uses, if it is not listed in the tech > specs. I replaced my OCZ drives with Crucial M4, which use a Marvell > controller. OCZ avoid the older like the plage they are very unreliable, Crucial M4's have very slow for TRIM so would avoid them on that basis. In terms of manufactures, both Kingston and Corsair have very good support. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 14:24:09 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 148B0C76 for ; Thu, 20 Feb 2014 14:24:09 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A15A41680 for ; Thu, 20 Feb 2014 14:24:08 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50008447130.msg for ; Thu, 20 Feb 2014 14:24:06 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 20 Feb 2014 14:24:06 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1128321063=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Willem Jan Withagen" , References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> <53060C89.8040500@digiware.nl> <53060F37.7030203@digiware.nl> Subject: Re: What types of SSDs to use..... Date: Thu, 20 Feb 2014 14:24:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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, 20 Feb 2014 14:24:09 -0000 ----- Original Message ----- From: "Willem Jan Withagen" > On 20-2-2014 15:15, Steven Hartland wrote: >> >> ----- Original Message ----- From: "Willem Jan Withagen" >> >> >>> On 20-2-2014 14:06, Steven Hartland wrote: >>>> The "disconnect" issue is generally related to Sandforce based devices. >>>> >>>> Its a lot better on later devices / firmware and does depend on the >>>> controller / MB they are connected to. >>> >>> Any easy way to detect these? Or is it just a matter of reading the >>> specsheets? Hoping that the controller chipset is mentioned. >> >> Its worse that that, its literally a try it an see. > > Seeing is: > The devices just drops of the Sata-channel?? > > That is what happens with me with certain older Corsair stuff. Correct, that and if you're using ZFS you'll some time see checksum errors taking a reboot to clear. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 15:25:33 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 14632219 for ; Thu, 20 Feb 2014 15:25:33 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (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 9C2261CFB for ; Thu, 20 Feb 2014 15:25:32 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1KFPO33069538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Feb 2014 08:25:24 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1KFPMc9069535; Thu, 20 Feb 2014 08:25:22 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 20 Feb 2014 08:25:22 -0700 (MST) From: Warren Block To: Willem Jan Withagen Subject: Re: What types of SSDs to use..... In-Reply-To: <53060C89.8040500@digiware.nl> Message-ID: References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> <53060C89.8040500@digiware.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 20 Feb 2014 08:25:24 -0700 (MST) 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: Thu, 20 Feb 2014 15:25:33 -0000 On Thu, 20 Feb 2014, Willem Jan Withagen wrote: > On 20-2-2014 14:06, Steven Hartland wrote: >> The "disconnect" issue is generally related to Sandforce based devices. >> >> Its a lot better on later devices / firmware and does depend on the >> controller / MB they are connected to. > > Any easy way to detect these? Or is it just a matter of reading the > specsheets? Hoping that the controller chipset is mentioned. > >> We have ~ 1000 SSD's in production most being consumer grade Sandforce >> based and disks, from various manufactures, drops are still fairly rare >> now; I'd estimate ~ 1 or 2 per month. >> >> Samsung 840 Pro's seem pretty good too for consumer devices. > > I got these offered a few times, they are quite competatively priced. The Plextor M5P models have a Marvell controller and are competitive with the Samsung 840 Pro. The Toshiba SSDs also have Marvell controllers and are worth a look. However, I have not used either for ZFS. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 15:36:01 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 C8A3F4A6 for ; Thu, 20 Feb 2014 15:36:01 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (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 775991DF3 for ; Thu, 20 Feb 2014 15:36:01 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1KFZv2Z069642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Feb 2014 08:35:57 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1KFZv0i069639; Thu, 20 Feb 2014 08:35:57 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 20 Feb 2014 08:35:57 -0700 (MST) From: Warren Block To: Erik Stian Tefre Subject: Re: What types of SSDs to use..... In-Reply-To: <53060AF4.9070900@tefre.com> Message-ID: References: <5305F8B0.1060308@digiware.nl> <53060AF4.9070900@tefre.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 20 Feb 2014 08:35:58 -0700 (MST) 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: Thu, 20 Feb 2014 15:36:01 -0000 On Thu, 20 Feb 2014, Erik Stian Tefre wrote: > Here's an interesting SSD stress test report by the way: > http://www.extremetech.com/computing/173887-ssd-stress-testing-finds-intel-might-be-the-only-reliable-drive-manufacturer That test was very domain-specific, seeing which SSDs lost data while writing during a power loss. Also a strange combination of SSDs tested. Interesting, but not overly relevant to the way most SSDs are used. Just to add: some Intel SSDs use Sandforce controllers with custom firmware. Maybe not all of them, I have not kept track. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 16:22:55 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 888C637B for ; Thu, 20 Feb 2014 16:22:55 +0000 (UTC) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 511E6132A for ; Thu, 20 Feb 2014 16:22:55 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id m1so2347499oag.34 for ; Thu, 20 Feb 2014 08:22:54 -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=7Abb8sL2ijJB4oKKNr6FRotOOpxIeSN5Mw0EfMERaao=; b=cDtb3roKLx3JbHzgLoPbTUEv70UvlCwENuWhIScmLuYKbAusYotB1rclxoxWMwD3In SsnE61g0CNYjXxSk81n4vVcLNF0qH37/KKENeJtVVyCDq8vH8k5rZJbuYi0VujuwO87X iaRBtHoCUNxGIu9LSvIoVDwkkulZQJLb9kIg56hgb0zTuAs6wh570cN0gMUh8AE+i0wc A6nDofA0NoJp724572X7pClY6zai802Sd3hWr0FmwWygx4Qs3+i2uqcOuktRmBSLDLaE ne4WP1xZhOje6+H37fCoEwHov6stsQOCdzVSqYGoEfdgt966/SNBM0aOoTmiEsaa9YRm KXjw== MIME-Version: 1.0 X-Received: by 10.60.63.102 with SMTP id f6mr2257234oes.76.1392913374471; Thu, 20 Feb 2014 08:22:54 -0800 (PST) Received: by 10.76.180.164 with HTTP; Thu, 20 Feb 2014 08:22:54 -0800 (PST) Received: by 10.76.180.164 with HTTP; Thu, 20 Feb 2014 08:22:54 -0800 (PST) In-Reply-To: <5305F8B0.1060308@digiware.nl> References: <5305F8B0.1060308@digiware.nl> Date: Thu, 20 Feb 2014 08:22:54 -0800 Message-ID: Subject: Re: What types of SSDs to use..... From: Freddie Cash To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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: Thu, 20 Feb 2014 16:22:55 -0000 Typos and terseness brought to you by the LG Optimus G running Rootbox. On Feb 20, 2014 4:44 AM, "Willem Jan Withagen" wrote: > > Hi, > > I'm looking for advise and suggestions on what SSDs to use for the > ZFS-systems I have and/or am building.... > > I know the difference between SLC en MLC , but beyond that I have not > the best experience with all the older SSD I have lingering about here. > > Most of them just "disconnect" after a while. > It could be because they have exceeded their wear level and just can not > write any more. But than that has occurred rather fast. > > So what types SSD are others using for > ZIL > cache > what is your experience with them We're using Intel 330s for OS, ZIL, and swap and Intel 520s for L2ARC. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 20 16:37:54 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 942F07E2 for ; Thu, 20 Feb 2014 16:37:54 +0000 (UTC) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) by mx1.freebsd.org (Postfix) with ESMTP id 5132014CF for ; Thu, 20 Feb 2014 16:37:53 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 48FE89DD588; Thu, 20 Feb 2014 17:30:11 +0100 (CET) Subject: Re: What types of SSDs to use..... Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Borja Marcos X-Priority: 3 In-Reply-To: <783388CA2911497B98479F1187F49915@multiplay.co.uk> Date: Thu, 20 Feb 2014 17:30:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A926D02-CA2F-451B-88D8-A4275C45CDAE@sarenet.es> References: <5305F8B0.1060308@digiware.nl> <783388CA2911497B98479F1187F49915@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1283) 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: Thu, 20 Feb 2014 16:37:54 -0000 On Feb 20, 2014, at 2:06 PM, Steven Hartland wrote: > The "disconnect" issue is generally related to Sandforce based = devices. >=20 > Its a lot better on later devices / firmware and does depend on the > controller / MB they are connected to. Although it's far from being a scientific observation, I am running = several OCZ disks, which are notorious for their unreliability and, = however, since I have updated to FreeBSD 10-RELEASE I haven't seen any = disconnects. Borja. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 21 00:52:03 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 3612172A for ; Fri, 21 Feb 2014 00:52:03 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0458C16A2 for ; Fri, 21 Feb 2014 00:52:02 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D746C20C53 for ; Thu, 20 Feb 2014 19:52:00 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute5.internal (MEProxy); Thu, 20 Feb 2014 19:52:00 -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=NPpCBa/QGIqZGPtOjtZsuSFVz5Y=; b=jbI ZR2mmm6MrPshNxh11k3UUZAdBbLz80f7QU+YYpeX1ViuKZB9mEbQiBKYhi7BX0+Y 7PMv14P/adt61oApk24IDF7NnucVzbbsE0Cd1agjkmSZo0azeveemtmGiMWYTxlt bQURwB/7ozpDC7ACXL2YZAIJQ/U9qW0MGWzCxKZo= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id B41315400AC; Thu, 20 Feb 2014 19:52:00 -0500 (EST) Message-Id: <1392943920.2273.85942093.30069072@webmail.messagingengine.com> X-Sasl-Enc: tO7YpYr2HZsuUuTh3DNudOePY7aJlpxxmmLo1LGN3tlg 1392943920 From: Mark Felder To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4527a23f In-Reply-To: References: Subject: Re: Possible ZFS bug? Insufficient sanity checks Date: Thu, 20 Feb 2014 18:52:00 -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: Fri, 21 Feb 2014 00:52:03 -0000 On Wed, Feb 19, 2014, at 8:47, Borja Marcos wrote: >=20 > Hello, >=20 > Doing something stupid I managed to corrupt a ZFS pool. I think it > shouldn=B4t have been possible. I hope to reproduce it next week, but > it's better to share just in case.=20 >=20 > I know what I did was quite foolish, and no dolphins were hurt as it's > just a test machine. >=20 > FreeBSD pruebassd 10.0-STABLE FreeBSD 10.0-STABLE #8: Wed Feb 12 09:32:29 > UTC 2014 root@pruebassd:/usr/obj/usr/src/sys/PRUEBASSD2_10 amd64 >=20 > The pool has one RAIDZ vdev, with 6 OCZ Vertex 4 SSDs. >=20 > The stupid manoeuvre was as follows: >=20 > 1) Pick up one of the disks at random. >=20 > 2) Extract it. >=20 > So far so good. zpool warns that the pool is in degraded state, but > everythng works. >=20 > 3) Take the disk to a different system. Insert it and create a new pool > on it. Just one disk, I was testing a data corruption issue with a "mfi" > adapter. >=20 > 4) Do some tests. >=20 > 5) Probably (not sure) destroy the newly created pool. >=20 > 6) take the ssd to the original machine -> insert it >=20 > And here the fun comes. >=20 > 7) zpool online cashopul (the previously removed disk) >=20 > 8) KABOOM! zpool warns of data corruption all over the place. -> most > files corrupted. >=20 >=20 >=20 > My theory: When doing the "zpool online" ZFS just checked the disk > serial number or identification, and, being the same, *not verifying the > pool identity* it mixed it into the pool with disastrous consequences. >=20 > What I think should have happened instead: >=20 > - ZFS should verify the physical disk "identity" *and* verify that the > ZFS metadata on the disk indeed belongs to the pool on which it's being > "onlined". >=20 >=20 > Again, I do know that I did something very foolish (I behave in a foolish > and careless way with that machine on purpose). >=20 > I'll try to reproduce this next week (I'm waiting to receive some SAS=20 > cables). >=20 >=20 I'm curious: on both machines did the zpools share the same name? From owner-freebsd-fs@FreeBSD.ORG Fri Feb 21 07:49:00 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 CD4D85F8; Fri, 21 Feb 2014 07:49:00 +0000 (UTC) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC911BF1; Fri, 21 Feb 2014 07:49:00 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 680239DD7B7; Fri, 21 Feb 2014 08:48:58 +0100 (CET) Subject: Re: Possible ZFS bug? Insufficient sanity checks Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Borja Marcos In-Reply-To: <1392943920.2273.85942093.30069072@webmail.messagingengine.com> Date: Fri, 21 Feb 2014 08:48:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1392943920.2273.85942093.30069072@webmail.messagingengine.com> To: Mark Felder X-Mailer: Apple Mail (2.1283) 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: Fri, 21 Feb 2014 07:49:00 -0000 On Feb 21, 2014, at 1:52 AM, Mark Felder wrote: > I'm curious: on both machines did the zpools share the same name? No, not at all. I'm waiting for a couple of SAS cables to repeat the = same test and verify that it's indeed what happened. What I think so far is, ZFS was happy to see that the physical disk was = the same one.=20 Borja. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 21 11:15:36 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 711A92B3 for ; Fri, 21 Feb 2014 11:15:36 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28553108A for ; Fri, 21 Feb 2014 11:15:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WGo4l-0004tQ-64 for freebsd-fs@freebsd.org; Fri, 21 Feb 2014 12:15:27 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Feb 2014 12:15:27 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Feb 2014 12:15:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Subject: su-journal and lost+found sharing inodes? Date: Fri, 21 Feb 2014 12:15:03 +0100 Lines: 40 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wOUwwRM8Wkp459BxorohdXN8st8AGwjwt" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 X-Enigmail-Version: 1.6 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, 21 Feb 2014 11:15:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wOUwwRM8Wkp459BxorohdXN8st8AGwjwt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable After a crash which required manual fsck, I've enabled SUJ and rebooted. Everything seemed fine until I (as a part of normal, unrelated work) noticed that "lost+found" is not a file. But the details are very curious= : (ls -ali) 3 drwxrwxr-x 2 root operator 512 Jan 17 14:25 .snap/ 4 -r-------- 1 root wheel 33554432 Feb 21 10:29 .sujournal 4 -r-------- 1 root wheel 33554432 Feb 21 10:29 lost+found Am I seeing what I think I'm seeing? lost+found sharing an inode with =2Esujournal, but the hardlink count staying "1" for both files? SUJ was enabled after a fsck -y run on the file system. --wOUwwRM8Wkp459BxorohdXN8st8AGwjwt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlMHNURfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSxA2wCgk4sSZ7sOxGYtzL+Gvmp4JWnc jh4An1x6wy9DXmIX70nv0r0L3dUmsP+Q =eV7P -----END PGP SIGNATURE----- --wOUwwRM8Wkp459BxorohdXN8st8AGwjwt-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 21 16:54:14 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 BB13C6DA; Fri, 21 Feb 2014 16:54:14 +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 9D5F41448; Fri, 21 Feb 2014 16:54:14 +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 s1LGsAAi037242; Fri, 21 Feb 2014 08:54:10 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201402211654.s1LGsAAi037242@chez.mckusick.com> To: Ivan Voras Subject: Re: su-journal and lost+found sharing inodes? In-reply-to: Date: Fri, 21 Feb 2014 08:54:10 -0800 From: Kirk McKusick 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: Fri, 21 Feb 2014 16:54:14 -0000 > To: freebsd-fs@freebsd.org > From: Ivan Voras > Subject: su-journal and lost+found sharing inodes? > Date: Fri, 21 Feb 2014 12:15:03 +0100 > > After a crash which required manual fsck, I've enabled SUJ and rebooted. > Everything seemed fine until I (as a part of normal, unrelated work) > noticed that "lost+found" is not a file. But the details are very curious: > > (ls -ali) > > 3 drwxrwxr-x 2 root operator 512 Jan 17 14:25 .snap/ > 4 -r-------- 1 root wheel 33554432 Feb 21 10:29 .sujournal > 4 -r-------- 1 root wheel 33554432 Feb 21 10:29 lost+found > > Am I seeing what I think I'm seeing? lost+found sharing an inode with > .sujournal, but the hardlink count staying "1" for both files? > > SUJ was enabled after a fsck -y run on the file system. That is wrong. You will need to run fsck -f to force it to do a full fsck on the filesystem to get that cleaned up. Journalling (like all journalling systems) only fixes things that break while it is running. It does not fix up pre-existing conditions. Note that fsck -y does not always make good decision on how to handle things. It is really designed as a last-ditch effort to recover the filesystem. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Sat Feb 22 03:26:46 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 57EAAA41 for ; Sat, 22 Feb 2014 03:26:46 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 2953A1123 for ; Sat, 22 Feb 2014 03:26:45 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s1M3QYJD038915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 19:26:37 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <530818E5.4090100@freebsd.org> Date: Sat, 22 Feb 2014 11:26:29 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Erik Stian Tefre , Willem Jan Withagen , fs@freebsd.org Subject: Re: What types of SSDs to use..... References: <5305F8B0.1060308@digiware.nl> <53060AF4.9070900@tefre.com> In-Reply-To: <53060AF4.9070900@tefre.com> 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: Sat, 22 Feb 2014 03:26:46 -0000 On 2/20/14, 10:02 PM, Erik Stian Tefre wrote: >> Hi, >> >> I'm looking for advise and suggestions on what SSDs to use for the >> ZFS-systems I have and/or am building.... >> >> I know the difference between SLC en MLC , but beyond that I have not >> the best experience with all the older SSD I have lingering about >> here. >> >> Most of them just "disconnect" after a while. >> It could be because they have exceeded their wear level and just >> can not >> write any more. But than that has occurred rather fast. >> >> So what types SSD are others using for >> ZIL >> cache >> what is your experience with them >> > Intel SSDs are good. I've got some handfuls of x25-e, 320, DC S3500 > and DC S3700 running in supermicro servers and none of them have > ever failed or dropped out in any way. The x25-es have been hammered > with database loads 24/7 since 2009 without any issues. the newest intel drives have enough RAM inhtem to actually index the entire drive in ram, so the performance is a lot better. Prior to that they had to hold the index on flash, (with a cache). > > I use DC S3500 for cache. DC S3700 is probably better for ZIL. (The > 3700 has a higher write endurance HET-MLC, 10x the endurance of the > S3500 I think and 4x the write IOPS.) > > Here's an interesting SSD stress test report by the way: > http://www.extremetech.com/computing/173887-ssd-stress-testing-finds-intel-might-be-the-only-reliable-drive-manufacturer > doesn't count PCI SSDs.. > > -- > Erik > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sat Feb 22 07:49: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 CFF9C98F for ; Sat, 22 Feb 2014 07:49:13 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A80291C07 for ; Sat, 22 Feb 2014 07:49:13 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kp14so4401086pab.23 for ; Fri, 21 Feb 2014 23:49:12 -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 :content-type; bh=cP7p2huCI7A8vwgRP+1nnf/MzJx8E3gjTfXrWkRdhig=; b=uJYEZQOdNlcndPOtN3KwT45Pd9aujEYqfgjOPtqsT+HiCDJj2qXftOTVMOS9AIXJsw /rZlHYW576PSNUKZVDgpp0Jj4lWiq3Mlfjq/DPntANdryVyC1csSBGzpOu8GyeIG0Hck 1Rgj/eYCCfH2nWn0pLAzlpYfUmzfLXbjbPgWL5ib/NtHYRAbbGEQQrQqiLuJeOTpLF0s CQwyzw9dn7Fv+3uO/IgitKsnuYYhhzeLmCaU5PlmFgNG3vQqneE4B2JoJZI1Y0vsVNnx DZjb3mrTk/or6bkXuel53bBpZ2J1BV8+TTuY9KpLykvEQWST1ap6t6V+H1fWSbzjsxz9 SfGw== MIME-Version: 1.0 X-Received: by 10.69.19.139 with SMTP id gu11mr13743522pbd.149.1393055352753; Fri, 21 Feb 2014 23:49:12 -0800 (PST) Received: by 10.66.27.75 with HTTP; Fri, 21 Feb 2014 23:49:12 -0800 (PST) In-Reply-To: References: Date: Sat, 22 Feb 2014 08:49:12 +0100 Message-ID: Subject: Re: Recovering deleted file, strange structure From: Felipe Monteiro de Carvalho To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 22 Feb 2014 07:49:13 -0000 Hello, Really no ideas what this structure is? =( thanks, Felipe Monteiro de Carvalho On Thu, Feb 6, 2014 at 2:20 PM, Felipe Monteiro de Carvalho wrote: > Hello, > > I am implementing a software to recover deleted files in UFS-1/2. > Right now I am first focusing in UFS-2, so I created a partition, > added some files, deleted a file, and then added more files. > > The name of the file (10MB_88.bin) completely vanished from the disk > image, and it's inode and dir entry were also overwritten. > > But I found this strange place in the disk where I can clearly see > references to the first and following block fragments of the disk ($B0 > 12 00 00 00 00 00 00), see this screenshot here: > > http://imageshack.com/a/img546/3399/o1lz.png > > But what kind of section/structure is this? I am reading the source > code of FreeBSD UFS driver, and I attempted to compare to the structs > there, but nothing seams to match ... each $20 bytes we have a new > record with a reference to a block fragment. > > I tried to compare to the ufs_cylinder_group but it doesn't match ... > so any ideas which struct / place in the source code is utilized to > create this structure? > > thank you very much =) > -- > Felipe Monteiro de Carvalho -- Felipe Monteiro de Carvalho From owner-freebsd-fs@FreeBSD.ORG Sat Feb 22 09:55:43 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 50050D65 for ; Sat, 22 Feb 2014 09:55:43 +0000 (UTC) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A91015C8 for ; Sat, 22 Feb 2014 09:55:42 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id oz11so2331017veb.34 for ; Sat, 22 Feb 2014 01:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Topta8EgZW1hdIe/IJVtkTTyed25RgfzxB6DlR/O4vg=; b=i8XLfmHVbi0/JymlwYLl3ef3NfiH7+vnhrQKDxbiZQ9EpZBd4FkvzHvDBLUwDUPLXI sAaPzCfTpdyNXoTf8K1+Or/poMZsgcZSVi4cL8J1/FvjJdNzqJ0y4Zssdwyvk6RQIFT5 PaZCrYud8pvPIPEedXW7CBoG1UsB+w5FwAW8VjA7ut4i+2KPlVcHqZwXW1+mHZJ0cplB cxAAmMWPARYaAxsAXylFj1y6ez7loWB57tfHIjEILr3U0sKrHAa6/XVNQ4/R4WwyvaPs tNyhyCKA9t5XsBLB4j9tKyPofbAnyaqvV8e44QD4Tma4fbBdDIaRavI3C+s5OizRlgm9 Hiag== X-Received: by 10.52.191.9 with SMTP id gu9mr6325372vdc.37.1393062942112; Sat, 22 Feb 2014 01:55:42 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.58.181.134 with HTTP; Sat, 22 Feb 2014 01:55:01 -0800 (PST) In-Reply-To: <201402211654.s1LGsAAi037242@chez.mckusick.com> References: <201402211654.s1LGsAAi037242@chez.mckusick.com> From: Ivan Voras Date: Sat, 22 Feb 2014 10:55:01 +0100 X-Google-Sender-Auth: EReitgzfjbJ9UP5i8_o5rIoywPc Message-ID: Subject: Re: su-journal and lost+found sharing inodes? To: Kirk McKusick 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, 22 Feb 2014 09:55:43 -0000 On 21 February 2014 17:54, Kirk McKusick wrote: > > To: freebsd-fs@freebsd.org > > From: Ivan Voras > > Subject: su-journal and lost+found sharing inodes? > > Date: Fri, 21 Feb 2014 12:15:03 +0100 > > > > After a crash which required manual fsck, I've enabled SUJ and rebooted. > > Everything seemed fine until I (as a part of normal, unrelated work) > > noticed that "lost+found" is not a file. But the details are very > curious: > > > > (ls -ali) > > > > 3 drwxrwxr-x 2 root operator 512 Jan 17 14:25 .snap/ > > 4 -r-------- 1 root wheel 33554432 Feb 21 10:29 .sujournal > > 4 -r-------- 1 root wheel 33554432 Feb 21 10:29 lost+found > > > > Am I seeing what I think I'm seeing? lost+found sharing an inode with > > .sujournal, but the hardlink count staying "1" for both files? > > > > SUJ was enabled after a fsck -y run on the file system. > > That is wrong. You will need to run fsck -f to force it to do a full > fsck on the filesystem to get that cleaned up. Journalling (like all > journalling systems) only fixes things that break while it is running. > It does not fix up pre-existing conditions. Note that fsck -y does not > always make good decision on how to handle things. It is really designed > as a last-ditch effort to recover the filesystem. > I didn't want to suggest that journaling would fix anything, I was describing the sequence of operations I did: first fsck -y then turning on journaling - the inode mixup could have happened either in fsck or in tunefs where it re-used an inode which it shouldn't have.