From owner-freebsd-fs@FreeBSD.ORG Sun May 22 06:19:01 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 648D6106564A for ; Sun, 22 May 2011 06:19:01 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DCC58FC08 for ; Sun, 22 May 2011 06:19:01 +0000 (UTC) Received: by pwj8 with SMTP id 8so2905271pwj.13 for ; Sat, 21 May 2011 23:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fDKE98oLCE1D2ePvkrLp//u1vhCJdDYYw0w/tRQdnp4=; b=ij4iTRE8O01idKTZ2Nh5qzY6yo39Rz9VdA1S/XpTo/p8jmBF7K+dWca+udmOpwc7G8 gfcT6FjLNZFtEkRa7ua8lo7qa32FOgqMmK1TD3hhDY7twbWVvoQk43HgDmHEKMRQOiWa WV3k8RMViKR7PVLKvKw2fPTBeOabhMeB7vPTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VO7+j2k+FQMlRhhgCtS9dLEz/xmoaBhga3aHJF/ClmvgO8xSSgWsAPdrIpKdI0dUYx 2rWKTJLkaNRmi+MSnKzydzcohybF7Ex0leLXeo5f7wl0gX85EtWFh3swKjWD3ZnY6eBb UBHJZ7nLEpdWVrtV+thiTSELvyM3cZB49jvbM= MIME-Version: 1.0 Received: by 10.142.230.6 with SMTP id c6mr663600wfh.415.1306045140730; Sat, 21 May 2011 23:19:00 -0700 (PDT) Received: by 10.142.157.2 with HTTP; Sat, 21 May 2011 23:19:00 -0700 (PDT) In-Reply-To: <6806.1305962015@critter.freebsd.dk> References: <6806.1305962015@critter.freebsd.dk> Date: Sun, 22 May 2011 02:19:00 -0400 Message-ID: From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: Write reallocator X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 06:19:01 -0000 >>see if it will reallocate marginal reads when written to. >>Because the data is still semi valuable, I want to >>read and write back every block of the disk. >>Any tools that will do this? > > Recoverdisk ? This is interesting, yet man does not indicate rewriting capabilities, only copying off to other media. dd will throw error block indexes. recoverdisk will automagically attempt rereading them, sizing down the bs. It's not clear to me what the zero blocksize in '-b 0' means, since you can't read anything less than the native size. I think recoverdisk could have another useful mode to take a list of error sectors '-e elist' (whether from dd noerror or a first pass of itself), and then loop read those into numbered files, instead of copying the whole 3TB worth of disk. With an option to zero pad after n number of read attempts. Those could then be layed back onto disk by hand. In the past, I've noticed some disks will cough up the sector in question depending on the covering bs size used, don't know why. dd reads a block before writing it (presumably up to some blocksize limitation), so we still have this old trick. If it's a file, and after all the full bs sized records, the last block is shorter than the bs, it will need to be handled separately. If it's a device, it's ok as it throws a short write EOD. There is no safety net obviously. # dd if=/dev/urandom of=r bs=1m count=50 50+0 records in 50+0 records out 52428800 bytes transferred in 2.552598 secs (20539388 bytes/sec) # ls -isl r 5 51248 -rw-r--r-- 1 0 0 52428800 May 22 01:19 r # md5 r MD5 (r) = 92b48057a6af390fa337523c10b757bc # dd if=r of=r conv=notrunc,noerror,sync bs=512 102400+0 records in 102400+0 records out 52428800 bytes transferred in 1.388739 secs (37752807 bytes/sec) # dd if=r of=r conv=notrunc,noerror,sync bs=1m 50+0 records in 50+0 records out 52428800 bytes transferred in 0.636191 secs (82410485 bytes/sec) # dd if=r of=r conv=notrunc,noerror,sync bs=50m 1+0 records in 1+0 records out 52428800 bytes transferred in 0.905330 secs (57911263 bytes/sec) # ls -isl r 5 51248 -rw-r--r-- 1 0 0 52428800 May 22 01:20 r # md5 r MD5 (r) = 92b48057a6af390fa337523c10b757bc From owner-freebsd-fs@FreeBSD.ORG Mon May 23 08:17:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B2D1065670 for ; Mon, 23 May 2011 08:17:50 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 69D1A8FC1A for ; Mon, 23 May 2011 08:17:50 +0000 (UTC) Received: (qmail 51246 invoked by uid 89); 23 May 2011 10:17:48 +0200 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with CAMELLIA256-SHA encrypted SMTP; 23 May 2011 10:17:48 +0200 Message-ID: <4DDA182B.8090901@bytecamp.net> Date: Mon, 23 May 2011 10:17:47 +0200 From: Robert Schulze Organization: bytecamp GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: rm on full zfs: quota limit exceeded X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 08:17:50 -0000 Hi, I thought that this bug was already fixed, but it isn't: deleting a file from a full ZFS results in "Disc quota exceeded". We are running 8.2-STABLE (amd64) from 2011-05-08. Zpool version 14, zfs version 3. Is this already fixed in newer zpool/zfs versions? with kind regards, Robert Schulze From owner-freebsd-fs@FreeBSD.ORG Mon May 23 11:06:58 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E4D41065679 for ; Mon, 23 May 2011 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5DC348FC25 for ; Mon, 23 May 2011 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NB6weB051659 for ; Mon, 23 May 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NB6vOI051657 for freebsd-fs@FreeBSD.org; Mon, 23 May 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 May 2011 11:06:57 GMT Message-Id: <201105231106.p4NB6vOI051657@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 11:06:58 -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/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156933 fs [zfs] ZFS receive after read on readonly=on filesystem 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/156168 fs [nfs] [panic] Kernel panic under concurrent access ove o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155484 fs [ufs] GPT + UFS boot don't work well together o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew 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/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small p kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode 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 kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/150207 fs zpool(1): zpool import -d /dev tries to open weird dev 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 bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload 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/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o 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/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/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/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani 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 f kern/116170 fs [panic] Kernel panic when mounting /tmp o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro f kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash 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 224 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon May 23 23:18:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BFFB106566B for ; Mon, 23 May 2011 23:18:40 +0000 (UTC) (envelope-from gull@gull.us) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A36978FC0C for ; Mon, 23 May 2011 23:18:39 +0000 (UTC) Received: by eyg7 with SMTP id 7so2761536eyg.13 for ; Mon, 23 May 2011 16:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.98.76 with SMTP id u52mr987789eef.220.1306190866512; Mon, 23 May 2011 15:47:46 -0700 (PDT) Received: by 10.14.50.70 with HTTP; Mon, 23 May 2011 15:47:46 -0700 (PDT) X-Originating-IP: [173.250.142.84] In-Reply-To: <4DDA182B.8090901@bytecamp.net> References: <4DDA182B.8090901@bytecamp.net> Date: Mon, 23 May 2011 15:47:46 -0700 Message-ID: From: David Brodbeck To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: rm on full zfs: quota limit exceeded X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 23:18:40 -0000 On Mon, May 23, 2011 at 1:17 AM, Robert Schulze wrote: > Hi, > > I thought that this bug was already fixed, but it isn't: deleting a file > from a full ZFS results in "Disc quota exceeded". > > We are running 8.2-STABLE (amd64) from 2011-05-08. Zpool version 14, zfs > version 3. > > Is this already fixed in newer zpool/zfs versions? Are you using 'quota' or 'refquota'? 'quota' takes into account snapshots, so even if the bug is fixed you could still hit this if you're using quota and have snapshots. 'refquota' ignores snapshots and is probably what you want. From owner-freebsd-fs@FreeBSD.ORG Tue May 24 08:03:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60E931065672 for ; Tue, 24 May 2011 08:03:14 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4838FC1F for ; Tue, 24 May 2011 08:03:13 +0000 (UTC) Received: (qmail 53068 invoked by uid 89); 24 May 2011 10:03:12 +0200 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with CAMELLIA256-SHA encrypted SMTP; 24 May 2011 10:03:12 +0200 Message-ID: <4DDB663F.8090406@bytecamp.net> Date: Tue, 24 May 2011 10:03:11 +0200 From: Robert Schulze Organization: bytecamp GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DDA182B.8090901@bytecamp.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: rm on full zfs: quota limit exceeded X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 08:03:14 -0000 Hi, Am 24.05.2011 00:47, schrieb David Brodbeck: > > Are you using 'quota' or 'refquota'? I'm using quota, but no snapshots at all. with kind regards, Robert Schulze From owner-freebsd-fs@FreeBSD.ORG Tue May 24 15:04:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 399AD1065670 for ; Tue, 24 May 2011 15:04:30 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta04.eastlink.ca (mta04.eastlink.ca [24.224.136.10]) by mx1.freebsd.org (Postfix) with ESMTP id 024D48FC0A for ; Tue, 24 May 2011 15:04:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip02.eastlink.ca ([24.222.39.20]) by mta04.eastlink.ca (Oracle Communications Messaging Exchange Server 7u4-21.01 64bit (built Feb 16 2011)) with ESMTP id <0LLP00LPAGJGD4Q0@mta04.eastlink.ca>; Tue, 24 May 2011 12:04:28 -0300 (ADT) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=nHVfyXyYbG49+bwDOo/IKBjvzAnLnYW+rCeuHgA+IwM= c=1 sm=1 a=ABXVJdilHEcA:10 a=kj9zAlcOel0A:10 a=2PQ8b1CnNZl47xe8dgsA:9 a=CjuIK1q_8ugA:10 a=Y4g+zi6NJtbRuBVJrbSZ6Q==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip02.eastlink.ca with ESMTP; Tue, 24 May 2011 12:04:28 -0300 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Tue, 24 May 2011 12:04:28 -0300 From: Chris Forgeron To: FreeBSD bugmaster , "freebsd-fs@FreeBSD.org" Date: Tue, 24 May 2011 12:04:27 -0300 Thread-topic: Current problem reports assigned to freebsd-fs@FreeBSD.org Thread-index: AcwZObxzePEMJBTzQ9Cie8dA78QEHQA6ejWQ Message-id: References: <201105231106.p4NB6vOI051657@freefall.freebsd.org> In-reply-to: <201105231106.p4NB6vOI051657@freefall.freebsd.org> Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Cc: Subject: RE: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:04:30 -0000 Wow, there's enough ZFS problems there to keep a team of programmers busy for months. What can we (I) do to help out? I assume the bugs need further confirmation before being brought to pjd's attention for fixing? From owner-freebsd-fs@FreeBSD.ORG Tue May 24 15:33:57 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 432A21065673; Tue, 24 May 2011 15:33:57 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6128FC15; Tue, 24 May 2011 15:33:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4OFXuom058260; Tue, 24 May 2011 15:33:56 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4OFXuuJ058256; Tue, 24 May 2011 15:33:56 GMT (envelope-from bcr) Date: Tue, 24 May 2011 15:33:56 GMT Message-Id: <201105241533.p4OFXuuJ058256@freefall.freebsd.org> To: bcr@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:33:57 -0000 Synopsis: boot from zfs kernel.old recovery undocumented/impossible Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: bcr Responsible-Changed-When: Tue May 24 15:31:04 UTC 2011 Responsible-Changed-Why: >From the description, it sounds more like an issue for the filesystem people. http://www.freebsd.org/cgi/query-pr.cgi?pr=153804 From owner-freebsd-fs@FreeBSD.ORG Tue May 24 16:08:51 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E7BC106566B for ; Tue, 24 May 2011 16:08:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1D21F8FC0A for ; Tue, 24 May 2011 16:08:50 +0000 (UTC) Received: by yie12 with SMTP id 12so3380315yie.13 for ; Tue, 24 May 2011 09:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=ij8B/3v27cjYwK2+PgDD+yRbbAJm/P2fZMOa0eA3doI=; b=Hy9cwYBpPa5Q9Tc/pztORt5okAnkEY94Q7mD7Z71jf33QwTF8/2g8Xjaj6KmrGChKP /hs5W8NUWFcVQpBi06VGBgjK5MHw1BiUxd7BGK9Lkr0CHdlP3lxDQ5/nWyQmOIvXp6Ia GXPO0OurgnJgXj7aYwJUDJdzXKTiQqJFLFYp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=IlIgguwBuisU7vTz3lSS4l783UBjr3KgeiBKW19KjIeQaS94NLV67U8ieXgKYwdCqJ BQaz65HA+bbJGyjCDD86GyhbEBPqCaAl2KBzlEVuD5cnMmuLF7jCrLpq0b8wFQZSVFsH rzIJrnlnTX5LEaME3QezAR6a/1cQSrXmgew4s= Received: by 10.101.86.16 with SMTP id o16mr5236321anl.135.1306251970194; Tue, 24 May 2011 08:46:10 -0700 (PDT) Received: from oddish.mark-home (Mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id d36sm5661881and.30.2011.05.24.08.46.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 08:46:09 -0700 (PDT) Date: Tue, 24 May 2011 11:46:02 -0400 From: Mark Johnston To: freebsd-fs@freebsd.org Message-ID: <20110524154602.GA57782@oddish.mark-home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: fdisk(1) uses a signed int for slice sizes X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:08:51 -0000 Hello all, fdisk(1) uses a signed int to store slice sizes when reading in a config file. On platforms with sizeof(int) == 4, this prevents users from specifying a size of more than 2^{31}-1 sectors even though the corresponding MBR field is a 32-bit unsigned number. I have a little patch which fixes this; I was going to ask rstone@ to commit it, but I'd like to know if there are any objections/comments first. Thanks, -Mark diff --git a/sbin/fdisk/fdisk.c b/sbin/fdisk/fdisk.c index 8314906..eb81e3b 100644 --- a/sbin/fdisk/fdisk.c +++ b/sbin/fdisk/fdisk.c @@ -108,9 +108,9 @@ typedef struct cmd { char cmd; int n_args; struct arg { - char argtype; - int arg_val; - char *arg_str; + char argtype; + unsigned long arg_val; + char * arg_str; } args[MAX_ARGS]; } CMD; @@ -990,7 +990,7 @@ parse_config_line(char *line, CMD *command) if (isalpha(*cp)) command->args[command->n_args].argtype = *cp++; end = NULL; - command->args[command->n_args].arg_val = strtol(cp, &end, 0); + command->args[command->n_args].arg_val = strtoul(cp, &end, 0); if (cp == end || (!isspace(*end) && *end != '\0')) { char ch; end = cp; From owner-freebsd-fs@FreeBSD.ORG Tue May 24 18:50:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 389841065674 for ; Tue, 24 May 2011 18:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 100B78FC1C for ; Tue, 24 May 2011 18:50:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4OIoBFm031734 for ; Tue, 24 May 2011 18:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4OIoBjS031733; Tue, 24 May 2011 18:50:11 GMT (envelope-from gnats) Date: Tue, 24 May 2011 18:50:11 GMT Message-Id: <201105241850.p4OIoBjS031733@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:50:12 -0000 The following reply was made to PR kern/153804; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, nsayer@kfu.com Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible Date: Tue, 24 May 2011 21:47:08 +0300 Try the following options: 1) unload set kernel=kernel.old boot 2) unload load /boot/kernel.old/kernel load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache boot My expectation is that both should do what you want. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue May 24 19:55:30 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6551D1065672 for ; Tue, 24 May 2011 19:55:30 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id CCFCE8FC08 for ; Tue, 24 May 2011 19:55:29 +0000 (UTC) Received: from [IPv6:2001:470:28:140:24f5:b4af:c57c:abfe] ([IPv6:2001:470:28:140:24f5:b4af:c57c:abfe]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p4OJtOT0008638 for ; Tue, 24 May 2011 22:55:24 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DDC0D13.3030401@ukr.net> Date: Tue, 24 May 2011 22:54:59 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: fs@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-92.0 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE,SPF_SOFTFAIL,TO_NO_BRKTS_DIRECT,T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Tue, 24 May 2011 22:55:28 +0300 (EEST) Cc: Subject: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 19:55:30 -0000 how to change the status of "FAULTED" on "DEGRADED"? # zpool import pool: tank id: 17628573572433446879 state: FAULTED status: One or more devices are missing from the system. action: The pool cannot be imported. Attach the missing devices and try again. The pool may be active on another system, but can be imported using the '-f' flag. see: http://www.sun.com/msg/ZFS-8000-3C config: tank FAULTED corrupted data raidz2 DEGRADED gpt/disk0 ONLINE gpt/disk1 ONLINE gpt/disk2 ONLINE gpt/disk3 UNAVAIL cannot open gpt/disk4 ONLINE ad18p1 ONLINE -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Tue May 24 20:18:54 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD4F1106564A for ; Tue, 24 May 2011 20:18:53 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9FA8FC08 for ; Tue, 24 May 2011 20:18:52 +0000 (UTC) Received: from [IPv6:2001:470:28:140:24f5:b4af:c57c:abfe] ([IPv6:2001:470:28:140:24f5:b4af:c57c:abfe]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p4OKImdq010862 for ; Tue, 24 May 2011 23:18:48 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DDC128F.80203@ukr.net> Date: Tue, 24 May 2011 23:18:23 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 References: <4DDC0D13.3030401@ukr.net> <20110524201118.GF2415@garage.freebsd.pl> In-Reply-To: <20110524201118.GF2415@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-94.3 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, MISSING_HEADERS,RDNS_NONE,SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Tue, 24 May 2011 23:18:51 +0300 (EEST) Cc: fs@freebsd.org Subject: Re: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:18:54 -0000 24.05.2011 23:11, Pawel Jakub Dawidek wrote: > Which FreeBSD version and ZFS version are you running? If this is v15, > then you might need 9-CURRENT to import that pool or wait for MFC of > v28, which should happen soon. FreeBSD 8.2-STABLE #0: Wed Apr 20 03:20:47 EEST 2011 vlad11@beastie.mydomain.local:/usr/obj/usr/src/sys/otrada.1 amd64 Yes, thank you, wait for MFC. For a 9-CURRENT serious slowdown in the speed of SATA drives. -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Tue May 24 20:33:11 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29B81106566C for ; Tue, 24 May 2011 20:33:11 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id C1CD38FC17 for ; Tue, 24 May 2011 20:33:10 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4BBBB45EC0; Tue, 24 May 2011 22:11:52 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8CB7945F1F; Tue, 24 May 2011 22:11:45 +0200 (CEST) Date: Tue, 24 May 2011 22:11:18 +0200 From: Pawel Jakub Dawidek To: "Vladislav V. Prodan" Message-ID: <20110524201118.GF2415@garage.freebsd.pl> References: <4DDC0D13.3030401@ukr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b8GWCKCLzrXbuNet" Content-Disposition: inline In-Reply-To: <4DDC0D13.3030401@ukr.net> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: fs@freebsd.org Subject: Re: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:33:11 -0000 --b8GWCKCLzrXbuNet Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 24, 2011 at 10:54:59PM +0300, Vladislav V. Prodan wrote: > how to change the status of "FAULTED" on "DEGRADED"? >=20 > # zpool import > pool: tank > id: 17628573572433446879 > state: FAULTED > status: One or more devices are missing from the system. > action: The pool cannot be imported. Attach the missing > devices and try again. > The pool may be active on another system, but can be imported usi= ng > the '-f' flag. > see: http://www.sun.com/msg/ZFS-8000-3C > config: >=20 > tank FAULTED corrupted data > raidz2 DEGRADED > gpt/disk0 ONLINE > gpt/disk1 ONLINE > gpt/disk2 ONLINE > gpt/disk3 UNAVAIL cannot open > gpt/disk4 ONLINE > ad18p1 ONLINE Which FreeBSD version and ZFS version are you running? If this is v15, then you might need 9-CURRENT to import that pool or wait for MFC of v28, which should happen soon. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --b8GWCKCLzrXbuNet Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk3cEOYACgkQForvXbEpPzRX0ACfZ37AAKgfCwnbxaO/UeVjG8r5 9ZsAn01JaZGk5+gNkCqDEQRXSrIjfy2T =de8R -----END PGP SIGNATURE----- --b8GWCKCLzrXbuNet-- From owner-freebsd-fs@FreeBSD.ORG Tue May 24 22:00:25 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE281065673 for ; Tue, 24 May 2011 22:00:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A46C28FC18 for ; Tue, 24 May 2011 22:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4OM0Pvs004160 for ; Tue, 24 May 2011 22:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4OM0Pfb004159; Tue, 24 May 2011 22:00:25 GMT (envelope-from gnats) Date: Tue, 24 May 2011 22:00:25 GMT Message-Id: <201105242200.p4OM0Pfb004159@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Nick Sayer Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nick Sayer List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:00:25 -0000 The following reply was made to PR kern/153804; it has been noted by GNATS. From: Nick Sayer To: Andriy Gapon Cc: bug-followup@FreeBSD.org Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible Date: Tue, 24 May 2011 14:58:39 -0700 Option number 2, indeed, does the trick. This should be added to the documentation for ZFS-on-root installations. From owner-freebsd-fs@FreeBSD.ORG Wed May 25 03:23:57 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A37106566B for ; Wed, 25 May 2011 03:23:57 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C0F418FC15 for ; Wed, 25 May 2011 03:23:56 +0000 (UTC) Received: by iwn33 with SMTP id 33so9146798iwn.13 for ; Tue, 24 May 2011 20:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :reply-to:references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=bngYr861I55ZDa9IBIzofSPgrxE7UOrkNAYg1iq1Yuw=; b=GIOBHN7UEjZpj4ws2s8PiePWWuJFOqCfsnpYlwChRg/HQ9Ee2Ead8kFrzfnr2M7YLD wH6leqjhW4imsiQCeCqD8oviJ03zS5wrCoKBSQQA19Vmvn9OBWU5ig1ZQn5uajQP7adI o6dETZdMLO5iJcqlQCn0xVisf0KGmKe5qYNYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :x-openpgp-key-id:x-openpgp-key-fingerprint:x-openpgp-key-url; b=dxNl3z+HoxwRN+0GZdIZFeLP/fvTKjhGkssxq/1frReE1y8A2fWVOSub7l/iDuyYG1 Mh7r2xOf++aJE55NWHbJbbreZZ4/Doiaf2yrKzVG/Af2Jq27VyBHpLVliWqqDufIaRKp M+xJk888fFN0Ti/1waT036S4f1XcsJmi46JnY= Received: by 10.231.195.40 with SMTP id ea40mr3859528ibb.167.1306292318623; Tue, 24 May 2011 19:58:38 -0700 (PDT) Received: from DataIX.net (adsl-99-181-146-200.dsl.klmzmi.sbcglobal.net [99.181.146.200]) by mx.google.com with ESMTPS id o3sm3585018ibd.44.2011.05.24.19.58.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 19:58:37 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4P2wXFJ005308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 22:58:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4P2wVWJ005307; Tue, 24 May 2011 22:58:31 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 24 May 2011 22:58:31 -0400 From: Jason Hellenthal To: "Vladislav V. Prodan" Message-ID: <20110525025831.GA2363@DataIX.net> References: <4DDC0D13.3030401@ukr.net> <20110524201118.GF2415@garage.freebsd.pl> <4DDC128F.80203@ukr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <4DDC128F.80203@ukr.net> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: fs@freebsd.org Subject: Re: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhell@DataIX.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:23:57 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Vladislav, Hi. Just a heads up on this instead of waiting for the MFC to happen you may want to boot mfsBSD from Martin Matuska [1][2] to check your disks ahead of time and diagnose whether it is worthwhile waiting for the MFC. Recently another fellow IRC'er had a ZFSv15 pool on 8.2-X and had one drive faulted that needed to be replaced. These drives were moved from one machine to another and the drive that faulted was unrecoverable for whatever reason, but unknown to the user, he had a second drive in the new machine that was showing up with some massive DMA errors after a reboot making the total drives that were faulted and irreparable greater than the amount that is allowed to be faulted in a raidz1 pool ultimately making his whole pool unrecoverable. Unfortunately he ended up having to destroy the pool and live with the loss of data. Anyway to cut to the facts of that. Only one of the faulted drives were picked up by ZFS v15 "don't know why" and the one with all the DMA errors only shown up in v28 as faulted which I found to be quite odd. It would be to your advantage to run some drive tests using smartctl or whatever your comfortable with and also grab one of the v28 images below to test boot and try repairing while waiting. Good luck. 1). http://mfsbsd.vx.sk/iso/mfsbsd-8.2-zfsv28-i386.iso 2). http://mfsbsd.vx.sk/iso/mfsbsd-8.2-zfsv28-amd64.iso On Tue, May 24, 2011 at 11:18:23PM +0300, Vladislav V. Prodan wrote: > 24.05.2011 23:11, Pawel Jakub Dawidek wrote: > > Which FreeBSD version and ZFS version are you running? If this is v15, > > then you might need 9-CURRENT to import that pool or wait for MFC of > > v28, which should happen soon. >=20 > FreeBSD 8.2-STABLE #0: Wed Apr 20 03:20:47 EEST 2011=20 > vlad11@beastie.mydomain.local:/usr/obj/usr/src/sys/otrada.1 amd64 >=20 > Yes, thank you, wait for MFC. > For a 9-CURRENT serious slowdown in the speed of SATA drives. >=20 --=20 Regards, (jhell) Jason Hellenthal --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJN3HBXAAoJEJBXh4mJ2FR+h34IAJfGmh38LYVKkW42i2SJK7hS XppU01/xvYEbXaEBwxHAOa/m+IHRm7o2diD2o1hnINL+4NyuufAYU7uelLE3+etq ORhMllm+AwOLC90DHo01/eJ7KlapIsOMeRkKeSCzlAGXzhOGFsH30BLtn97d7keR 9zzVkDVUwI0zwafP+85X3kaJ816b5YjJb0wYpTXCcPDEsRY90l7GNvmI2OX9VWqR 954CnXSU3U0Jv2+gkoTpth4IxcDcBhKY+eVb/b9498oTqodnNYctHMk9F3lnRVDy D96IjHYDOR+152dNfRpJIXKDehzPnwhZnb5nRv6j3jWrTGrE+ZFOgN4UZPqt1H8= =CMGh -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-fs@FreeBSD.ORG Wed May 25 09:00:25 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736E71065679 for ; Wed, 25 May 2011 09:00:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6412A8FC08 for ; Wed, 25 May 2011 09:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4P90OTX041093 for ; Wed, 25 May 2011 09:00:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4P90OJO041088; Wed, 25 May 2011 09:00:24 GMT (envelope-from gnats) Date: Wed, 25 May 2011 09:00:24 GMT Message-Id: <201105250900.p4P90OJO041088@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Pan Tsu Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pan Tsu List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:00:25 -0000 The following reply was made to PR kern/153804; it has been noted by GNATS. From: Pan Tsu To: Andriy Gapon Cc: bug-followup@FreeBSD.org, Nick Sayer Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible Date: Wed, 25 May 2011 12:52:38 +0400 Andriy Gapon writes: > Try the following options: > > 1) > unload > set kernel=kernel.old > boot > > 2) > unload > load /boot/kernel.old/kernel > load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache zpool_cache_type can be anything. loader(8) unlike grub2 doesn't enforce type to be "/boot/zfs/zpool.cache". > boot Whatever happened to just typing following? boot kernel.old It assumes zpool.cache was already preloaded by failed attempt to boot default kernel. No need to `unload' the kernel, `boot' replaces it. > My expectation is that both should do what you want. From owner-freebsd-fs@FreeBSD.ORG Wed May 25 13:33:42 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F40E1065670 for ; Wed, 25 May 2011 13:33:42 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3E368FC16 for ; Wed, 25 May 2011 13:33:41 +0000 (UTC) Received: from [IPv6:2001:470:28:140:5557:cc11:66f1:fc92] ([IPv6:2001:470:28:140:5557:cc11:66f1:fc92]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p4PDXb3A036513 for ; Wed, 25 May 2011 16:33:37 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DDD0516.4060000@ukr.net> Date: Wed, 25 May 2011 16:33:10 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: fs@freebsd.org References: <4DDC0D13.3030401@ukr.net> <20110524201118.GF2415@garage.freebsd.pl> <4DDC128F.80203@ukr.net> <20110525025831.GA2363@DataIX.net> In-Reply-To: <20110525025831.GA2363@DataIX.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-95.5 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE, SPF_SOFTFAIL, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Wed, 25 May 2011 16:33:40 +0300 (EEST) Cc: Subject: Re: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:33:42 -0000 25.05.2011 5:58, Jason Hellenthal wrote: > > Vladislav, > > Hi. Just a heads up on this instead of waiting for the MFC to happen you > may want to boot mfsBSD from Martin Matuska [1][2] to check your disks > ahead of time and diagnose whether it is worthwhile waiting for the MFC. Thank you for reminding me about this rescue-CD. I received a broken pool raidz2. 1) Run smartctl on all 6 disks. He showed that the three discs problem with counters: 184 End-to-End_Error 0x0033 001 001 099 Pre-fail Always FAILING_NOW 149 2) I pulled out the two problematic screws to carry the service, but the pool would not be installed and not the mounted and remained in the status of "FAULTED" 3) I gave up one drive to the service, and the second returned to the place, but the pool is still unable to import. Probably I should do I get all the disks in the pool, correct errors and one by one off from the pool and one to refer to the service. P.S. I have a system to another pool. -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Wed May 25 14:30:16 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 658A8106564A for ; Wed, 25 May 2011 14:30:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5583E8FC13 for ; Wed, 25 May 2011 14:30:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PEUGor044108 for ; Wed, 25 May 2011 14:30:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PEUG2d044103; Wed, 25 May 2011 14:30:16 GMT (envelope-from gnats) Date: Wed, 25 May 2011 14:30:16 GMT Message-Id: <201105251430.p4PEUG2d044103@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Nick Sayer Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nick Sayer List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:30:16 -0000 The following reply was made to PR kern/153804; it has been noted by GNATS. From: Nick Sayer To: Pan Tsu Cc: Andriy Gapon , bug-followup@FreeBSD.org Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible Date: Wed, 25 May 2011 07:21:40 -0700 On May 25, 2011, at 1:52 AM, Pan Tsu wrote: > Andriy Gapon writes: >=20 >> Try the following options: >>=20 >> 1) >> unload >> set kernel=3Dkernel.old >> boot >>=20 >> 2) >> unload >> load /boot/kernel.old/kernel >> load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache >=20 > zpool_cache_type can be anything. loader(8) unlike grub2 doesn't = enforce > type to be "/boot/zfs/zpool.cache". >=20 >> boot >=20 > Whatever happened to just typing following? >=20 > boot kernel.old >=20 > It assumes zpool.cache was already preloaded by failed attempt to boot > default kernel. No need to `unload' the kernel, `boot' replaces it. I didn't try that. At the time I didn't think it worked that way. Back = when I was in full on panic mode, I think option number 1 was what = finally worked, but I am happier with option 2, as it offers the most = control. It just needs to be better documented. >=20 >> My expectation is that both should do what you want. From owner-freebsd-fs@FreeBSD.ORG Wed May 25 16:04:15 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCD2D106564A for ; Wed, 25 May 2011 16:04:15 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 338BC8FC15 for ; Wed, 25 May 2011 16:04:14 +0000 (UTC) Received: from [IPv6:2001:470:28:140:5557:cc11:66f1:fc92] ([IPv6:2001:470:28:140:5557:cc11:66f1:fc92]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p4PG4492004572 for ; Wed, 25 May 2011 19:04:04 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DDD2859.2070600@ukr.net> Date: Wed, 25 May 2011 19:03:37 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 References: <4DDC0D13.3030401@ukr.net> <20110524201118.GF2415@garage.freebsd.pl> <4DDC128F.80203@ukr.net> <20110525025831.GA2363@DataIX.net> In-Reply-To: <20110525025831.GA2363@DataIX.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-94.3 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, MISSING_HEADERS,RDNS_NONE,SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Wed, 25 May 2011 19:04:13 +0300 (EEST) Cc: fs@freebsd.org Subject: Re: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:04:15 -0000 25.05.2011 5:58, Jason Hellenthal пишет: > Hi. Just a heads up on this instead of waiting for the MFC to happen you > may want to boot mfsBSD from Martin Matuska [1][2] to check your disks > ahead of time and diagnose whether it is worthwhile waiting for the MFC. > > 2).http://mfsbsd.vx.sk/iso/mfsbsd-8.2-zfsv28-amd64.iso I downloaded and booted from that image. 1) mfsBSD not see my sata drives connected to ports on the motherboard, through the driver ahci 2) When I set the BIOS RAID mode saw not all disks. I still tried to look zpool import, he told me to import only through gptid. I have disks in the pool are tied after gpart label. -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Wed May 25 17:55:29 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3416B106566C for ; Wed, 25 May 2011 17:55:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2548FC0A for ; Wed, 25 May 2011 17:55:28 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ntvT1g0010x6nqcA3tvUPQ; Wed, 25 May 2011 17:55:28 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id ntvS1g01B1t3BNj8YtvSak; Wed, 25 May 2011 17:55:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C68BA102C19; Wed, 25 May 2011 10:55:26 -0700 (PDT) Date: Wed, 25 May 2011 10:55:26 -0700 From: Jeremy Chadwick To: "Vladislav V. Prodan" Message-ID: <20110525175526.GA45398@icarus.home.lan> References: <4DDC0D13.3030401@ukr.net> <20110524201118.GF2415@garage.freebsd.pl> <4DDC128F.80203@ukr.net> <20110525025831.GA2363@DataIX.net> <4DDD0516.4060000@ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DDD0516.4060000@ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:55:29 -0000 On Wed, May 25, 2011 at 04:33:10PM +0300, Vladislav V. Prodan wrote: > 25.05.2011 5:58, Jason Hellenthal wrote: > > > >Vladislav, > > > >Hi. Just a heads up on this instead of waiting for the MFC to happen you > >may want to boot mfsBSD from Martin Matuska [1][2] to check your disks > >ahead of time and diagnose whether it is worthwhile waiting for the MFC. > > Thank you for reminding me about this rescue-CD. > > I received a broken pool raidz2. > > 1) Run smartctl on all 6 disks. He showed that the three discs > problem with counters: > 184 End-to-End_Error 0x0033 001 001 099 Pre-fail Always FAILING_NOW 149 Without knowing the exact device model of disk ("Device Model:"), and whether or not the disk is within smartmontools' internal drive database ("Device is:"), this attribute may or may not actually be End-to-End_Error. It would be helpful if you could provide that. Are these HP drives, per chance? Assuming these are HP drives: end-to-end error indicates, more or less, bad cache on the drive itself. HP implemented a parity check on every 512 bytes read/written from/to the drive's cache. There's no error correction used (to my knowledge), and failures are reported back to the (host) controller in some manner. HP does document that "in some situations" (reads) the drive can attempt re-reads and re-write that block of data in the cache, in hopes that a subsequent read will work. In that situation I imagine the attribute would be incremented but a hard failure (ATA error, etc.) not shown. Are you absolutely certain you haven't seen a single error on your FreeBSD console (or in /var/log/messages, etc.) since these drives were put into use? Were these brand new drives or previously used? (Footnote for readers: this SMART attribute shouldn't be confused with attribute 199 (CRC errors), which indicates communication failures between both controllers (the controller in the host, and the controller on the drive PCB) and is often an indicator of bad cabling, a bad hot-swap backplane, a dusty/dirty SATA port, etc...) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Wed May 25 22:10:45 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0D9106564A for ; Wed, 25 May 2011 22:10:45 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 242818FC14 for ; Wed, 25 May 2011 22:10:44 +0000 (UTC) Received: from [IPv6:2001:470:28:140:25bb:2c3d:a167:a9ef] ([IPv6:2001:470:28:140:25bb:2c3d:a167:a9ef]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p4PMAeem020467 for ; Thu, 26 May 2011 01:10:41 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DDD7E45.8020008@ukr.net> Date: Thu, 26 May 2011 01:10:13 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 References: <4DDC0D13.3030401@ukr.net> <20110524201118.GF2415@garage.freebsd.pl> <4DDC128F.80203@ukr.net> <20110525025831.GA2363@DataIX.net> <4DDD0516.4060000@ukr.net> <20110525175526.GA45398@icarus.home.lan> In-Reply-To: <20110525175526.GA45398@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-94.3 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, MISSING_HEADERS,RDNS_NONE,SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Thu, 26 May 2011 01:10:43 +0300 (EEST) Cc: fs@freebsd.org Subject: Re: how to import raidz2, if only one disk is missing? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 22:10:45 -0000 25.05.2011 20:55, Jeremy Chadwick wrote: > Without knowing the exact device model of disk ("Device Model:"), and > whether or not the disk is within smartmontools' internal drive database > ("Device is:"), this attribute may or may not actually be > End-to-End_Error. It would be helpful if you could provide that. Are > these HP drives, per chance? > > Assuming these are HP drives: end-to-end error indicates, more or less, > bad cache on the drive itself. HP implemented a parity check on every > 512 bytes read/written from/to the drive's cache. There's no error > correction used (to my knowledge), and failures are reported back to the > (host) controller in some manner. HP does document that "in some > situations" (reads) the drive can attempt re-reads and re-write that > block of data in the cache, in hopes that a subsequent read will work. > In that situation I imagine the attribute would be incremented but a > hard failure (ATA error, etc.) not shown. > > Are you absolutely certain you haven't seen a single error on your > FreeBSD console (or in /var/log/messages, etc.) since these drives were > put into use? Were these brand new drives or previously used? > > (Footnote for readers: this SMART attribute shouldn't be confused with > attribute 199 (CRC errors), which indicates communication failures > between both controllers (the controller in the host, and the controller > on the drive PCB) and is often an indicator of bad cabling, a bad > hot-swap backplane, a dusty/dirty SATA port, etc...) > Thanks so much for so many messages. I wanted to spread the software issue from hardware, but probably will have to tell:) I mean: Motherboard BIOSTAR TA780G M2 + HP - 1 pc CPU AMD Athlon (tm) 64 X2 Dual Core Processor 4200+ - 1 pc. PCI Express (1x) Controller for 2 SATA ports, chipset Silicon Image Inc SiI 3132 - 1 pc. HDD SAMSUNG HD753LJ - 6 pcs. HDD WDC WD5000AAKS-00TMA0 - 1 pc. Power Supply Chieftec 550 - 1 pc. On WD drives installed FreeBSD and plugged into the port Pci-e controller. All HDD Samsung plugged in the 6 slots on the motherboard. And an array of them gathered raidz2 on ZFS. All of this is gathered in a large body of Chieftec three years ago Periodically, about once every six months, 1-2 hard drive fall off from the system Helped or unplugged sata-data cable, and again plugged into the socket. A couple of times I changed them all sata-data cables with new ones. Recently, I set up to monitor smartd, to be aware of life hdd. He immediately found problems at three hdd. A couple of problematic hdd were tested mhdd, but problems with the bad-blocks not found. One of these problematic hdd I passed a local service center Samsung promised to return in 10-14 days. Now plan to borrow hdd 750GB and above to rebuild pool to working state, partly to make backuping data to another hdd. P.S. Thank you translate.google.com for translation :) -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Thu May 26 02:03:11 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41EA1106566C for ; Thu, 26 May 2011 02:03:11 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id D8F308FC0C for ; Thu, 26 May 2011 02:03:10 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id p4Q1cf59017139 for ; Thu, 26 May 2011 11:08:41 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.4.0) with ESMTP id for ; Thu, 26 May 2011 11:11:21 +0930 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 11:11:21 +0930 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 09:41:20 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id p4Q1fKuP012243 for ; Thu, 26 May 2011 09:41:20 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id p4Q1fKks012242 for freebsd-fs@freebsd.org; Thu, 26 May 2011 09:41:20 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 26 May 2011 09:41:20 +0800 From: "Wilkinson, Alex" To: freebsd-fs@freebsd.org Message-ID: <20110526014120.GA12153@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 26 May 2011 01:41:20.0696 (UTC) FILETIME=[037B1380:01CC1B46] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-18160.002 X-TM-AS-Result: No--31.058900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Fwd: [zfs-discuss] ZFS working group and feature flags proposal [SEC=UNCLASSIFIED] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 02:03:11 -0000 FYI ----- Forwarded message from Matthew Ahrens ----- Date: Wed, 25 May 2011 12:02:04 -0700 From: Matthew Ahrens To: zfs-discuss@opensolaris.org, developer@lists.illumos.org Subject: [zfs-discuss] ZFS working group and feature flags proposal List-Id: The community of developers working on ZFS continues to grow, as does the diversity of companies betting big on ZFS. We wanted a forum for these developers to coordinate their efforts and exchange ideas. The ZFS working group was formed to coordinate these development efforts. The working group encourages new membership. In order to maintain the group's focus on ZFS development, candidates should demonstrate significant and ongoing contribution to ZFS. The first product of the working group is the design for a ZFS on-disk versioning method that will allow for distributed development of ZFS on-disk format changes without further explicit coordination. This method eliminates the problem of two developers both allocating version number 31 to mean their own feature. This "feature flags" versioning allows unknown versions to be identified, and in many cases the ZFS pool or filesystem can be accessed read-only even in the presence of unknown on-disk features. My proposal covers versioning of the SPA/zpool, ZPL/zfs, send stream, and allocation of compression and checksum identifiers (enum values). We plan to implement the feature flags this summer, and aim to integrate it into Illumos. I welcome feedback on my proposal, and I'd especially like to hear from people doing ZFS development -- what are you working on? Does this meet your needs? If we implement it, will you use it? Thanks, --matt ZFS Feature Flags proposal, version 1.0, May 25th 2011 =============================== ON-DISK FORMAT CHANGES =============================== for SPA/zpool versioning: new pool version = SPA_VERSION_FEATURES = 1000 ZAP objects in MOS, pointed to by DMU_POOL_DIRECTORY_OBJECT = 1 "features_for_read" -> { feature name -> nonzero if in use } "features_for_write" -> { feature name -> nonzero if in use } "feature_descriptions" -> { feature name -> description } Note that a pool can't be opened "write-only", so the features_for_read are always required. A given feature should be stored in either features_for_read or features_for_write, not both. Note that if a feature is "promoted" from a company-private feature to part of a larger distribution (eg. illumos), this can be handled in a variety of ways, all of which can be handled with code added at that time, without changing the on-disk format. for ZPL/zfs versioning: new zpl version = ZPL_VERSION_FEATURES = 1000 same 3 ZAP objects as above, but pointed to by MASTER_NODE_OBJ = 1 "features_for_read" -> { feature name -> nonzero if in use } "features_for_write" -> { feature name -> nonzero if in use } "feature_descriptions" -> { feature name -> description } Note that the namespace for ZPL features is separate from SPA features (like version numbers), so the same feature name can be used for both (eg. for related SPA and ZPL features), but compatibility-wise this is not treated specially. for compression: must be at pool version SPA_VERSION_FEATURES ZAP object in MOS, pointed to by POOL_DIR_OBJ: "compression_algos" -> { algo name -> enum value } Existing enum values (0-14) must stay the same, but new algorithms may have different enum values in different pools. Note that this simply defines the enum value. If a new algorithm is in use, there must also be a corresponding feature in features_for_read with a nonzero value. For simplicity, all algorithms, including legacy algorithms with fixed values (lzjb, gzip, etc) should be stored here (pending evaluation of prototype code -- this may be more trouble than it's worth). for checksum: must be at pool version SPA_VERSION_FEATURES ZAP object in MOS, pointed to by POOL_DIR_OBJ: "checksum_algos" -> { algo name -> enum value } All notes for compression_algos apply here too. Must also store copy of what's needed to read the MOS in label nvlist: "features_for_read" -> { feature name -> nonzero if in use } "compression_algos" -> { algo name -> enum value } "checksum_algos" -> { algo name -> enum value } ZPL information is never needed. It's fine to store complete copies of these objects in the label. However, space in the label is limited. It's only *required* to store information needed to read the MOS so we can get to the definitive version of this information. Eg, introduce new compression algo, but it is never used in the MOS, don't need to add it to the label. Legacy algos with fixed values may be omitted from the label nvlist (eg. lzjb, fletcher4). The values in the nvlist features_for_read map may be different from the values in the MOS features_for_read. However, they must be the same when interpreted as a boolean (ie, the nvlist value != 0 iff the MOS value != 0). This is so that the nvlist map need not be updated whenever the "reference count" on a feature changes, only when it changes to/from zero. for send stream: new feature flag DRR_FLAG_FEATURES = 1<<16 BEGIN record has nvlist payload nvlist has: "features" -> { feature name -> unspecified } "types" -> { type name -> enum value } types are record types, existing ones are reserved. New types should have a corresponding feature, so presence of an unknown type is not an error. If an unknown type is used, records of that type can be safely ignored. So if a new record type can not be safely ignored, a corresponding new feature must be added. all name formats (feature name, algo name, type name): : eg. com.delphix:raidz4 all ALL_CAPS_STRING_DEFINITIONS will be #defined to the lowercase string, eg: #define FEATURES_FOR_READ "features_for_read" =============================== BEHAVIOR CHANGES =============================== zpool upgrade zpool upgrade (no arguments) If the pool is at SPA_VERSION_FEATURES, but this software supports features which are not listed in the features_for_* MOS objects, the pool should be listed as available to upgrade. It's recommended that the short name of the available features be listed. zpool upgrade -v After the list of static versions, each supported feature should be listed. zpool upgrade -a | The pool or pools will have their features_for_* MOS objects updated to list all features supported by this software. Ideally, the value of the newly-added ZAP entries will be 0, indicating that the feature is enabled but not yet in use. zpool upgrade -V -a | The may specify a feature, rather than a version number, if the version is already at SPA_VERSION_FEATURES. The feature may be specified by its short or full name. The pool or pools will have their features_for_* MOS object updated to list the specified feature, and any other features required by the specified one. pool open ("zpool import" and implicit import from zpool.cache) If pool is at SPA_VERSION_FEATURES, we must check for feature compatibility. First we will look through entries in the label nvlist's features_for_read. If there is a feature listed there which we don't understand, and it has a nonzero value, then we can not open the pool. Each vendor may decide how much information they want to print about the unsupported feature. It may be a catch all "Pool could not be opened because it uses an unsupported feature.", or it may be the most verbose message, "Pool could not be opened because it uses the following unsupported features: ...". Or features from known vs foreign vendors may be treated differently (eg. print this vendors features description, but not unknown vendors'). Note that if a feature in the label is not supported, we can't access the feature description, so at best we can print the full feature name. After checking the label's features_for_read, we know we can read the MOS, so we will continue opening it and then check the MOS's features_for_read. Note that we will need to load the label's checksum_algos and compression_algos before reading any blocks. This should be implemented as: If the pool is bring opened for writing, then features_for_write must also be checked. (Note, currently grub and zdb open the pool read-only, and the kernel module opens the pool for writing. In the future it would be great to allow the kernel module to open the pool read-only.) zfs upgrade Treat this similarly to zpool upgrade, using the filesystem's MASTER_NODE's features_for_* objects. filesystem mount Treat this similarly to pool open, using the filesystem's MASTER_NODE's features_for_* objects. zfs receive If any unknown features are in the stream's BEGIN record's nvlist's "features" entry, then the stream can not be received. =============================== IMPLEMENTATION NOTES =============================== Legacy checksum algorithms are to be stored as follows: "com.sun:label" -> 3 "com.sun:gang_header" -> 4 "com.sun:zilog" -> 5 "com.sun:fletcher2" -> 6 "com.sun:fletcher4" -> 7 "com.sun:sha256" -> 8 "com.sun:zilog2" -> 9 Legacy compression algorithms are to be stored as follows: "com.sun:lzjb" -> 3 "com.sun:empty" -> 4 "com.sun:gzip-1" -> 5 "com.sun:gzip-2" -> 6 "com.sun:gzip-3" -> 7 "com.sun:gzip-4" -> 8 "com.sun:gzip-5" -> 9 "com.sun:gzip-6" -> 10 "com.sun:gzip-7" -> 11 "com.sun:gzip-8" -> 12 "com.sun:gzip-9" -> 13 "com.sun:zle" -> 14 Legacy send record types are to be stored as follows: "com.sun:begin" -> 0 "com.sun:object" -> 1 "com.sun:freeobjects" -> 2 "com.sun:write" -> 3 "com.sun:free" -> 4 "com.sun:end" -> 5 "com.sun:write_byref" -> 6 "com.sun:spill" -> 7 The indirection tables for checksum algorithm, compression algorithm, and send stream record type can be implemented as follows: enum zio_checksum { ZIO_CHECKSUM_INHERIT = 0, ZIO_CHECKSUM_ON, ZIO_CHECKSUM_OFF, ZIO_CHECKSUM_LABEL, ZIO_CHECKSUM_GANG_HEADER, ZIO_CHECKSUM_ZILOG, ZIO_CHECKSUM_FLETCHER_2, ZIO_CHECKSUM_FLETCHER_4, ZIO_CHECKSUM_SHA256, ZIO_CHECKSUM_ZILOG2, ... ZIO_CHECKSUM_FUNCTIONS }; const char *zio_checksum_names[] = { /* Order must match enum zio_checksum! */ "inherit", "on", "off", "com.sun:label", "com.sun:gang_header" "com.sun:zilog" "com.sun:fletcher2" "com.sun:fletcher4" "com.sun:sha256" "com.sun:zilog2" ... }; /* * inherit, on, and off are not stored on disk, so * pre-initialize them here. Note that 8 bits are used for the * checksum algorithm in the blkptr_t, so there are 256 posible * values. */ uint8_t checksum_to_index[ZIO_CHECKSUM_FUNCTIONS] = {0, 1, 2}; enum zio_checksum index_to_checksum[256] = {0, 1, 2}; void add_checksum_algo(const char *algo_name, uint8_t value) { enum zio_checksum i; for (i = 0; i < ZIO_CHECKSUM_FUNCTIONS; i++) { if (strcmp(algo_name, zio_checksum_names[i]) == 0) { checksum_to_index[i] = value; index_to_checksum[value] = i; } } /* Ignore any unknown algorithms. */ } #define BP_GET_CHECKSUM(bp) index_to_checksum[BF64_GET(...)] #define BP_SET_CHECKSUM(bp, x) BF64_SET(..., checksum_to_index[x]) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ----- End forwarded message ----- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-fs@FreeBSD.ORG Thu May 26 11:56:19 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F71D106566C; Thu, 26 May 2011 11:56:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E58888FC14; Thu, 26 May 2011 11:56:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QBuIs3064986; Thu, 26 May 2011 11:56:18 GMT (envelope-from avg@freefall.freebsd.org) Received: (from avg@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QBuIP2064982; Thu, 26 May 2011 11:56:18 GMT (envelope-from avg) Date: Thu, 26 May 2011 11:56:18 GMT Message-Id: <201105261156.p4QBuIP2064982@freefall.freebsd.org> To: nsayer@kfu.com, avg@FreeBSD.org, freebsd-fs@FreeBSD.org From: avg@FreeBSD.org Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 11:56:19 -0000 Synopsis: boot from zfs kernel.old recovery undocumented/impossible State-Changed-From-To: open->closed State-Changed-By: avg State-Changed-When: Thu May 26 11:55:22 UTC 2011 State-Changed-Why: No change needed. http://www.freebsd.org/cgi/query-pr.cgi?pr=153804 From owner-freebsd-fs@FreeBSD.ORG Thu May 26 12:00:28 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B27106571E for ; Thu, 26 May 2011 12:00:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E42768FC0A for ; Thu, 26 May 2011 12:00:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QC0Rtx065173 for ; Thu, 26 May 2011 12:00:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QC0RLx065171; Thu, 26 May 2011 12:00:27 GMT (envelope-from gnats) Date: Thu, 26 May 2011 12:00:27 GMT Message-Id: <201105261200.p4QC0RLx065171@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 12:00:28 -0000 The following reply was made to PR kern/153804; it has been noted by GNATS. From: Andriy Gapon To: Pan Tsu , bug-followup@FreeBSD.org, Nick Sayer Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible Date: Thu, 26 May 2011 14:54:53 +0300 on 25/05/2011 11:52 Pan Tsu said the following: > Andriy Gapon writes: > >> Try the following options: >> >> 1) >> unload >> set kernel=kernel.old >> boot >> >> 2) >> unload >> load /boot/kernel.old/kernel >> load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache > > zpool_cache_type can be anything. loader(8) unlike grub2 doesn't enforce > type to be "/boot/zfs/zpool.cache". Yes, one can specify load -t anything /boot/zfs/zpool.cache and it will work. I was just on the safe side following what's done in /boot/defaults/loader.conf. >> boot > > Whatever happened to just typing following? > > boot kernel.old > > It assumes zpool.cache was already preloaded by failed attempt to boot > default kernel. No need to `unload' the kernel, `boot' replaces it. > Yes, I think that this command is a more convenient form of doing #1 above. All in all, I qualify this as a pilot error. Supported convenience methods do the right thing automatically. In the completely manual method a user should know what he is doing. Perhaps it's worth mentioning somewhere that zpool.cache must be loaded, but I think that it's a common knowledge. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 12:50:11 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C40B8106566B for ; Thu, 26 May 2011 12:50:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B32BA8FC15 for ; Thu, 26 May 2011 12:50:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QCoBf2011650 for ; Thu, 26 May 2011 12:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QCoBRr011649; Thu, 26 May 2011 12:50:11 GMT (envelope-from gnats) Date: Thu, 26 May 2011 12:50:11 GMT Message-Id: <201105261250.p4QCoBRr011649@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/155484: [ufs] GPT + UFS boot don't work well together X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 12:50:11 -0000 The following reply was made to PR kern/155484; it has been noted by GNATS. From: Andriy Gapon To: Andrey Vladimirov Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/155484: [ufs] GPT + UFS boot don't work well together Date: Thu, 26 May 2011 15:28:48 +0300 I can not reproduce your problem. This is what I did (to provide a full and clean picture unlike your original example): $ gpart create -s gpt /dev/zvol/pond/zvol2 zvol/pond/zvol2 created $ gpart add -s 64K -t freebsd-boot zvol/pond/zvol2 zvol/pond/zvol2p1 added $ gpart add -s 128m -t freebsd-swap -l swap0 zvol/pond/zvol2 zvol/pond/zvol2p2 added $ gpart add -t freebsd-ufs -l disk0 zvol/pond/zvol2 zvol/pond/zvol2p3 added $ gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 zvol/pond/zvol2 bootcode written to zvol/pond/zvol2 $ newfs /dev/zvol/pond/zvol2p3 /dev/zvol/pond/zvol2p3: 895.9MB (1834812 sectors) block size 16384, fragment size 2048 using 5 cylinder groups of 183.72MB, 11758 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376416, 752672, 1128928, 1505184 $ mount /dev/zvol/pond/zvol2p3 /mnt $ cp -a /boot /mnt/boot $ umount /mnt $ gpart show zvol/pond/zvol2 => 34 2097085 zvol/pond/zvol2 GPT (1.0G) 34 128 1 freebsd-boot (64k) 162 262144 2 freebsd-swap (128M) 262306 1834813 3 freebsd-ufs (895M) $ name -srm FreeBSD 9.0-CURRENT amd64 After this I can boot to kernel from this zvol in qemu without any problems. So either there is some pilot error, or some problems with your boot blocks or with 8GB size of the swap partition (but somehow I doubt that this is the case). Do you have a chance to play with your configuration more? If so, can you try smaller swap partition sizes (starting with 128M for example)? Can you try to use boot blocks (gptboot) from a recent head/CURRENT snapshot? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 14:40:09 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6657A1065672 for ; Thu, 26 May 2011 14:40:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3915A8FC13 for ; Thu, 26 May 2011 14:40:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QEe9UN011894 for ; Thu, 26 May 2011 14:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QEe9Rd011893; Thu, 26 May 2011 14:40:09 GMT (envelope-from gnats) Date: Thu, 26 May 2011 14:40:09 GMT Message-Id: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Nick Sayer Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nick Sayer List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:40:09 -0000 The following reply was made to PR kern/153804; it has been noted by GNATS. From: Nick Sayer To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible Date: Thu, 26 May 2011 07:31:13 -0700 Before this gets closed, is someone going to maybe add this to some = documentation somewhere? This ought to go in the handbook at the very = least. From owner-freebsd-fs@FreeBSD.ORG Thu May 26 15:20:22 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA3A310656D0 for ; Thu, 26 May 2011 15:20:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 43D048FC15 for ; Thu, 26 May 2011 15:20:21 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA22384; Thu, 26 May 2011 18:20:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE6FAE.9070601@FreeBSD.org> Date: Thu, 26 May 2011 18:20:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Sayer References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> In-Reply-To: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 15:20:23 -0000 on 26/05/2011 17:40 Nick Sayer said the following: > The following reply was made to PR kern/153804; it has been noted by GNATS. > > From: Nick Sayer > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible > Date: Thu, 26 May 2011 07:31:13 -0700 > > Before this gets closed, is someone going to maybe add this to some = > documentation somewhere? This ought to go in the handbook at the very = > least. Which part exactly? IMO, loader(8) should be sufficient. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:14:27 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41B211065670; Thu, 26 May 2011 16:14:27 +0000 (UTC) (envelope-from nsayer@kfu.com) Received: from quack.kfu.com (unknown [IPv6:2001:470:1f04:1caa::2]) by mx1.freebsd.org (Postfix) with ESMTP id EA89B8FC1C; Thu, 26 May 2011 16:14:26 +0000 (UTC) Received: from [10.45.230.80] (166-205-139-006.mobile.mymmode.com [166.205.139.6] (may be forged)) (authenticated bits=0) by quack.kfu.com (8.14.4/8.14.4) with ESMTP id p4QGEIax046840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 May 2011 09:14:25 -0700 (PDT) (envelope-from nsayer@kfu.com) X-DKIM: Sendmail DKIM Filter v2.8.3 quack.kfu.com p4QGEIax046840 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kfu.com; s=KFU; t=1306426466; bh=+6UmZVaM1PJCx2Zjy7UwgDT1Lhpj5LbdOwwEXMPO9FQ=; h=References:In-Reply-To:Mime-Version:Content-Transfer-Encoding: Content-Type:Message-Id:Cc:From:Subject:Date:To; b=ktREEGoWkQ6ct/u550e6ajCfKN5sznDi6JcVbWKVI5jseEOl9RxITKFnNV7VyL2aN hKOTFaFrsDtD1AVFXMRNZxCsjZgmAj8dJ56LkWyafQvHUUuHHjI62XfXXMTrPS50FT Onc/mcVR6RgtFHl5KDeeUmHVKe/FzydxdU2qibio= References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> <4DDE6FAE.9070601@FreeBSD.org> In-Reply-To: <4DDE6FAE.9070601@FreeBSD.org> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8J2) From: Nick Sayer Date: Thu, 26 May 2011 09:14:08 -0700 To: Andriy Gapon X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (quack.kfu.com [204.109.60.138]); Thu, 26 May 2011 09:14:26 -0700 (PDT) Cc: "freebsd-fs@FreeBSD.org" Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:14:27 -0000 1. Man pages are not helpful when the system will not boot.=20 2. The page in question does not mention the correct type argument for the z= pool.cache (nor that the type is not material). Not that it necessarily shou= ld, but in either case, loader(8) is not sufficient.=20 3. Perhaps it would be particularly helpful to print some kind of message as= to WHY the system failed to mount root - that the zpool.cache file wasn't l= oaded. That message would be good google fodder to help folks with unbootabl= e systems get back up and running.=20 All I know is that I have been without an answer as to how to recover betwee= n January and a few days ago. That suggests to me the existence of a documen= tation gap.=20 On May 26, 2011, at 8:20 AM, Andriy Gapon wrote: > on 26/05/2011 17:40 Nick Sayer said the following: >> The following reply was made to PR kern/153804; it has been noted by GNAT= S. >>=20 >> From: Nick Sayer >> To: bug-followup@FreeBSD.org >> Cc: =20 >> Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/= impossible >> Date: Thu, 26 May 2011 07:31:13 -0700 >>=20 >> Before this gets closed, is someone going to maybe add this to some =3D >> documentation somewhere? This ought to go in the handbook at the very =3D= >> least. >=20 > Which part exactly? > IMO, loader(8) should be sufficient. >=20 >=20 > --=20 > Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:20:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C85E106566B for ; Thu, 26 May 2011 16:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0C68FC18 for ; Thu, 26 May 2011 16:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QGKCr3002085 for ; Thu, 26 May 2011 16:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QGKC1j002084; Thu, 26 May 2011 16:20:12 GMT (envelope-from gnats) Date: Thu, 26 May 2011 16:20:12 GMT Message-Id: <201105261620.p4QGKC1j002084@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Simmons Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Simmons List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:20:12 -0000 The following reply was made to PR kern/153804; it has been noted by GNATS. From: Martin Simmons To: bug-followup@FreeBSD.org, nsayer@kfu.com Cc: Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible Date: Thu, 26 May 2011 17:01:10 +0100 >>>>> On Thu, 26 May 2011 18:20:14 +0300, Andriy Gapon said: > > on 26/05/2011 17:40 Nick Sayer said the following: > > > > Before this gets closed, is someone going to maybe add this to some = > > documentation somewhere? This ought to go in the handbook at the very = > > least. > > Which part exactly? > IMO, loader(8) should be sufficient. I think it should be http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-trouble.html where it currently tells you to do unload and boot with arguments that don't work for zfs... __Martin From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:25:25 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04EBD1065674 for ; Thu, 26 May 2011 16:25:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 503578FC36 for ; Thu, 26 May 2011 16:25:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23214; Thu, 26 May 2011 19:25:17 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE7EEC.5000708@FreeBSD.org> Date: Thu, 26 May 2011 19:25:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Sayer References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> <4DDE6FAE.9070601@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@FreeBSD.org" Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:25:25 -0000 on 26/05/2011 19:14 Nick Sayer said the following: > 1. Man pages are not helpful when the system will not boot. Yeah, if you have only a single system. Non-hardcopy Handbook/Wiki/etc won't help you either. > 2. The page in question does not mention the correct type argument for the > zpool.cache (nor that the type is not material). Not that it necessarily > should, but in either case, loader(8) is not sufficient. Why should it? > 3. Perhaps it would be particularly helpful to print some kind of message as to > WHY the system failed to mount root - that the zpool.cache file wasn't loaded. > That message would be good google fodder to help folks with unbootable systems > get back up and running. That's a good idea. > All I know is that I have been without an answer as to how to recover between > January and a few days ago. That suggests to me the existence of a > documentation gap. Perhaps. It also shows that you have not been researching and/or asking actively enough. If you provide reasonable patches to FreeBSD documentation they will be welcome. You can also blog/etc about your experience, so that other people could pick your knowledge via search engines. > On May 26, 2011, at 8:20 AM, Andriy Gapon wrote: > >> on 26/05/2011 17:40 Nick Sayer said the following: >>> The following reply was made to PR kern/153804; it has been noted by >>> GNATS. >>> >>> From: Nick Sayer To: bug-followup@FreeBSD.org Cc: Subject: >>> Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible >>> Date: Thu, 26 May 2011 07:31:13 -0700 >>> >>> Before this gets closed, is someone going to maybe add this to some = >>> documentation somewhere? This ought to go in the handbook at the very = >>> least. >> >> Which part exactly? IMO, loader(8) should be sufficient. >> >> >> -- Andriy Gapon -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:30:19 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7320106566B; Thu, 26 May 2011 16:30:19 +0000 (UTC) (envelope-from nsayer@kfu.com) Received: from quack.kfu.com (unknown [IPv6:2001:470:1f04:1caa::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0A38FC15; Thu, 26 May 2011 16:30:19 +0000 (UTC) Received: from nsayer-osx.silverspringnet.com (soi.silverspringnet.com [74.121.22.10]) (authenticated bits=0) by quack.kfu.com (8.14.4/8.14.4) with ESMTP id p4QGUFba047070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 May 2011 09:30:18 -0700 (PDT) (envelope-from nsayer@kfu.com) X-DKIM: Sendmail DKIM Filter v2.8.3 quack.kfu.com p4QGUFba047070 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kfu.com; s=KFU; t=1306427419; bh=BsgCkByERWe55dZuH8W65KE2IJjmG/64uUbUSgsZnjU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GmPIbGPUWoRzZ1GXJ9J/XtxNHPYg8/rwxxWhft61fTBpQ3Kt++gCmKrDx8jyD9SYm qt6mqoV9XqQH4hEg1II8h03RgnjIZNb+z/0CUd1K6GOAGw8xlZPOP/fbZVhN6O7C50 YyzH0bPTpP+khY65bKQjvmXhDhpnBRBhqNaX9Ggo= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nick Sayer In-Reply-To: <4DDE7EEC.5000708@FreeBSD.org> Date: Thu, 26 May 2011 09:30:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CEE2015-A88C-4C2E-9CE0-3FF154A7E5A5@kfu.com> References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> <4DDE6FAE.9070601@FreeBSD.org> <4DDE7EEC.5000708@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (quack.kfu.com [204.109.60.138]); Thu, 26 May 2011 09:30:19 -0700 (PDT) Cc: "freebsd-fs@FreeBSD.org" Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:30:19 -0000 On May 26, 2011, at 9:25 AM, Andriy Gapon wrote: > on 26/05/2011 19:14 Nick Sayer said the following: >> 1. Man pages are not helpful when the system will not boot. >=20 > Yeah, if you have only a single system. Non-hardcopy = Handbook/Wiki/etc won't help > you either. >=20 >> 2. The page in question does not mention the correct type argument = for the >> zpool.cache (nor that the type is not material). Not that it = necessarily >> should, but in either case, loader(8) is not sufficient. >=20 > Why should it? Did you not read the last sentence there, sparky? >=20 >> 3. Perhaps it would be particularly helpful to print some kind of = message as to >> WHY the system failed to mount root - that the zpool.cache file = wasn't loaded. >> That message would be good google fodder to help folks with = unbootable systems >> get back up and running. >=20 > That's a good idea. >=20 >> All I know is that I have been without an answer as to how to recover = between >> January and a few days ago. That suggests to me the existence of a >> documentation gap. >=20 > Perhaps. It also shows that you have not been researching and/or = asking actively > enough. I love it. I couldn't find the answer, so it's clearly my fault. > If you provide reasonable patches to FreeBSD documentation they will = be > welcome. I can't document it if I DON'T KNOW WHAT THE FRIGGING ANSWER IS! > You can also blog/etc about your experience, so that other people = could > pick your knowledge via search engines. In fact, I gave a talk at BSDCan about my experience. You'll see a = reference to this PR on the BSDCan site. >=20 >> On May 26, 2011, at 8:20 AM, Andriy Gapon wrote: >>=20 >>> on 26/05/2011 17:40 Nick Sayer said the following: >>>> The following reply was made to PR kern/153804; it has been noted = by >>>> GNATS. >>>>=20 >>>> From: Nick Sayer To: bug-followup@FreeBSD.org Cc: = Subject: >>>> Re: kern/153804: boot from zfs kernel.old recovery = undocumented/impossible=20 >>>> Date: Thu, 26 May 2011 07:31:13 -0700 >>>>=20 >>>> Before this gets closed, is someone going to maybe add this to some = =3D=20 >>>> documentation somewhere? This ought to go in the handbook at the = very =3D=20 >>>> least. >>>=20 >>> Which part exactly? IMO, loader(8) should be sufficient. >>>=20 >>>=20 >>> -- Andriy Gapon >=20 >=20 > --=20 > Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:32:24 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2125F1065670 for ; Thu, 26 May 2011 16:32:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 583708FC08 for ; Thu, 26 May 2011 16:32:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23298; Thu, 26 May 2011 19:32:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE808F.3050906@FreeBSD.org> Date: Thu, 26 May 2011 19:32:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Sayer References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> <4DDE6FAE.9070601@FreeBSD.org> <4DDE7EEC.5000708@FreeBSD.org> <6CEE2015-A88C-4C2E-9CE0-3FF154A7E5A5@kfu.com> In-Reply-To: <6CEE2015-A88C-4C2E-9CE0-3FF154A7E5A5@kfu.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@FreeBSD.org" Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:32:24 -0000 on 26/05/2011 19:30 Nick Sayer said the following: > In fact, I gave a talk at BSDCan about my experience. You'll see a reference to > this PR on the BSDCan site. Cool! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:35:18 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BA4D106564A; Thu, 26 May 2011 16:35:18 +0000 (UTC) (envelope-from nsayer@kfu.com) Received: from quack.kfu.com (unknown [IPv6:2001:470:1f04:1caa::2]) by mx1.freebsd.org (Postfix) with ESMTP id 674AD8FC0A; Thu, 26 May 2011 16:35:18 +0000 (UTC) Received: from nsayer-osx.silverspringnet.com (edge-gw-rwc.silverspringnet.com [74.121.22.10]) (authenticated bits=0) by quack.kfu.com (8.14.4/8.14.4) with ESMTP id p4QGZEji047149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 May 2011 09:35:17 -0700 (PDT) (envelope-from nsayer@kfu.com) X-DKIM: Sendmail DKIM Filter v2.8.3 quack.kfu.com p4QGZEji047149 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kfu.com; s=KFU; t=1306427718; bh=PLqZkHAmbSfJCn7rAQQYrN3tHR6tEgTQ3FlwY8YINRM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3FO+9EJFqwkY4D/Z97c4EDPGdIxnc2doccaJAohYULNJbLbzAQev7NqAJSgmkpWLq wdIaN4M2jXttftgU68W++PAnW3bb6dQv8zshJ+tZkpfpWAtm/Y4xomP5f6WTHWuxBg SEEqwm4GdghQ65uwtfhQBgGSo4OxUolCkkJKpk/Q= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nick Sayer In-Reply-To: <4DDE808F.3050906@FreeBSD.org> Date: Thu, 26 May 2011 09:35:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> <4DDE6FAE.9070601@FreeBSD.org> <4DDE7EEC.5000708@FreeBSD.org> <6CEE2015-A88C-4C2E-9CE0-3FF154A7E5A5@kfu.com> <4DDE808F.3050906@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (quack.kfu.com [204.109.60.138]); Thu, 26 May 2011 09:35:18 -0700 (PDT) Cc: "freebsd-fs@FreeBSD.org" Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:35:18 -0000 Yes. What a shame that I couldn't provide my audience the correct = solution at the time BECAUSE IT WASN'T DOCUMENTED WELL ENOUGH! On May 26, 2011, at 9:32 AM, Andriy Gapon wrote: > on 26/05/2011 19:30 Nick Sayer said the following: >> In fact, I gave a talk at BSDCan about my experience. You'll see a = reference to >> this PR on the BSDCan site. >=20 > Cool! >=20 > --=20 > Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:36:38 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C4B6106567E for ; Thu, 26 May 2011 16:36:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 65E5C8FC1B for ; Thu, 26 May 2011 16:36:36 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23351; Thu, 26 May 2011 19:36:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE8191.6080503@FreeBSD.org> Date: Thu, 26 May 2011 19:36:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Martin Simmons References: <201105261620.p4QGKC1j002084@freefall.freebsd.org> In-Reply-To: <201105261620.p4QGKC1j002084@freefall.freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:36:38 -0000 on 26/05/2011 19:20 Martin Simmons said the following: > I think it should be > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-trouble.html > > where it currently tells you to do unload and boot with arguments that don't > work for zfs... Oh, yes, thanks for the pointer - we should fix that. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:42:15 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2794C106564A for ; Thu, 26 May 2011 16:42:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 723078FC0A for ; Thu, 26 May 2011 16:42:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23426; Thu, 26 May 2011 19:42:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE82DF.2020408@FreeBSD.org> Date: Thu, 26 May 2011 19:42:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Sayer References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> <4DDE6FAE.9070601@FreeBSD.org> <4DDE7EEC.5000708@FreeBSD.org> <6CEE2015-A88C-4C2E-9CE0-3FF154A7E5A5@kfu.com> <4DDE808F.3050906@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@FreeBSD.org" Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:42:15 -0000 on 26/05/2011 19:35 Nick Sayer said the following: > Yes. What a shame that I couldn't provide my audience the correct solution at > the time BECAUSE IT WASN'T DOCUMENTED WELL ENOUGH! Yes, I got it. Just curious - nobody in the audience knew any of the solutions? > On May 26, 2011, at 9:32 AM, Andriy Gapon wrote: > >> on 26/05/2011 19:30 Nick Sayer said the following: >>> In fact, I gave a talk at BSDCan about my experience. You'll see a >>> reference to this PR on the BSDCan site. >> >> Cool! >> >> -- Andriy Gapon > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:48:36 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D221106566C; Thu, 26 May 2011 16:48:36 +0000 (UTC) (envelope-from nsayer@kfu.com) Received: from quack.kfu.com (unknown [IPv6:2001:470:1f04:1caa::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8898FC12; Thu, 26 May 2011 16:48:36 +0000 (UTC) Received: from nsayer-osx.silverspringnet.com (soi.silverspringnet.com [74.121.22.10]) (authenticated bits=0) by quack.kfu.com (8.14.4/8.14.4) with ESMTP id p4QGmWdi047344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 May 2011 09:48:35 -0700 (PDT) (envelope-from nsayer@kfu.com) X-DKIM: Sendmail DKIM Filter v2.8.3 quack.kfu.com p4QGmWdi047344 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kfu.com; s=KFU; t=1306428516; bh=P2GDqzlW1Jiaf5CZNU50SrcKsIRqbsrwfN9hH4lQGnY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xdyjW8e11S7eMyJ0IVj6AwEKL7kzf77G04wfnvbnjtphDanmKuWGOwXFthQ64UQ6m zgBbw+YuUvrrO93eUjcG84pQsWcVaHOEcc5TZRPpKw46rNSbb/KK5VBA48VkrdaZhj iHZqBz1S0os5n83gHGs7nlv+3zcvvaA9tw7CR7W8= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nick Sayer In-Reply-To: <4DDE82DF.2020408@FreeBSD.org> Date: Thu, 26 May 2011 09:48:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69C8DC5C-7D76-4055-8E5E-B6E9BA6501DF@kfu.com> References: <201105261440.p4QEe9Rd011893@freefall.freebsd.org> <4DDE6FAE.9070601@FreeBSD.org> <4DDE7EEC.5000708@FreeBSD.org> <6CEE2015-A88C-4C2E-9CE0-3FF154A7E5A5@kfu.com> <4DDE808F.3050906@FreeBSD.org> <4DDE82DF.2020408@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (quack.kfu.com [204.109.60.138]); Thu, 26 May 2011 09:48:36 -0700 (PDT) Cc: "freebsd-fs@FreeBSD.org" Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:48:36 -0000 If they did, they didn't say anything. To be fair, the audience was about 20 people, by my estimation. But one = of them was a guy (alas, I didn't get his name at the time) who clearly = had a lot of experience with ZFS, and he didn't chime in with an answer. On May 26, 2011, at 9:42 AM, Andriy Gapon wrote: > on 26/05/2011 19:35 Nick Sayer said the following: >> Yes. What a shame that I couldn't provide my audience the correct = solution at >> the time BECAUSE IT WASN'T DOCUMENTED WELL ENOUGH! >=20 > Yes, I got it. > Just curious - nobody in the audience knew any of the solutions? >=20 >> On May 26, 2011, at 9:32 AM, Andriy Gapon wrote: >>=20 >>> on 26/05/2011 19:30 Nick Sayer said the following: >>>> In fact, I gave a talk at BSDCan about my experience. You'll see a >>>> reference to this PR on the BSDCan site. >>>=20 >>> Cool! >>>=20 >>> -- Andriy Gapon >>=20 >=20 >=20 > --=20 > Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 26 16:54:24 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 856B91065672 for ; Thu, 26 May 2011 16:54:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D26E78FC15 for ; Thu, 26 May 2011 16:54:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23599; Thu, 26 May 2011 19:54:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE85BC.40407@FreeBSD.org> Date: Thu, 26 May 2011 19:54:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Martin Simmons References: <201105261620.p4QGKC1j002084@freefall.freebsd.org> <4DDE8191.6080503@FreeBSD.org> In-Reply-To: <4DDE8191.6080503@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-doc@FreeBSD.org Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:54:24 -0000 on 26/05/2011 19:36 Andriy Gapon said the following: > on 26/05/2011 19:20 Martin Simmons said the following: >> I think it should be >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-trouble.html >> >> where it currently tells you to do unload and boot with arguments that don't >> work for zfs... > > Oh, yes, thanks for the pointer - we should fix that. I would change it like this: Index: kernelconfig/chapter.sgml =================================================================== RCS file: /usr/devel/fcvs/doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml,v retrieving revision 1.196 diff -u -r1.196 chapter.sgml --- kernelconfig/chapter.sgml 8 Mar 2011 17:46:12 -0000 1.196 +++ kernelconfig/chapter.sgml 26 May 2011 16:50:19 -0000 @@ -1494,10 +1494,8 @@ the &os; boot loader. You can access this when the system boot menu appears. Select the Escape to a loader prompt option, number six. At the prompt, type - unload kernel - and then type - boot /boot/kernel.old/kernel, - or the filename of any other kernel that will boot properly. + boot kernel.old, + or the name of any other kernel that will boot properly. When reconfiguring a kernel, it is always a good idea to keep a kernel that is known to work on hand. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri May 27 02:17:54 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F6921065673 for ; Fri, 27 May 2011 02:17:54 +0000 (UTC) (envelope-from dpd@bitgravity.com) Received: from mail1.sjc1.bitgravity.com (mail1.sjc1.bitgravity.com [209.131.97.19]) by mx1.freebsd.org (Postfix) with ESMTP id 65D1F8FC18 for ; Fri, 27 May 2011 02:17:54 +0000 (UTC) Received: from mail-pw0-f45.google.com ([209.85.160.45]) by mail1.sjc1.bitgravity.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QPm8V-0005PN-12 for freebsd-fs@freebsd.org; Thu, 26 May 2011 18:46:47 -0700 Received: by pwi6 with SMTP id 6so751308pwi.18 for ; Thu, 26 May 2011 18:46:41 -0700 (PDT) Received: by 10.68.27.71 with SMTP id r7mr507981pbg.385.1306460801542; Thu, 26 May 2011 18:46:41 -0700 (PDT) Received: from netops-199.sfo1.bitgravity.com (netops-199.sfo1.bitgravity.com [209.131.110.199]) by mx.google.com with ESMTPS id m9sm75087pbd.87.2011.05.26.18.46.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 18:46:40 -0700 (PDT) From: David P Discher Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2011 18:46:37 -0700 Message-Id: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 02:17:54 -0000 Hello FS list: We've been using ZFS v3, storage pool v14 with FreeBSD 8.1-RELEASE with = fairly good results for over a year. We have been moving more and more = of our storage to ZFS. Last week, I believe we hit another issue with = LBOLT. The original which was first reported by Artem Belevich for = l2arc_feed_thread : - = http://lists.freebsd.org/pipermail/freebsd-fs/2011-January/010558.html But this also affects the arc_reclaim_thread as well. The guys over at = iX Systems helped out and pointed me to this patch : - http://people.freebsd.org/~delphij/misc/218180.diff which typedef's clock_t to int64_t. However, the arc_reclaim_thread does not have a ~24 day rollover - it = does not use clock_t. I think this rollover in the integer results in = LBOLT going negative, after about 106-107 days. We haven't noticed this = until actually 112-115 days of uptime. I think it is also related to L1 = ARC sizing, and load. Our systems with arc set to min-max of 512M/2G = ARC haven't developed the issue - at least the CPU hogging thread - but = the systems with 12G+ of ARC, and lots of rsync and du activity along = side of random reads from the zpool develop the issue. The problem is slight different, and possibly more harmful than the = l2arc feeder issue seen with LBOLT.=20 in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, the arc_evict() = function, under "evict_start:" has this loop to walk the arc cache page = list: 1708 for (ab =3D list_tail(list); ab; ab =3D ab_prev) { 1709 ab_prev =3D list_prev(list, ab); 1710 bytes_remaining -=3D (ab->b_size * = ab->b_datacnt); 1711 /* prefetch buffers have a minimum lifespan = */ 1712 if (HDR_IO_IN_PROGRESS(ab) || 1713 (spa && ab->b_spa !=3D spa) || 1714 (ab->b_flags & = (ARC_PREFETCH|ARC_INDIRECT) && 1715 LBOLT - ab->b_arc_access < = arc_min_prefetch_lifespan)) { 1716 skipped++; 1717 continue; 1718 } Now, when LBOLT is negative, with some degree of jitter/randomness, this = loop short-circuts, resulting in high CPU usage. Also the ARC buffers = may not get evicted on-time, or possibly at all. One system I had, all = processes to the zpool where waiting on D-state, and the = arc_reclaim_thread was stuck at 100%. du and rysnc seem to help = aggravate this issue. On an affected system : > top -SHb 500 | grep arc_reclaim_thr 95 root -8 - 0K 60K arc_re 3 102.9H 96.39% = {arc_reclaim_thre} Conveniently, "skipped++" is surfaced via a sysctl, here's two queries = to it on this system with the arc reclaim thread running hot (a du going = too at the same time ), 60 seconds in between : kstat.zfs.misc.arcstats.evict_skip: 4117714520450 kstat.zfs.misc.arcstats.evict_skip: 4118188257434 > uptime 3:51PM up 116 days, 23:48, 3 users, load averages: 1.30, 0.96, 0.64 After chatting with someone else well respected in the community, he = proposed an alternative fix. I'm vetting here to make sure there isn't = something deeper in the code that could get bitten by, as well as some = clarification :=20 in: ./sys/cddl/compat/opensolaris/sys/time.h=20 the relevant parts are: 41 #define LBOLT ((gethrtime() * hz) / NANOSEC) ... =20 54 static __inline hrtime_t 55 gethrtime(void) { 56=20 57 struct timespec ts; 58 hrtime_t nsec; 59=20 60 #if 1 61 getnanouptime(&ts); 62 #else 63 nanouptime(&ts); 64 #endif 65 nsec =3D (hrtime_t)ts.tv_sec * NANOSEC + ts.tv_nsec; 66 return (nsec); 67 } QUESTION - what units is LBOLT suppose to be ? If gethrtime() is = returning nanoseconds, why is nanoseconds getting multiplied by hz ? If = LBOLT is suppose to be clock-ticks (which is what arc.c looks like it = wants it in) then it really should be : #define LBOLT ( (gethrtime() / NANOSEC) * hz ) But if that is case, then why make the call to getnanouptime() at all ? = If LBOLT is number of clock ticks, then can't this just be a query to = uptime in seconds ? So how about something like this: #define LBOLT (time_uptime * hz) I've applied this changed locally, and did a basic stress test with our = load generator in the lab, thrashing the arc cache. (96GB RAM, 48G = min/max for ARC) It seems to have no ill effects - though, will have to = wait 4-months before declaring the actual issue here fixed. I'm hoping = to put this in production next week. All this above is on 8.1-RELEASE. ZFS v28 changed some of this, but = still didn't improve lbolt: - = http://svnweb.freebsd.org/base/head/sys/cddl/compat/opensolaris/sys/time.h= ?revision=3D221991&view=3Dmarkup 65 #define ddi_get_lbolt() ((gethrtime() * hz) / = NANOSEC) 66 #define ddi_get_lbolt64() (int64_t)((gethrtime() * = hz) / NANOSEC) It would seem, the same optimization could be done here too: #define ddi_get_lbolt() (time_uptime * hz) #define ddi_get_lbolt64() (int64_t)(time_uptime * = hz) With saving the call to getnanouptime() a multiple and divide, there = should be a couple hundred cycle performance improvement here. I don't = claim this would be noticeable, but seems like a simple, straight = forward optimization.=20 clock_t will still need the typedef'ed to 64bit to still address the = l2arc usage of LBOLT. Thanks ! --- David P. Discher dpd@bitgravity.com * AIM: bgDavidDPD BITGRAVITY * http://www.bitgravity.com From owner-freebsd-fs@FreeBSD.ORG Fri May 27 04:06:04 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9C5A1065672 for ; Fri, 27 May 2011 04:06:04 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 625A28FC0A for ; Fri, 27 May 2011 04:06:04 +0000 (UTC) Received: by yxl31 with SMTP id 31so731375yxl.13 for ; Thu, 26 May 2011 21:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zskmKtnZrjTf+TyyxASh2EjNREwNaHGGEWaKWz1itLs=; b=ECKYbfy19h6wF2jgoRHqxuNzfrerQgFFh6aR2R7AzfH1IKKhojrAQpau099KVHpkb6 rvYM2poYVQy0qbe57sbI1IWqK6vvB9UIWdkJKf2ELeVazCzN6n8KALkvhjMiz/NmnPgL rkCapc7BoWaFS68lfKmoChb3gUuipYPZutJCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MptNPonl0w+zWemK3d0c6z9LQ/rrHqoVs8/WvPRp7jwt3Gwnx6Qym+m4UoRpcxo6S9 XQdcl6/wEdRfgV7BA/VPO+Fw9aIw/fjBc2f8oB0fUyzD2qfOF+m1DqXajsF1ne7+t1dS Mvzc+fnyej3Ugj52yMy693roq3RFxr+T3KMRE= MIME-Version: 1.0 Received: by 10.236.70.72 with SMTP id o48mr1951915yhd.512.1306469163366; Thu, 26 May 2011 21:06:03 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.209.165 with HTTP; Thu, 26 May 2011 21:06:03 -0700 (PDT) In-Reply-To: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> Date: Thu, 26 May 2011 21:06:03 -0700 X-Google-Sender-Auth: F57sUesPP8v_0ZNoi6Eqt_W_w18 Message-ID: From: Artem Belevich To: David P Discher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 04:06:04 -0000 On Thu, May 26, 2011 at 6:46 PM, David P Discher wrote= : > Hello FS list: > > We've been using ZFS v3, storage pool v14 with FreeBSD 8.1-RELEASE with f= airly good results for over a year. =A0We have been moving more and more of= our storage to ZFS. =A0Last week, I believe we hit another issue with LBOL= T. > > The original which was first reported by Artem Belevich for l2arc_feed_th= read : > > =A0- http://lists.freebsd.org/pipermail/freebsd-fs/2011-January/010558.ht= ml > > But this also affects the arc_reclaim_thread as well. The guys over at iX= Systems helped out and pointed me to this patch : > > =A0- http://people.freebsd.org/~delphij/misc/218180.diff > > which typedef's clock_t to int64_t. > > However, the arc_reclaim_thread does not have a ~24 day rollover - it doe= s not use clock_t. =A0I think this rollover in the integer results in LBOLT= going negative, after about 106-107 days. =A0We haven't noticed this until= actually 112-115 days of uptime. =A0I think it is also related to L1 ARC s= izing, and load. =A0Our systems with arc set to min-max of =A0512M/2G ARC h= aven't developed the issue - at least the CPU hogging thread - but the syst= ems with 12G+ of ARC, and lots of rsync and du activity along side of rando= m reads from the zpool develop the issue. > > The problem is slight different, and possibly more harmful than the l2arc= feeder issue seen with LBOLT. > > in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, the arc_evict() = function, under "evict_start:" has this loop to walk the arc cache page lis= t: > > =A0 =A0 =A0 =A01708 =A0 =A0 =A0 =A0 for (ab =3D list_tail(list); ab; ab = =3D ab_prev) { > =A0 =A0 =A0 =A01709 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ab_prev =3D list_prev= (list, ab); > =A0 =A0 =A0 =A01710 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bytes_remaining -=3D = (ab->b_size * ab->b_datacnt); > =A0 =A0 =A0 =A01711 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* prefetch buffers h= ave a minimum lifespan */ > =A0 =A0 =A0 =A01712 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (HDR_IO_IN_PROGRES= S(ab) || > =A0 =A0 =A0 =A01713 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (spa && ab->b= _spa !=3D spa) || > =A0 =A0 =A0 =A01714 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ab->b_flags = & (ARC_PREFETCH|ARC_INDIRECT) && > =A0 =A0 =A0 =A01715 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LBOLT - ab->b= _arc_access < arc_min_prefetch_lifespan)) { > =A0 =A0 =A0 =A01716 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 skipp= ed++; > =A0 =A0 =A0 =A01717 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 conti= nue; > =A0 =A0 =A0 =A01718 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > > > Now, when LBOLT is negative, with some degree of jitter/randomness, this = loop short-circuts, resulting in high CPU usage. =A0Also the ARC buffers ma= y not get evicted on-time, or possibly at all. =A0One system I had, all pro= cesses to the zpool where waiting on D-state, and the arc_reclaim_thread wa= s stuck at 100%. =A0du and rysnc seem to help aggravate this issue. =A0On a= n affected system : > >> top -SHb 500 | grep arc_reclaim_thr > =A0 95 root =A0 =A0 =A0 =A0 =A0 -8 =A0 =A0- =A0 =A0 0K =A0 =A060K arc_re = =A03 102.9H 96.39% {arc_reclaim_thre} > > Conveniently, "skipped++" is surfaced via a sysctl, here's two queries to= it on this system with the arc reclaim thread running hot (a du going too = at the same time ), 60 seconds in between : > > =A0kstat.zfs.misc.arcstats.evict_skip: 4117714520450 > =A0kstat.zfs.misc.arcstats.evict_skip: 4118188257434 > >> uptime > =A03:51PM =A0up 116 days, 23:48, 3 users, load averages: 1.30, 0.96, 0.64 > > After chatting with someone else well respected in the community, he prop= osed an alternative fix. =A0I'm vetting here to make sure there isn't somet= hing deeper in the code that could get bitten by, as well as some clarifica= tion : > > in: > ./sys/cddl/compat/opensolaris/sys/time.h > > the relevant parts are: > > =A0 =A0 =A0 =A0 41 #define LBOLT =A0 ((gethrtime() * hz) / NANOSEC) > =A0 =A0 =A0 =A0 ... > > =A0 =A0 =A0 =A0 54 static __inline hrtime_t > =A0 =A0 =A0 =A0 55 gethrtime(void) { > =A0 =A0 =A0 =A0 56 > =A0 =A0 =A0 =A0 57 =A0 =A0 =A0 =A0 struct timespec ts; > =A0 =A0 =A0 =A0 58 =A0 =A0 =A0 =A0 hrtime_t nsec; > =A0 =A0 =A0 =A0 59 > =A0 =A0 =A0 =A0 60 #if 1 > =A0 =A0 =A0 =A0 61 =A0 =A0 =A0 =A0 getnanouptime(&ts); > =A0 =A0 =A0 =A0 62 #else > =A0 =A0 =A0 =A0 63 =A0 =A0 =A0 =A0 nanouptime(&ts); > =A0 =A0 =A0 =A0 64 #endif > =A0 =A0 =A0 =A0 65 =A0 =A0 =A0 =A0 nsec =3D (hrtime_t)ts.tv_sec * NANOSEC= + ts.tv_nsec; Yup. This would indeed overflow in ~106.75 days. > =A0 =A0 =A0 =A0 66 =A0 =A0 =A0 =A0 return (nsec); > =A0 =A0 =A0 =A0 67 } > > QUESTION - what units is LBOLT suppose to be ? =A0If gethrtime() is retur= ning nanoseconds, why is nanoseconds getting multiplied by hz ? =A0If LBOLT= is suppose to be clock-ticks (which is what arc.c looks like it wants it i= n) then it really should be : > > =A0 =A0 =A0 =A0 #define LBOLT =A0 ( (gethrtime() / NANOSEC) * hz ) > > But if that is case, then why make the call to getnanouptime() at all ? = =A0If LBOLT is number of clock ticks, then can't this just be a query to up= time in seconds ? =A0So how about something like this: > > =A0 =A0 =A0 =A0#define LBOLT =A0 (time_uptime * hz) I believe lbolt used to hold number of ticks on solaris, though they switched to tickless kernel some time back and got rid of lbolt. > > I've applied this changed locally, and did a basic stress test with our l= oad generator in the lab, thrashing the arc cache. (96GB RAM, 48G min/max f= or ARC) It seems to have no ill effects - though, will have to wait 4-month= s before declaring the actual issue here fixed. =A0I'm hoping to put this i= n production next week. > > All this above is on 8.1-RELEASE. ZFS v28 changed some of this, but still= didn't improve lbolt: > > =A0- http://svnweb.freebsd.org/base/head/sys/cddl/compat/opensolaris/sys/= time.h?revision=3D221991&view=3Dmarkup > > =A0 =A0 =A0 =A065 =A0 =A0 =A0#define ddi_get_lbolt() =A0 =A0 =A0 =A0 ((ge= thrtime() * hz) / NANOSEC) > =A0 =A0 =A0 =A066 =A0 =A0 =A0#define ddi_get_lbolt64() =A0 =A0 =A0 (int64= _t)((gethrtime() * hz) / NANOSEC) > > It would seem, the same optimization could be done here too: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#define ddi_get_lbolt() =A0 =A0 =A0 =A0 (t= ime_uptime * hz) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#define ddi_get_lbolt64() =A0 =A0 =A0 (int= 64_t)(time_uptime * hz) > > With saving the call to getnanouptime() a multiple and divide, there shou= ld be a couple hundred cycle performance improvement here. =A0I don't claim= this would be noticeable, but seems like a simple, straight forward optimi= zation. The side effect is that it limits bolt resolution to hz units. With HZ=3D100, that will be 10ms. Whether it's good enough or too coarse I have no idea. Perhaps we can compromise and update lbolt in microseconds. That should give us few hundred years until the overflow. --Artem > > clock_t will still need the typedef'ed to 64bit to still address the l2ar= c usage of LBOLT. > > Thanks ! > > --- > David P. Discher > dpd@bitgravity.com * AIM: bgDavidDPD > BITGRAVITY * http://www.bitgravity.com > > _______________________________________________ > 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 Fri May 27 14:05:39 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90201065675; Fri, 27 May 2011 14:05:39 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0C98FC0C; Fri, 27 May 2011 14:05:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4RE5dT2057616; Fri, 27 May 2011 14:05:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4RE5dZ8057612; Fri, 27 May 2011 14:05:39 GMT (envelope-from linimon) Date: Fri, 27 May 2011 14:05:39 GMT Message-Id: <201105271405.p4RE5dZ8057612@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/157365: [nfs] cannot umount an nfs from dead server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 14:05:39 -0000 Synopsis: [nfs] cannot umount an nfs from dead server Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 27 14:05:12 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=157365