From owner-freebsd-fs@FreeBSD.ORG Sun Apr 24 05:30:43 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 A1538106564A; Sun, 24 Apr 2011 05:30:43 +0000 (UTC) (envelope-from konstantin.kuklin@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 451808FC0A; Sun, 24 Apr 2011 05:30:43 +0000 (UTC) Received: by yie12 with SMTP id 12so541333yie.13 for ; Sat, 23 Apr 2011 22:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=dP1/iLiY4E1Q+uzkeNk2TO69XhzyoVqg9hB1J8vq1EI=; b=hKYYW/TgA6mvpKsNYL9Fe69rF7s9z0GTrAGJQ+3SiS4+Xx3hjPob0ZoztA8+2hO3T+ weocBlu+DNDsEZEAvvz4afTNa3qy6sZ38eg5YK4gA36H3FEDoEpWxGS3dI4/XTA0ZCKV jRzlRX91bVVt5M30uQeCrY5Bjn0uuHQj2hr40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OkL5o09T1cCNcnDNayQl/iOmgaK4/u0m7RtnKaJsCpRrc2OWdVSuorzkV0s4++3ZjN VNNvPN7zvKr2R/2sSMDMNZy1U6Qa6f+KY9IyhaJ9mOUEl9EVG3EprlrBAcU/ArIEkjjy AOWmVPgnDQsy5TIiGmdtMt15tsfOoRkeryaU8= MIME-Version: 1.0 Received: by 10.150.163.20 with SMTP id l20mr2375164ybe.249.1303621387565; Sat, 23 Apr 2011 22:03:07 -0700 (PDT) Received: by 10.147.34.17 with HTTP; Sat, 23 Apr 2011 22:03:07 -0700 (PDT) Date: Sun, 24 Apr 2011 09:03:07 +0400 Message-ID: From: Konstantin Kuklin To: freebsd-fs@freebsd.org, pjd@freebsd.org, mm@freebsd.org, zfs-discuss@opensolaris.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: zfs problem vdev I/O failure 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, 24 Apr 2011 05:30:43 -0000 Good morning, I have a problem with ZFS: ZFS filesystem version 4 ZFS storage pool version 15 Yesterday my comp with Freebsd 8.2 releng shutdown with ad4 error detached,when I copy a big file... and after reboot in 2 wd green 1tb say me goodbye. One of them die and other with zfs errors: Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=187921768448 size=512 error=6 Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=187921768960 size=512 error=6 Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=311738368 size=21504 error=6 Apr 24 04:53:41 Flash root: ZFS: zpool I/O failure, zpool=zroot error=6 Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset= size= error= Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=635155456 size=3072 error=6 Apr 24 04:53:41 Flash root: ZFS: zpool I/O failure, zpool=zroot error=6 Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset= size= error= Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=635158528 size=12288 error=6 Apr 24 04:53:41 Flash root: ZFS: zpool I/O failure, zpool=zroot error=6 Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset= size= error= Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=635170816 size=512 error=6 Apr 24 04:53:41 Flash root: ZFS: zpool I/O failure, zpool=zroot error=6 Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset= size= error= Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=635171328 size=512 error=6 Apr 24 04:53:41 Flash root: ZFS: vdev I/O failure, zpool=zroot path= offset=635171840 size=512 error=6 Apr 24 04:53:41 Flash root: ZFS: zpool I/O failure, zpool=zroot error=6 zpool status: Flash# zpool status pool: zroot state: DEGRADED status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'. see: http://www.sun.com/msg/ZFS-8000-HC scrub: resilver in progress for 0h6m, 0.00% done, 1582566h29m to go config: NAME STATE READ WRITE CKSUM zroot DEGRADED 12 0 1 mirror DEGRADED 36 0 4 7159451150335751026 UNAVAIL 0 0 0 was /dev/gpt/disk0 gpt/disk1 ONLINE 0 0 40 errors: 12 data errors, use '-v' for a list Zpool scrub freeze and time to resilver up in time... How i can repair it, if zpool scrub -s zroot and detach don`t work...and don`t work all of zfs commands =\ Thx From owner-freebsd-fs@FreeBSD.ORG Sun Apr 24 09:51:56 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 9275E106564A for ; Sun, 24 Apr 2011 09:51:56 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDD58FC18 for ; Sun, 24 Apr 2011 09:51:55 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QDvys-000N28-P7 for freebsd-fs@freebsd.org; Sun, 24 Apr 2011 11:51:54 +0200 Date: Sun, 24 Apr 2011 11:49:47 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <223111974.20110424114947@nitronet.pl> To: Konstantin Kuklin In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, pjd@freebsd.org Subject: Re: zfs problem vdev I/O failure 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, 24 Apr 2011 09:51:56 -0000 Hi Konstantin, > zpool status: > Flash# zpool status > pool: zroot > state: DEGRADED > status: One or more devices are faulted in response to IO failures. > action: Make sure the affected devices are connected, then run 'zpool > clear'. > see: http://www.sun.com/msg/ZFS-8000-HC > scrub: resilver in progress for 0h6m, 0.00% done, 1582566h29m to go > config: > NAME STATE READ WRITE CKSUM > zroot DEGRADED 12 0 1 > mirror DEGRADED 36 0 4 > 7159451150335751026 UNAVAIL 0 0 0 was > /dev/gpt/disk0 > gpt/disk1 ONLINE 0 0 40 > errors: 12 data errors, use '-v' for a list > Zpool scrub freeze and time to resilver up in time... > How i can repair it, if zpool scrub -s zroot and detach don`t work...and > don`t work all of zfs commands =\ Try booting mfsBSD and fixing there, http://mfsbsd.vx.sk/ http://mfsbsd.vx.sk/iso/mfsbsd-8.2-zfsv28-i386.iso http://mfsbsd.vx.sk/iso/mfsbsd-se-8.2-zfsv28-amd64.iso From owner-freebsd-fs@FreeBSD.ORG Sun Apr 24 11:10:07 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 258CE106566B for ; Sun, 24 Apr 2011 11:10:07 +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 0DC7F8FC13 for ; Sun, 24 Apr 2011 11:10:07 +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 p3OBA7wT045164 for ; Sun, 24 Apr 2011 11:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3OBA76o045163; Sun, 24 Apr 2011 11:10:07 GMT (envelope-from gnats) Date: Sun, 24 Apr 2011 11:10:07 GMT Message-Id: <201104241110.p3OBA76o045163@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/156545: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 11:10:07 -0000 The following reply was made to PR kern/156545; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/156545: commit references a PR Date: Sun, 24 Apr 2011 11:02:04 +0000 (UTC) Author: kib Date: Sun Apr 24 11:01:42 2011 New Revision: 220986 URL: http://svn.freebsd.org/changeset/base/220986 Log: Merge the part of r207141 that fixes the locking for ufs_rename() (and r218838 followup). Adopt the SU calls to the stable/8 SU implementation, with the help from Kirk. PR: kern/156545 Reviewed by: mckusick Tested by: pho Modified: stable/8/sys/ufs/ufs/inode.h stable/8/sys/ufs/ufs/ufs_extern.h stable/8/sys/ufs/ufs/ufs_lookup.c stable/8/sys/ufs/ufs/ufs_vnops.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/ufs/ufs/inode.h ============================================================================== --- stable/8/sys/ufs/ufs/inode.h Sun Apr 24 10:47:56 2011 (r220985) +++ stable/8/sys/ufs/ufs/inode.h Sun Apr 24 11:01:42 2011 (r220986) @@ -120,7 +120,7 @@ struct inode { #define IN_CHANGE 0x0002 /* Inode change time update request. */ #define IN_UPDATE 0x0004 /* Modification time update request. */ #define IN_MODIFIED 0x0008 /* Inode has been modified. */ -#define IN_RENAME 0x0010 /* Inode is being renamed. */ +#define IN_NEEDSYNC 0x0010 /* Inode requires fsync. */ #define IN_LAZYMOD 0x0040 /* Modified, but don't write yet. */ #define IN_SPACECOUNTED 0x0080 /* Blocks to be freed in free count. */ #define IN_LAZYACCESS 0x0100 /* Process IN_ACCESS after the Modified: stable/8/sys/ufs/ufs/ufs_extern.h ============================================================================== --- stable/8/sys/ufs/ufs/ufs_extern.h Sun Apr 24 10:47:56 2011 (r220985) +++ stable/8/sys/ufs/ufs/ufs_extern.h Sun Apr 24 11:01:42 2011 (r220986) @@ -57,7 +57,7 @@ int ufs_bmap(struct vop_bmap_args *); int ufs_bmaparray(struct vnode *, ufs2_daddr_t, ufs2_daddr_t *, struct buf *, int *, int *); int ufs_fhtovp(struct mount *, struct ufid *, struct vnode **); -int ufs_checkpath(ino_t, struct inode *, struct ucred *); +int ufs_checkpath(ino_t, ino_t, struct inode *, struct ucred *, ino_t *); void ufs_dirbad(struct inode *, doff_t, char *); int ufs_dirbadentry(struct vnode *, struct direct *, int); int ufs_dirempty(struct inode *, ino_t, struct ucred *); @@ -66,9 +66,11 @@ int ufs_extwrite(struct vop_write_args void ufs_makedirentry(struct inode *, struct componentname *, struct direct *); int ufs_direnter(struct vnode *, struct vnode *, struct direct *, - struct componentname *, struct buf *); + struct componentname *, struct buf *, int); int ufs_dirremove(struct vnode *, struct inode *, int, int); int ufs_dirrewrite(struct inode *, struct inode *, ino_t, int, int); +int ufs_lookup_ino(struct vnode *, struct vnode **, struct componentname *, + ino_t *); int ufs_getlbns(struct vnode *, ufs2_daddr_t, struct indir *, int *); int ufs_inactive(struct vop_inactive_args *); int ufs_init(struct vfsconf *); Modified: stable/8/sys/ufs/ufs/ufs_lookup.c ============================================================================== --- stable/8/sys/ufs/ufs/ufs_lookup.c Sun Apr 24 10:47:56 2011 (r220985) +++ stable/8/sys/ufs/ufs/ufs_lookup.c Sun Apr 24 11:01:42 2011 (r220986) @@ -76,9 +76,6 @@ SYSCTL_INT(_debug, OID_AUTO, dircheck, C /* true if old FS format...*/ #define OFSFMT(vp) ((vp)->v_mount->mnt_maxsymlinklen <= 0) -static int ufs_lookup_(struct vnode *, struct vnode **, struct componentname *, - ino_t *); - #ifdef QUOTA static int ufs_lookup_upgrade_lock(struct vnode *vp) @@ -214,11 +211,11 @@ ufs_lookup(ap) } */ *ap; { - return (ufs_lookup_(ap->a_dvp, ap->a_vpp, ap->a_cnp, NULL)); + return (ufs_lookup_ino(ap->a_dvp, ap->a_vpp, ap->a_cnp, NULL)); } -static int -ufs_lookup_(struct vnode *vdp, struct vnode **vpp, struct componentname *cnp, +int +ufs_lookup_ino(struct vnode *vdp, struct vnode **vpp, struct componentname *cnp, ino_t *dd_ino) { struct inode *dp; /* inode for directory being searched */ @@ -556,6 +553,8 @@ notfound: return (ENOENT); found: + if (dd_ino != NULL) + *dd_ino = ino; if (numdirpasses == 2) nchstats.ncs_pass2++; /* @@ -578,11 +577,6 @@ found: if ((flags & ISLASTCN) && nameiop == LOOKUP) dp->i_diroff = i_offset &~ (DIRBLKSIZ - 1); - if (dd_ino != NULL) { - *dd_ino = ino; - return (0); - } - /* * If deleting, and at end of pathname, return * parameters which can be used to remove file. @@ -590,17 +584,6 @@ found: if (nameiop == DELETE && (flags & ISLASTCN)) { if (flags & LOCKPARENT) ASSERT_VOP_ELOCKED(vdp, __FUNCTION__); - if ((error = VFS_VGET(vdp->v_mount, ino, - LK_EXCLUSIVE, &tdp)) != 0) - return (error); - - error = ufs_delete_denied(vdp, tdp, cred, cnp->cn_thread); - if (error) { - vput(tdp); - return (error); - } - - /* * Return pointer to current entry in dp->i_offset, * and distance past previous entry (if there @@ -617,6 +600,16 @@ found: dp->i_count = 0; else dp->i_count = dp->i_offset - prevoff; + if (dd_ino != NULL) + return (0); + if ((error = VFS_VGET(vdp->v_mount, ino, + LK_EXCLUSIVE, &tdp)) != 0) + return (error); + error = ufs_delete_denied(vdp, tdp, cred, cnp->cn_thread); + if (error) { + vput(tdp); + return (error); + } if (dp->i_number == ino) { VREF(vdp); *vpp = vdp; @@ -648,6 +641,8 @@ found: dp->i_offset = i_offset; if (dp->i_number == ino) return (EISDIR); + if (dd_ino != NULL) + return (0); if ((error = VFS_VGET(vdp->v_mount, ino, LK_EXCLUSIVE, &tdp)) != 0) return (error); @@ -682,6 +677,8 @@ found: cnp->cn_flags |= SAVENAME; return (0); } + if (dd_ino != NULL) + return (0); /* * Step through the translation in the name. We do not `vput' the @@ -713,7 +710,7 @@ found: * to the inode we looked up before vdp lock was * dropped. */ - error = ufs_lookup_(pdp, NULL, cnp, &ino1); + error = ufs_lookup_ino(pdp, NULL, cnp, &ino1); if (error) { vput(tdp); return (error); @@ -865,12 +862,13 @@ ufs_makedirentry(ip, cnp, newdirp) * soft dependency code). */ int -ufs_direnter(dvp, tvp, dirp, cnp, newdirbp) +ufs_direnter(dvp, tvp, dirp, cnp, newdirbp, isrename) struct vnode *dvp; struct vnode *tvp; struct direct *dirp; struct componentname *cnp; struct buf *newdirbp; + int isrename; { struct ucred *cr; struct thread *td; @@ -943,22 +941,30 @@ ufs_direnter(dvp, tvp, dirp, cnp, newdir blkoff += DIRBLKSIZ; } if (softdep_setup_directory_add(bp, dp, dp->i_offset, - dirp->d_ino, newdirbp, 1) == 0) { - bdwrite(bp); + dirp->d_ino, newdirbp, 1)) + dp->i_flag |= IN_NEEDSYNC; +#ifdef JOURNALED_SOFTUPDATES + if (newdirbp) + bdwrite(newdirbp); +#endif + bdwrite(bp); + if ((dp->i_flag & IN_NEEDSYNC) == 0) return (UFS_UPDATE(dvp, 0)); - } - /* We have just allocated a directory block in an - * indirect block. Rather than tracking when it gets - * claimed by the inode, we simply do a VOP_FSYNC - * now to ensure that it is there (in case the user - * does a future fsync). Note that we have to unlock - * the inode for the entry that we just entered, as - * the VOP_FSYNC may need to lock other inodes which - * can lead to deadlock if we also hold a lock on - * the newly entered node. + /* + * We have just allocated a directory block in an + * indirect block. We must prevent holes in the + * directory created if directory entries are + * written out of order. To accomplish this we + * fsync when we extend a directory into indirects. + * During rename it's not safe to drop the tvp lock + * so sync must be delayed until it is. + * + * This synchronous step could be removed if fsck and + * the kernel were taught to fill in sparse + * directories rather than panic. */ - if ((error = bwrite(bp))) - return (error); + if (isrename) + return (0); if (tvp != NULL) VOP_UNLOCK(tvp, 0); error = VOP_FSYNC(dvp, MNT_WAIT, td); @@ -1099,6 +1105,10 @@ ufs_direnter(dvp, tvp, dirp, cnp, newdir (void) softdep_setup_directory_add(bp, dp, dp->i_offset + (caddr_t)ep - dirbuf, dirp->d_ino, newdirbp, 0); +#ifdef JOURNALED_SOFTUPDATES + if (newdirbp != NULL) + bdwrite(newdirbp); +#endif bdwrite(bp); } else { if (DOINGASYNC(dvp)) { @@ -1116,7 +1126,8 @@ ufs_direnter(dvp, tvp, dirp, cnp, newdir * lock other inodes which can lead to deadlock if we also hold a * lock on the newly entered node. */ - if (error == 0 && dp->i_endoff && dp->i_endoff < dp->i_size) { + if (isrename == 0 && error == 0 && + dp->i_endoff && dp->i_endoff < dp->i_size) { if (tvp != NULL) VOP_UNLOCK(tvp, 0); #ifdef UFS_DIRHASH @@ -1386,25 +1397,25 @@ ufs_dir_dd_ino(struct vnode *vp, struct /* * Check if source directory is in the path of the target directory. - * Target is supplied locked, source is unlocked. - * The target is always vput before returning. */ int -ufs_checkpath(ino_t source_ino, struct inode *target, struct ucred *cred) +ufs_checkpath(ino_t source_ino, ino_t parent_ino, struct inode *target, struct ucred *cred, ino_t *wait_ino) { - struct vnode *vp, *vp1; + struct mount *mp; + struct vnode *tvp, *vp, *vp1; int error; ino_t dd_ino; - vp = ITOV(target); - if (target->i_number == source_ino) { - error = EEXIST; - goto out; - } - error = 0; + vp = tvp = ITOV(target); + mp = vp->v_mount; + *wait_ino = 0; + if (target->i_number == source_ino) + return (EEXIST); + if (target->i_number == parent_ino) + return (0); if (target->i_number == ROOTINO) - goto out; - + return (0); + error = 0; for (;;) { error = ufs_dir_dd_ino(vp, cred, &dd_ino); if (error != 0) @@ -1415,9 +1426,13 @@ ufs_checkpath(ino_t source_ino, struct i } if (dd_ino == ROOTINO) break; - error = vn_vget_ino(vp, dd_ino, LK_EXCLUSIVE, &vp1); - if (error != 0) + if (dd_ino == parent_ino) + break; + error = VFS_VGET(mp, dd_ino, LK_SHARED | LK_NOWAIT, &vp1); + if (error != 0) { + *wait_ino = dd_ino; break; + } /* Recheck that ".." still points to vp1 after relock of vp */ error = ufs_dir_dd_ino(vp, cred, &dd_ino); if (error != 0) { @@ -1429,14 +1444,14 @@ ufs_checkpath(ino_t source_ino, struct i vput(vp1); continue; } - vput(vp); + if (vp != tvp) + vput(vp); vp = vp1; } -out: if (error == ENOTDIR) - printf("checkpath: .. not a directory\n"); - if (vp != NULL) + panic("checkpath: .. not a directory\n"); + if (vp != tvp) vput(vp); return (error); } Modified: stable/8/sys/ufs/ufs/ufs_vnops.c ============================================================================== --- stable/8/sys/ufs/ufs/ufs_vnops.c Sun Apr 24 10:47:56 2011 (r220985) +++ stable/8/sys/ufs/ufs/ufs_vnops.c Sun Apr 24 11:01:42 2011 (r220986) @@ -49,6 +49,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -114,6 +115,8 @@ static vop_close_t ufsfifo_close; static vop_kqfilter_t ufsfifo_kqfilter; static vop_pathconf_t ufsfifo_pathconf; +SYSCTL_NODE(_vfs, OID_AUTO, ufs, CTLFLAG_RD, 0, "UFS filesystem"); + /* * A virgin directory (no blushing please). */ @@ -992,7 +995,7 @@ ufs_link(ap) error = UFS_UPDATE(vp, !(DOINGSOFTDEP(vp) | DOINGASYNC(vp))); if (!error) { ufs_makedirentry(ip, cnp, &newdir); - error = ufs_direnter(tdvp, vp, &newdir, cnp, NULL); + error = ufs_direnter(tdvp, vp, &newdir, cnp, NULL, 0); } if (error) { @@ -1043,7 +1046,7 @@ ufs_whiteout(ap) newdir.d_namlen = cnp->cn_namelen; bcopy(cnp->cn_nameptr, newdir.d_name, (unsigned)cnp->cn_namelen + 1); newdir.d_type = DT_WHT; - error = ufs_direnter(dvp, NULL, &newdir, cnp, NULL); + error = ufs_direnter(dvp, NULL, &newdir, cnp, NULL, 0); break; case DELETE: @@ -1062,6 +1065,11 @@ ufs_whiteout(ap) return (error); } +static volatile int rename_restarts; +SYSCTL_INT(_vfs_ufs, OID_AUTO, rename_restarts, CTLFLAG_RD, + __DEVOLATILE(int *, &rename_restarts), 0, + "Times rename had to restart due to lock contention"); + /* * Rename system call. * rename("foo", "bar"); @@ -1101,111 +1109,185 @@ ufs_rename(ap) struct vnode *tdvp = ap->a_tdvp; struct vnode *fvp = ap->a_fvp; struct vnode *fdvp = ap->a_fdvp; + struct vnode *nvp; struct componentname *tcnp = ap->a_tcnp; struct componentname *fcnp = ap->a_fcnp; struct thread *td = fcnp->cn_thread; - struct inode *ip, *xp, *dp; + struct inode *fip, *tip, *tdp, *fdp; struct direct newdir; - int doingdirectory = 0, oldparent = 0, newparent = 0; + off_t endoff; + int doingdirectory, newparent; int error = 0, ioflag; - ino_t fvp_ino; + struct mount *mp; + ino_t ino; #ifdef INVARIANTS if ((tcnp->cn_flags & HASBUF) == 0 || (fcnp->cn_flags & HASBUF) == 0) panic("ufs_rename: no name"); #endif + endoff = 0; + mp = tdvp->v_mount; + VOP_UNLOCK(tdvp, 0); + if (tvp && tvp != tdvp) + VOP_UNLOCK(tvp, 0); /* * Check for cross-device rename. */ if ((fvp->v_mount != tdvp->v_mount) || (tvp && (fvp->v_mount != tvp->v_mount))) { error = EXDEV; -abortit: - if (tdvp == tvp) - vrele(tdvp); - else - vput(tdvp); - if (tvp) - vput(tvp); - vrele(fdvp); + mp = NULL; + goto releout; + } + error = vfs_busy(mp, 0); + if (error) { + mp = NULL; + goto releout; + } +relock: + /* + * We need to acquire 2 to 4 locks depending on whether tvp is NULL + * and fdvp and tdvp are the same directory. Subsequently we need + * to double-check all paths and in the directory rename case we + * need to verify that we are not creating a directory loop. To + * handle this we acquire all but fdvp using non-blocking + * acquisitions. If we fail to acquire any lock in the path we will + * drop all held locks, acquire the new lock in a blocking fashion, + * and then release it and restart the rename. This acquire/release + * step ensures that we do not spin on a lock waiting for release. + */ + error = vn_lock(fdvp, LK_EXCLUSIVE); + if (error) + goto releout; + if (vn_lock(tdvp, LK_EXCLUSIVE | LK_NOWAIT) != 0) { + VOP_UNLOCK(fdvp, 0); + error = vn_lock(tdvp, LK_EXCLUSIVE); + if (error) + goto releout; + VOP_UNLOCK(tdvp, 0); + atomic_add_int(&rename_restarts, 1); + goto relock; + } + /* + * Re-resolve fvp to be certain it still exists and fetch the + * correct vnode. + */ + error = ufs_lookup_ino(fdvp, NULL, fcnp, &ino); + if (error) { + VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(tdvp, 0); + goto releout; + } + error = VFS_VGET(mp, ino, LK_EXCLUSIVE | LK_NOWAIT, &nvp); + if (error) { + VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(tdvp, 0); + if (error != EBUSY) + goto releout; + error = VFS_VGET(mp, ino, LK_EXCLUSIVE, &nvp); + if (error != 0) + goto releout; + VOP_UNLOCK(nvp, 0); vrele(fvp); - return (error); + fvp = nvp; + atomic_add_int(&rename_restarts, 1); + goto relock; + } + vrele(fvp); + fvp = nvp; + /* + * Re-resolve tvp and acquire the vnode lock if present. + */ + error = ufs_lookup_ino(tdvp, NULL, tcnp, &ino); + if (error != 0 && error != EJUSTRETURN) { + VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(tdvp, 0); + VOP_UNLOCK(fvp, 0); + goto releout; } - + /* + * If tvp disappeared we just carry on. + */ + if (error == EJUSTRETURN && tvp != NULL) { + vrele(tvp); + tvp = NULL; + } + /* + * Get the tvp ino if the lookup succeeded. We may have to restart + * if the non-blocking acquire fails. + */ + if (error == 0) { + nvp = NULL; + error = VFS_VGET(mp, ino, LK_EXCLUSIVE | LK_NOWAIT, &nvp); + if (tvp) + vrele(tvp); + tvp = nvp; + if (error) { + VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(tdvp, 0); + VOP_UNLOCK(fvp, 0); + if (error != EBUSY) + goto releout; + error = VFS_VGET(mp, ino, LK_EXCLUSIVE, &nvp); + if (error != 0) + goto releout; + VOP_UNLOCK(nvp, 0); + atomic_add_int(&rename_restarts, 1); + goto relock; + } + } + fdp = VTOI(fdvp); + fip = VTOI(fvp); + tdp = VTOI(tdvp); + tip = NULL; + if (tvp) + tip = VTOI(tvp); if (tvp && ((VTOI(tvp)->i_flags & (NOUNLINK | IMMUTABLE | APPEND)) || (VTOI(tdvp)->i_flags & APPEND))) { error = EPERM; - goto abortit; + goto unlockout; } - /* * Renaming a file to itself has no effect. The upper layers should - * not call us in that case. Temporarily just warn if they do. + * not call us in that case. However, things could change after + * we drop the locks above. */ if (fvp == tvp) { - printf("ufs_rename: fvp == tvp (can't happen)\n"); error = 0; - goto abortit; + goto unlockout; } - - if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0) - goto abortit; - dp = VTOI(fdvp); - ip = VTOI(fvp); - if (ip->i_nlink >= LINK_MAX) { - VOP_UNLOCK(fvp, 0); + doingdirectory = 0; + newparent = 0; + ino = fip->i_number; + if (fip->i_nlink >= LINK_MAX) { error = EMLINK; - goto abortit; + goto unlockout; } - if ((ip->i_flags & (NOUNLINK | IMMUTABLE | APPEND)) - || (dp->i_flags & APPEND)) { - VOP_UNLOCK(fvp, 0); + if ((fip->i_flags & (NOUNLINK | IMMUTABLE | APPEND)) + || (fdp->i_flags & APPEND)) { error = EPERM; - goto abortit; + goto unlockout; } - if ((ip->i_mode & IFMT) == IFDIR) { + if ((fip->i_mode & IFMT) == IFDIR) { /* * Avoid ".", "..", and aliases of "." for obvious reasons. */ if ((fcnp->cn_namelen == 1 && fcnp->cn_nameptr[0] == '.') || - dp == ip || (fcnp->cn_flags | tcnp->cn_flags) & ISDOTDOT || - (ip->i_flag & IN_RENAME)) { - VOP_UNLOCK(fvp, 0); + fdp == fip || + (fcnp->cn_flags | tcnp->cn_flags) & ISDOTDOT) { error = EINVAL; - goto abortit; + goto unlockout; } - ip->i_flag |= IN_RENAME; - oldparent = dp->i_number; + if (fdp->i_number != tdp->i_number) + newparent = tdp->i_number; doingdirectory = 1; } - vrele(fdvp); - - /* - * When the target exists, both the directory - * and target vnodes are returned locked. - */ - dp = VTOI(tdvp); - xp = NULL; - if (tvp) - xp = VTOI(tvp); - - /* - * 1) Bump link count while we're moving stuff - * around. If we crash somewhere before - * completing our work, the link count - * may be wrong, but correctable. - */ - ip->i_effnlink++; - ip->i_nlink++; - DIP_SET(ip, i_nlink, ip->i_nlink); - ip->i_flag |= IN_CHANGE; - if (DOINGSOFTDEP(fvp)) - softdep_change_linkcnt(ip); - if ((error = UFS_UPDATE(fvp, !(DOINGSOFTDEP(fvp) | - DOINGASYNC(fvp)))) != 0) { - VOP_UNLOCK(fvp, 0); - goto bad; + if ((fvp->v_type == VDIR && fvp->v_mountedhere != NULL) || + (tvp != NULL && tvp->v_type == VDIR && + tvp->v_mountedhere != NULL)) { + error = EXDEV; + goto unlockout; } /* @@ -1214,35 +1296,55 @@ abortit: * directory hierarchy above the target, as this would * orphan everything below the source directory. Also * the user must have write permission in the source so - * as to be able to change "..". We must repeat the call - * to namei, as the parent directory is unlocked by the - * call to checkpath(). - */ - error = VOP_ACCESS(fvp, VWRITE, tcnp->cn_cred, tcnp->cn_thread); - fvp_ino = ip->i_number; - VOP_UNLOCK(fvp, 0); - if (oldparent != dp->i_number) - newparent = dp->i_number; + * as to be able to change "..". + */ if (doingdirectory && newparent) { - if (error) /* write access check above */ - goto bad; - if (xp != NULL) - vput(tvp); - error = ufs_checkpath(fvp_ino, dp, tcnp->cn_cred); + error = VOP_ACCESS(fvp, VWRITE, tcnp->cn_cred, tcnp->cn_thread); if (error) - goto out; + goto unlockout; + error = ufs_checkpath(ino, fdp->i_number, tdp, tcnp->cn_cred, + &ino); + /* + * We encountered a lock that we have to wait for. Unlock + * everything else and VGET before restarting. + */ + if (ino) { + VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(fvp, 0); + VOP_UNLOCK(tdvp, 0); + if (tvp) + VOP_UNLOCK(tvp, 0); + error = VFS_VGET(mp, ino, LK_SHARED, &nvp); + if (error == 0) + vput(nvp); + atomic_add_int(&rename_restarts, 1); + goto relock; + } + if (error) + goto unlockout; if ((tcnp->cn_flags & SAVESTART) == 0) panic("ufs_rename: lost to startdir"); - VREF(tdvp); - error = relookup(tdvp, &tvp, tcnp); - if (error) - goto out; - vrele(tdvp); - dp = VTOI(tdvp); - xp = NULL; - if (tvp) - xp = VTOI(tvp); } + if (fip->i_effnlink == 0 || fdp->i_effnlink == 0 || + tdp->i_effnlink == 0) + panic("Bad effnlink fip %p, fdp %p, tdp %p", fip, fdp, tdp); + + /* + * 1) Bump link count while we're moving stuff + * around. If we crash somewhere before + * completing our work, the link count + * may be wrong, but correctable. + */ + fip->i_effnlink++; + fip->i_nlink++; + DIP_SET(fip, i_nlink, fip->i_nlink); + fip->i_flag |= IN_CHANGE; + if (DOINGSOFTDEP(fvp)) + softdep_change_linkcnt(fip); + error = UFS_UPDATE(fvp, !(DOINGSOFTDEP(fvp) | DOINGASYNC(fvp))); + if (error) + goto bad; + /* * 2) If target doesn't exist, link the target * to the source and unlink the source. @@ -1250,52 +1352,37 @@ abortit: * entry to reference the source inode and * expunge the original entry's existence. */ - if (xp == NULL) { - if (dp->i_dev != ip->i_dev) + if (tip == NULL) { + if (tdp->i_dev != fip->i_dev) panic("ufs_rename: EXDEV"); - /* - * Account for ".." in new directory. - * When source and destination have the same - * parent we don't fool with the link count. - */ if (doingdirectory && newparent) { - if ((nlink_t)dp->i_nlink >= LINK_MAX) { + /* + * Account for ".." in new directory. + * When source and destination have the same + * parent we don't adjust the link count. The + * actual link modification is completed when + * .. is rewritten below. + */ + if ((nlink_t)tdp->i_nlink >= LINK_MAX) { error = EMLINK; goto bad; } - dp->i_effnlink++; - dp->i_nlink++; - DIP_SET(dp, i_nlink, dp->i_nlink); - dp->i_flag |= IN_CHANGE; - if (DOINGSOFTDEP(tdvp)) - softdep_change_linkcnt(dp); - error = UFS_UPDATE(tdvp, !(DOINGSOFTDEP(tdvp) | - DOINGASYNC(tdvp))); - if (error) - goto bad; } - ufs_makedirentry(ip, tcnp, &newdir); - error = ufs_direnter(tdvp, NULL, &newdir, tcnp, NULL); - if (error) { - if (doingdirectory && newparent) { - dp->i_effnlink--; - dp->i_nlink--; - DIP_SET(dp, i_nlink, dp->i_nlink); - dp->i_flag |= IN_CHANGE; - if (DOINGSOFTDEP(tdvp)) - softdep_change_linkcnt(dp); - (void)UFS_UPDATE(tdvp, 1); - } + ufs_makedirentry(fip, tcnp, &newdir); + error = ufs_direnter(tdvp, NULL, &newdir, tcnp, NULL, 1); + if (error) goto bad; - } - vput(tdvp); + /* Setup tdvp for directory compaction if needed. */ + if (tdp->i_count && tdp->i_endoff && + tdp->i_endoff < tdp->i_size) + endoff = tdp->i_endoff; } else { - if (xp->i_dev != dp->i_dev || xp->i_dev != ip->i_dev) + if (tip->i_dev != tdp->i_dev || tip->i_dev != fip->i_dev) panic("ufs_rename: EXDEV"); /* * Short circuit rename(foo, foo). */ - if (xp->i_number == ip->i_number) + if (tip->i_number == fip->i_number) panic("ufs_rename: same file"); /* * If the parent directory is "sticky", then the caller @@ -1303,7 +1390,7 @@ abortit: * destination of the rename. This implements append-only * directories. */ - if ((dp->i_mode & S_ISTXT) && + if ((tdp->i_mode & S_ISTXT) && VOP_ACCESS(tdvp, VADMIN, tcnp->cn_cred, td) && VOP_ACCESS(tvp, VADMIN, tcnp->cn_cred, td)) { error = EPERM; @@ -1314,9 +1401,9 @@ abortit: * to it. Also, ensure source and target are compatible * (both directories, or both not directories). */ - if ((xp->i_mode&IFMT) == IFDIR) { - if ((xp->i_effnlink > 2) || - !ufs_dirempty(xp, dp->i_number, tcnp->cn_cred)) { + if ((tip->i_mode & IFMT) == IFDIR) { + if ((tip->i_effnlink > 2) || + !ufs_dirempty(tip, tdp->i_number, tcnp->cn_cred)) { error = ENOTEMPTY; goto bad; } @@ -1329,20 +1416,30 @@ abortit: error = EISDIR; goto bad; } - error = ufs_dirrewrite(dp, xp, ip->i_number, - IFTODT(ip->i_mode), - (doingdirectory && newparent) ? newparent : doingdirectory); - if (error) - goto bad; if (doingdirectory) { if (!newparent) { - dp->i_effnlink--; + tdp->i_effnlink--; if (DOINGSOFTDEP(tdvp)) - softdep_change_linkcnt(dp); + softdep_change_linkcnt(tdp); } - xp->i_effnlink--; + tip->i_effnlink--; if (DOINGSOFTDEP(tvp)) - softdep_change_linkcnt(xp); + softdep_change_linkcnt(tip); + } + error = ufs_dirrewrite(tdp, tip, fip->i_number, + IFTODT(fip->i_mode), + (doingdirectory && newparent) ? newparent : doingdirectory); + if (error) { + if (doingdirectory) { + if (!newparent) { + tdp->i_effnlink++; + if (DOINGSOFTDEP(tdvp)) + softdep_change_linkcnt(tdp); + } + tip->i_effnlink++; + if (DOINGSOFTDEP(tvp)) + softdep_change_linkcnt(tip); + } } if (doingdirectory && !DOINGSOFTDEP(tvp)) { /* @@ -1357,115 +1454,107 @@ abortit: * them now. */ if (!newparent) { - dp->i_nlink--; - DIP_SET(dp, i_nlink, dp->i_nlink); - dp->i_flag |= IN_CHANGE; + tdp->i_nlink--; + DIP_SET(tdp, i_nlink, tdp->i_nlink); + tdp->i_flag |= IN_CHANGE; } - xp->i_nlink--; - DIP_SET(xp, i_nlink, xp->i_nlink); - xp->i_flag |= IN_CHANGE; + tip->i_nlink--; + DIP_SET(tip, i_nlink, tip->i_nlink); + tip->i_flag |= IN_CHANGE; ioflag = IO_NORMAL; if (!DOINGASYNC(tvp)) ioflag |= IO_SYNC; + /* Don't go to bad here as the new link exists. */ if ((error = UFS_TRUNCATE(tvp, (off_t)0, ioflag, tcnp->cn_cred, tcnp->cn_thread)) != 0) - goto bad; + goto unlockout; } - vput(tdvp); - vput(tvp); - xp = NULL; } /* - * 3) Unlink the source. + * 3) Unlink the source. We have to resolve the path again to + * fixup the directory offset and count for ufs_dirremove. */ - fcnp->cn_flags &= ~MODMASK; - fcnp->cn_flags |= LOCKPARENT | LOCKLEAF; - if ((fcnp->cn_flags & SAVESTART) == 0) - panic("ufs_rename: lost from startdir"); - VREF(fdvp); - error = relookup(fdvp, &fvp, fcnp); - if (error == 0) - vrele(fdvp); - if (fvp != NULL) { - xp = VTOI(fvp); - dp = VTOI(fdvp); - } else { - /* - * From name has disappeared. IN_RENAME is not sufficient - * to protect against directory races due to timing windows, - * so we have to remove the panic. XXX the only real way - * to solve this issue is at a much higher level. By the - * time we hit ufs_rename() it's too late. - */ -#if 0 - if (doingdirectory) - panic("ufs_rename: lost dir entry"); -#endif - vrele(ap->a_fvp); - return (0); + if (fdvp == tdvp) { + error = ufs_lookup_ino(fdvp, NULL, fcnp, &ino); + if (error) + panic("ufs_rename: from entry went away!"); + if (ino != fip->i_number) + panic("ufs_rename: ino mismatch %d != %d\n", ino, + fip->i_number); } /* - * Ensure that the directory entry still exists and has not - * changed while the new name has been entered. If the source is - * a file then the entry may have been unlinked or renamed. In - * either case there is no further work to be done. If the source - * is a directory then it cannot have been rmdir'ed; the IN_RENAME - * flag ensures that it cannot be moved by another rename or removed - * by a rmdir. - */ - if (xp != ip) { - /* - * From name resolves to a different inode. IN_RENAME is - * not sufficient protection against timing window races - * so we can't panic here. XXX the only real way - * to solve this issue is at a much higher level. By the - * time we hit ufs_rename() it's too late. - */ -#if 0 - if (doingdirectory) - panic("ufs_rename: lost dir entry"); -#endif - } else { + * If the source is a directory with a + * new parent, the link count of the old + * parent directory must be decremented + * and ".." set to point to the new parent. + */ + if (doingdirectory && newparent) { /* - * If the source is a directory with a - * new parent, the link count of the old - * parent directory must be decremented - * and ".." set to point to the new parent. + * If tip exists we simply use its link, otherwise we must + * add a new one. */ - if (doingdirectory && newparent) { - xp->i_offset = mastertemplate.dot_reclen; - ufs_dirrewrite(xp, dp, newparent, DT_DIR, 0); - cache_purge(fdvp); - } - error = ufs_dirremove(fdvp, xp, fcnp->cn_flags, 0); - xp->i_flag &= ~IN_RENAME; - } - if (dp) - vput(fdvp); - if (xp) - vput(fvp); - vrele(ap->a_fvp); + if (tip == NULL) { + tdp->i_effnlink++; + tdp->i_nlink++; + DIP_SET(tdp, i_nlink, tdp->i_nlink); + tdp->i_flag |= IN_CHANGE; + if (DOINGSOFTDEP(tdvp)) + softdep_change_linkcnt(tdp); + error = UFS_UPDATE(tdvp, !(DOINGSOFTDEP(tdvp) | + DOINGASYNC(tdvp))); + /* Don't go to bad here as the new link exists. */ + if (error) + goto unlockout; + } + fip->i_offset = mastertemplate.dot_reclen; + ufs_dirrewrite(fip, fdp, newparent, DT_DIR, 0); + cache_purge(fdvp); + } + error = ufs_dirremove(fdvp, fip, fcnp->cn_flags, 0); + +unlockout: + vput(fdvp); + vput(fvp); + if (tvp) + vput(tvp); + /* + * If compaction or fsync was requested do it now that other locks + * are no longer needed. + */ + if (error == 0 && endoff != 0) { +#ifdef UFS_DIRHASH + if (tdp->i_dirhash != NULL) + ufsdirhash_dirtrunc(tdp, endoff); +#endif + UFS_TRUNCATE(tdvp, endoff, IO_NORMAL | IO_SYNC, tcnp->cn_cred, + td); + } + if (error == 0 && tdp->i_flag & IN_NEEDSYNC) + error = VOP_FSYNC(tdvp, MNT_WAIT, td); + vput(tdvp); + if (mp) + vfs_unbusy(mp); return (error); bad: - if (xp) - vput(ITOV(xp)); - vput(ITOV(dp)); -out: - if (doingdirectory) - ip->i_flag &= ~IN_RENAME; - if (vn_lock(fvp, LK_EXCLUSIVE) == 0) { - ip->i_effnlink--; - ip->i_nlink--; - DIP_SET(ip, i_nlink, ip->i_nlink); - ip->i_flag |= IN_CHANGE; - ip->i_flag &= ~IN_RENAME; - if (DOINGSOFTDEP(fvp)) - softdep_change_linkcnt(ip); - vput(fvp); - } else - vrele(fvp); + fip->i_effnlink--; + fip->i_nlink--; + DIP_SET(fip, i_nlink, fip->i_nlink); + fip->i_flag |= IN_CHANGE; + if (DOINGSOFTDEP(fvp)) + softdep_change_linkcnt(fip); + goto unlockout; + +releout: *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sun Apr 24 11:12:37 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 5E6D01065672; Sun, 24 Apr 2011 11:12:37 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 35BCC8FC1B; Sun, 24 Apr 2011 11:12:37 +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 p3OBCb5P053303; Sun, 24 Apr 2011 11:12:37 GMT (envelope-from kib@freefall.freebsd.org) Received: (from kib@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3OBCasE053299; Sun, 24 Apr 2011 11:12:36 GMT (envelope-from kib) Date: Sun, 24 Apr 2011 11:12:36 GMT Message-Id: <201104241112.p3OBCasE053299@freefall.freebsd.org> To: konstantin.malov@kaspersky.com, kib@FreeBSD.org, freebsd-fs@FreeBSD.org From: kib@FreeBSD.org Cc: Subject: Re: kern/156545: [ufs] mv could break UFS on SMP systems 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, 24 Apr 2011 11:12:37 -0000 Synopsis: [ufs] mv could break UFS on SMP systems State-Changed-From-To: open->patched State-Changed-By: kib State-Changed-When: Sun Apr 24 11:11:10 UTC 2011 State-Changed-Why: HEAD contained fix for the problem, that was commited together with large +J patch. I extracted the lone ufs_rename() rework and merged it into stable/8. Lets see how it works. http://www.freebsd.org/cgi/query-pr.cgi?pr=156545 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 25 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 D0452106566B for ; Mon, 25 Apr 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 B35AC8FC19 for ; Mon, 25 Apr 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 p3PB6wTh084549 for ; Mon, 25 Apr 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 p3PB6wxd084547 for freebsd-fs@FreeBSD.org; Mon, 25 Apr 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Apr 2011 11:06:58 GMT Message-Id: <201104251106.p3PB6wxd084547@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, 25 Apr 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 -------------------------------------------------------------------------------- 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 f 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 f kern/149022 fs [hang] File system operations hangs with suspfs state 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 f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat 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 o 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 o 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 222 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 25 15:50: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 35270106564A for ; Mon, 25 Apr 2011 15:50:14 +0000 (UTC) (envelope-from conall@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BEDF78FC15 for ; Mon, 25 Apr 2011 15:50:13 +0000 (UTC) Received: by wwc33 with SMTP id 33so2224867wwc.31 for ; Mon, 25 Apr 2011 08:50:12 -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:content-type :content-transfer-encoding; bh=unGWWRlY+3U1EPSNfMrsDqqMihUVdcNjtKaNzCuMWe8=; b=bO4LmaQx9jU8AU3sNbF2GNNOUGg0gFqLpGEjJwImKlT8c4YdqEt+n3sZN3fSKT95ld 1dKN8+zUmw+BjNnr7ovor98yY9yAMabakpV/SxqS6B/hkwOS0UZDhLTaoQU/jElQRscr yVZDZ/BYklpAZb8adIYBSEmKihEm7UE+v++zk= 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:content-type :content-transfer-encoding; b=oC8dkYbKuIxNGHTcGrH3SlKqDKIeZCa6XKIMrkC87j9qXDoSUupxK6NYJPCXvzRORn N5jq1uRtmb5QVoRKBYbzFuUlLOem5PPBX6BGq0OL42KvAAnh9NV883Rw9kEMgDKn2hk2 MZpHrTRPi3T1kV2M5+36OmTgqSjZGQNZdDB/g= MIME-Version: 1.0 Received: by 10.216.245.4 with SMTP id n4mr3570190wer.83.1303746611315; Mon, 25 Apr 2011 08:50:11 -0700 (PDT) Sender: conall@gmail.com Received: by 10.216.48.18 with HTTP; Mon, 25 Apr 2011 08:50:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Apr 2011 16:50:11 +0100 X-Google-Sender-Auth: PpBDgVtrdxaiG1aUWEkYoB-tBWc Message-ID: From: "Conall O'Brien" To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Problems Terminating zpool scrub... 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, 25 Apr 2011 15:50:14 -0000 On 15 April 2011 15:59, Conall O'Brien wrote: > Hello, > > > I've got a NAS box running 8-STABLEW [1] which I'm running with 5x > Western Digital 2TB disks. > > > One of the disks was having DMA issues as reported in dmesg, so I > began the usual zfs workflow of "zpool offline pool dev", physically > removing it and tried to "zpool replace pool dev" but my attempts to > do so fail, actually the zpool command keeps ending up in > uninterruptable wait (the D state). Before resorting to replacing the > disk, a zpool scrub was in progress. Now, I can't kill it using "zpool > scrub -s pool", it too ends up in the D state. > > > Is there another way than "zpool scrub -s pool" to terminate a scrub > process, so I can proceed with the disk replacement. I care more about > resilvering my pool before getting around to scrubbing it. > > > Thanks! > > > [1] For completeness, uname -a reports FreeBSD galvatron.taku.ie > 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Mar 19 13:18:46 UTC 2011 > root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON =C2=A0amd64 I worked out the problem. There's a regression in one of the drivers between the kernel I was running and my previous kernel: FreeBSD galvatron.taku.ie 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Wed Dec 29 04:00:27 UTC 2010 root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON amd64 I'll file a PR to get it fixed. --=20 Conall O'Brien From owner-freebsd-fs@FreeBSD.ORG Mon Apr 25 16:54: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 93EED1065673; Mon, 25 Apr 2011 16:54:54 +0000 (UTC) (envelope-from konstantin.kuklin@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA14E8FC1D; Mon, 25 Apr 2011 16:54:53 +0000 (UTC) Received: by gyg13 with SMTP id 13so905929gyg.13 for ; Mon, 25 Apr 2011 09:54:53 -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:cc:content-type; bh=+Icc+8B4W60mVi0JaFdrgg5LrG2WmScvVPKmqsXuIlw=; b=CvMrSW9rkiY5pC1v0TVbZGbtUeO2WOpKyittWwVcfwopKTVhCbkwp4v3SjsX4PcYhQ JtV0jb9JFLXxkNvA6tjlSHjhtMjXAyB9sVDvZo3C6JBHzCjj7TTo7ZJBTWaQSHumbace qDfozlnpfEwe7kGIoCy4OJeLQsaqN3sQn+y4c= 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 :cc:content-type; b=uSR4sxuxdGuNeQET7+ObQrRfBpb7RkeRXc2On2lIxYN0SlVhNsH2oVI4Ivw4zoeNG9 2gBE+c8t2jl52qqKNuyrUzMorqWPgkXHsQMNGfF4qhTbOSWqrgeb1x9yNKbdLDldZqhw IMUolEwn7MqMYytTpembrJbqHNLlUo1MQws2s= MIME-Version: 1.0 Received: by 10.236.183.129 with SMTP id q1mr4312970yhm.220.1303750493339; Mon, 25 Apr 2011 09:54:53 -0700 (PDT) Received: by 10.147.34.17 with HTTP; Mon, 25 Apr 2011 09:54:53 -0700 (PDT) In-Reply-To: <223111974.20110424114947@nitronet.pl> References: <223111974.20110424114947@nitronet.pl> Date: Mon, 25 Apr 2011 20:54:53 +0400 Message-ID: From: Konstantin Kuklin To: Pawel Tyll X-Mailman-Approved-At: Mon, 25 Apr 2011 17:03:15 +0000 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, pjd@freebsd.org Subject: Re: zfs problem vdev I/O failure 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, 25 Apr 2011 16:54:54 -0000 So, I install FreeBSD 8.2 with ZFS patch v28 and have this error message with full freeze zfs system: Solaris: Warning: can`t open object for zroot/var/crash log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement Solaris: Warning: can`t open object for zroot/var/crash log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement log_sysevent: type19 is not emplement 2011/4/24 Pawel Tyll > Hi Konstantin, > > > zpool status: > > Flash# zpool status > > pool: zroot > > state: DEGRADED > > status: One or more devices are faulted in response to IO failures. > > action: Make sure the affected devices are connected, then run 'zpool > > clear'. > > see: http://www.sun.com/msg/ZFS-8000-HC > > scrub: resilver in progress for 0h6m, 0.00% done, 1582566h29m to go > > config: > > > NAME STATE READ WRITE CKSUM > > zroot DEGRADED 12 0 1 > > mirror DEGRADED 36 0 4 > > 7159451150335751026 UNAVAIL 0 0 0 was > > /dev/gpt/disk0 > > gpt/disk1 ONLINE 0 0 40 > > > errors: 12 data errors, use '-v' for a list > > > Zpool scrub freeze and time to resilver up in time... > > How i can repair it, if zpool scrub -s zroot and detach don`t work...an= d > > don`t work all of zfs commands =3D\ > > Try booting mfsBSD and fixing there, http://mfsbsd.vx.sk/ > > http://mfsbsd.vx.sk/iso/mfsbsd-8.2-zfsv28-i386.iso > http://mfsbsd.vx.sk/iso/mfsbsd-se-8.2-zfsv28-amd64.iso > > > --=20 =F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD =EB=D5=CB=CC=C9=CE =EB=CF=CE=D3=D4=C1=CE=D4=C9=CE. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 25 19:45:02 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 728AA1065679 for ; Mon, 25 Apr 2011 19:45:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 613B615444E for ; Mon, 25 Apr 2011 19:45:00 +0000 (UTC) Message-ID: <4DB5CF3C.9030002@FreeBSD.org> Date: Mon, 25 Apr 2011 12:45:00 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic: ext2fs_alloccg: map corrupted 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, 25 Apr 2011 19:45:02 -0000 I got the following panic on 9-current, r216869, amd64 SMP on a core 2 duo system. I'm running the older version (from 2011-01-01) to try and determine where the problem I'm having with stability on -current first occurred. If this problem was fixed between now and then, no worries. This panic happened during heavy disk activity on the ext2fs partition. The file core.txt.0.216869 is in my home directory on freefall if anyone wants to take a look. Doug Unread portion of the kernel message buffer: start = 0, len = 1, fs = /home panic: ext2fs_alloccg: map corrupted cpuid = 0 Uptime: 5m51s Physical memory: 2036 MB Dumping 242 MB: 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 #0 doadump () at /home/svn/head/sys/kern/kern_shutdown.c:250 250 if (textdump_pending) (kgdb) #0 doadump () at /home/svn/head/sys/kern/kern_shutdown.c:250 #1 0xffffffff8031d367 in kern_reboot (howto=260) at /home/svn/head/sys/kern/kern_shutdown.c:418 #2 0xffffffff8031d7c1 in panic (fmt=Variable "fmt" is not available. ) at /home/svn/head/sys/kern/kern_shutdown.c:591 #3 0xffffffff802c9cc9 in ext2_alloccg (ip=Variable "ip" is not available. ) at /home/svn/head/sys/fs/ext2fs/ext2_alloc.c:914 #4 0xffffffff802c90d5 in ext2_hashalloc (ip=0xfffffe006ae92b00, cg=11, pref=Variable "pref" is not available. ) at /home/svn/head/sys/fs/ext2fs/ext2_alloc.c:606 #5 0xffffffff802c930a in ext2_alloc (ip=0xfffffe006ae92b00, lbn=Variable "lbn" is not available. ) at /home/svn/head/sys/fs/ext2fs/ext2_alloc.c:116 #6 0xffffffff802ca268 in ext2_balloc (ip=0xfffffe006ae92b00, lbn=9, size=Variable "size" is not available. ) at /home/svn/head/sys/fs/ext2fs/ext2_balloc.c:139 #7 0xffffffff802d0fb2 in ext2_write (ap=0xffffff80950eb9b0) at ext2_readwrite.c:238 #8 0xffffffff805a4b83 in VOP_WRITE_APV (vop=0xffffffff8078a000, a=0xffffff80950eb9b0) at vnode_if.c:951 #9 0xffffffff803be602 in vn_write (fp=0xfffffe0001c7f8c0, uio=0xffffff80950ebab0, active_cred=0xfffffe001a271e00, flags=0, td=Variable "td" is not available. ) at vnode_if.h:413 #10 0xffffffff80365225 in dofilewrite (td=0xfffffe001a6c5000, fd=4, fp=0xfffffe0001c7f8c0, auio=0xffffff80950ebab0, offset=Variable "offset" is not available. ) at file.h:238 #11 0xffffffff80366a30 in kern_writev (td=0xfffffe001a6c5000, fd=4, auio=0xffffff80950ebab0) at /home/svn/head/sys/kern/sys_generic.c:447 #12 0xffffffff80366b35 in write (td=Variable "td" is not available. ) at /home/svn/head/sys/kern/sys_generic.c:363 #13 0xffffffff8035f2da in syscallenter (td=0xfffffe001a6c5000, sa=0xffffff80950ebbb0) at /home/svn/head/sys/kern/subr_trap.c:318 #14 0xffffffff80563c4c in syscall (frame=0xffffff80950ebc50) at /home/svn/head/sys/amd64/amd64/trap.c:938 #15 0xffffffff8054e982 in Xfast_syscall () at /home/svn/head/sys/amd64/amd64/exception.S:381 #16 0x000000080073c24c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Apr 25 19:55:41 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9BE341065691 for ; Mon, 25 Apr 2011 19:55:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B98EC15514E for ; Mon, 25 Apr 2011 19:55:38 +0000 (UTC) Message-ID: <4DB5D1BA.5030100@FreeBSD.org> Date: Mon, 25 Apr 2011 12:55:38 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Do the IDs under /dev/ufsid change when the partition is newfs'ed? 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, 25 Apr 2011 19:55:41 -0000 INRE the current discussion about labeling and how to refer to devices in fstab, I'm curious if the IDs in /dev/ufsid change when the partition is newfs'ed. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Apr 25 21:34:31 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 DE79F106564A; Mon, 25 Apr 2011 21:34:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5FF58FC20; Mon, 25 Apr 2011 21:34:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6A85F46B98; Mon, 25 Apr 2011 17:34:31 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F0B8D8A01B; Mon, 25 Apr 2011 17:34:30 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 25 Apr 2011 17:34:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DB5CF3C.9030002@FreeBSD.org> In-Reply-To: <4DB5CF3C.9030002@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104251734.30284.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 25 Apr 2011 17:34:31 -0400 (EDT) Cc: Subject: Re: panic: ext2fs_alloccg: map corrupted 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, 25 Apr 2011 21:34:32 -0000 On Monday, April 25, 2011 3:45:00 pm Doug Barton wrote: > I got the following panic on 9-current, r216869, amd64 SMP on a core 2 > duo system. I'm running the older version (from 2011-01-01) to try and > determine where the problem I'm having with stability on -current first > occurred. If this problem was fixed between now and then, no worries. > > This panic happened during heavy disk activity on the ext2fs partition. > The file core.txt.0.216869 is in my home directory on freefall if anyone > wants to take a look. This looks like the panic that you reported earlier (and tested the fix for IIRC). The fix was comitted in 218438: ------------------------------------------------------------------------ r218438 | jhb | 2011-02-08 08:02:25 -0500 (Tue, 08 Feb 2011) | 6 lines After reading a bitmap block for i-nodes or blocks, recheck the count of free i-nodes or blocks to handle a race where another thread might have allocated the last i-node or block while we were waiting for the buffer. Tested by: dougb -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 25 21:45:01 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 57E641065670; Mon, 25 Apr 2011 21:45:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 33FFA150CAD; Mon, 25 Apr 2011 21:45:01 +0000 (UTC) Message-ID: <4DB5EB5C.6040906@FreeBSD.org> Date: Mon, 25 Apr 2011 14:45:00 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4DB5CF3C.9030002@FreeBSD.org> <201104251734.30284.jhb@freebsd.org> In-Reply-To: <201104251734.30284.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: panic: ext2fs_alloccg: map corrupted 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, 25 Apr 2011 21:45:01 -0000 On 04/25/2011 14:34, John Baldwin wrote: > On Monday, April 25, 2011 3:45:00 pm Doug Barton wrote: >> I got the following panic on 9-current, r216869, amd64 SMP on a core 2 >> duo system. I'm running the older version (from 2011-01-01) to try and >> determine where the problem I'm having with stability on -current first >> occurred. If this problem was fixed between now and then, no worries. >> >> This panic happened during heavy disk activity on the ext2fs partition. >> The file core.txt.0.216869 is in my home directory on freefall if anyone >> wants to take a look. > > This looks like the panic that you reported earlier (and tested the fix for > IIRC). The fix was comitted in 218438: Yeah, I thought it looked familiar. :-/ Sorry for not digging into it deeper myself before reporting, and thanks for looking into it. I'm having massive problems with -current atm, and I'm trying to do a binary search to find out when they started in the middle of also trying to get $REALWORK done. Since I was just able to trigger the problem I'm seeing without heavy access on my ext2fs partition, I'm thinking that what I might do is back all of my sources up to the point in the binary search that I'm testing but then 'cd /sys/fs/ext2fs && svn up', does that sound safe? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 12:44: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 21B10106564A for ; Tue, 26 Apr 2011 12:44:01 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD6478FC14 for ; Tue, 26 Apr 2011 12:44:00 +0000 (UTC) Received: by qwc9 with SMTP id 9so310912qwc.13 for ; Tue, 26 Apr 2011 05:44: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:cc:content-type :content-transfer-encoding; bh=DdRowFeY4X+Q+MAnPz+oUFWc9Z/8UHVijdvevOElk74=; b=wCWDk7Cv5rcrFOxeMdTt6oBaL4gyO26MYVgpjO0tM1U6LE4aN/lQZo1MBEQ7o6OfAe P0XmDjIoH7DCsoFXvo7tmBZKALB9zS7pOGYR4pUjZNqP5bZ3LOz3q243cRaLfKYYw1U3 z9yl4BV6hf1t2NEM1cH/YzK4P3VHEuyy6+C0U= 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 :cc:content-type:content-transfer-encoding; b=aF/KsbegsVAhK5Q2dzAN389KH1/oFK05cXOuU5z3NN1NamVBQp9my9ogg/lPhUqsGl i3a76mp+f/yzXW49W0eQsE/rpouApgJWO0iblRi2yn4n+9BcP4KVuFtLKISsUBUwJ7Hz /LseZ2TJHrYyL7IsSD1FyMw2D/XS+vuOeHiNY= MIME-Version: 1.0 Received: by 10.229.127.104 with SMTP id f40mr505006qcs.48.1303820131711; Tue, 26 Apr 2011 05:15:31 -0700 (PDT) Received: by 10.229.18.68 with HTTP; Tue, 26 Apr 2011 05:15:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2011 20:15:31 +0800 Message-ID: From: ambrosehuang ambrose To: "Conall O'Brien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Problems Terminating zpool scrub... 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, 26 Apr 2011 12:44:01 -0000 Could you post your PR number?I was curious about the driver used by West Digital Disk, cause I use the WR10EARS? 2011/4/25 Conall O'Brien > > On 15 April 2011 15:59, Conall O'Brien wrote: > > Hello, > > > > > > I've got a NAS box running 8-STABLEW [1] which I'm running with 5x > > Western Digital 2TB disks. > > > > > > One of the disks was having DMA issues as reported in dmesg, so I > > began the usual zfs workflow of "zpool offline pool dev", physically > > removing it and tried to "zpool replace pool dev" but my attempts to > > do so fail, actually the zpool command keeps ending up in > > uninterruptable wait (the D state). Before resorting to replacing the > > disk, a zpool scrub was in progress. Now, I can't kill it using "zpool > > scrub -s pool", it too ends up in the D state. > > > > > > Is there another way than "zpool scrub -s pool" to terminate a scrub > > process, so I can proceed with the disk replacement. I care more about > > resilvering my pool before getting around to scrubbing it. > > > > > > Thanks! > > > > > > [1] For completeness, uname -a reports FreeBSD galvatron.taku.ie > > 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Mar 19 13:18:46 UTC 2011 > > root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON =A0amd64 > > I worked out the problem. There's a regression in one of the drivers > between the kernel I was running and my previous kernel: > > FreeBSD galvatron.taku.ie 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: > Wed Dec 29 04:00:27 UTC 2010 > root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON =A0amd64 > > > I'll file a PR to get it fixed. > > -- > > Conall O'Brien > _______________________________________________ > 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 Tue Apr 26 13:25: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 CD7FE106566B for ; Tue, 26 Apr 2011 13:25:01 +0000 (UTC) (envelope-from conall@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF608FC15 for ; Tue, 26 Apr 2011 13:25:01 +0000 (UTC) Received: by wwc33 with SMTP id 33so595650wwc.31 for ; Tue, 26 Apr 2011 06:25:00 -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=RZ0nJouV3WijanKQCUih2nvJyl9tKH5xvBCDVcopbpE=; b=ww2RQTn1Kh9a+dwNJD6tgAEjVWiJzMCh6Y0SS/k5Gv7/7YZh+fPnGulNjB+7hlrgX7 diu4rViArCqBjxSwi3oQ4Ps3XR/b0rzITf/+sDAVbS/YUNn+n5oj4LFoj7PMgYzURExi FHfRCMLQRxxgcftf+NQo+tf10IJ3VUOa//Gf8= 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=qcYiiS2+VcRqij2p1QmEOIOiruD+J1xm/eEV7SJF96XDsBixfjC6VRYOYoGG1nqCU7 0TLWFJ0VJFKeTnmMMf/VZqvWcaB6LJddnTFlQC4oZHLijfjCxS2WDSMhVzUmNr/ED76G FPJOpa99IvV4oOyM9IDcoFrN0EhggN0qhhbbc= MIME-Version: 1.0 Received: by 10.216.159.75 with SMTP id r53mr735852wek.98.1303824300165; Tue, 26 Apr 2011 06:25:00 -0700 (PDT) Sender: conall@gmail.com Received: by 10.216.48.18 with HTTP; Tue, 26 Apr 2011 06:25:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2011 14:25:00 +0100 X-Google-Sender-Auth: WRIsD6E1L0Gyep4EY5yb5Z9F6GU Message-ID: From: "Conall O'Brien" To: ambrosehuang ambrose Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Problems Terminating zpool scrub... 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, 26 Apr 2011 13:25:02 -0000 On 26 April 2011 13:15, ambrosehuang ambrose wrote: > Could you post your PR number?I was curious about the driver used by > West Digital Disk, cause I use > the WR10EARS? http://www.freebsd.org/cgi/query-pr.cgi?pr=3D156647 I chalked it up to the SATA controller, since only 2 of my 5 identical WD20EARS disks were reporting DMA issues. > > 2011/4/25 Conall O'Brien >> >> On 15 April 2011 15:59, Conall O'Brien wrote: >> > Hello, >> > >> > >> > I've got a NAS box running 8-STABLEW [1] which I'm running with 5x >> > Western Digital 2TB disks. >> > >> > >> > One of the disks was having DMA issues as reported in dmesg, so I >> > began the usual zfs workflow of "zpool offline pool dev", physically >> > removing it and tried to "zpool replace pool dev" but my attempts to >> > do so fail, actually the zpool command keeps ending up in >> > uninterruptable wait (the D state). Before resorting to replacing the >> > disk, a zpool scrub was in progress. Now, I can't kill it using "zpool >> > scrub -s pool", it too ends up in the D state. >> > >> > >> > Is there another way than "zpool scrub -s pool" to terminate a scrub >> > process, so I can proceed with the disk replacement. I care more about >> > resilvering my pool before getting around to scrubbing it. >> > >> > >> > Thanks! >> > >> > >> > [1] For completeness, uname -a reports FreeBSD galvatron.taku.ie >> > 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Mar 19 13:18:46 UTC 2011 >> > root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON =C2=A0amd64 >> >> I worked out the problem. There's a regression in one of the drivers >> between the kernel I was running and my previous kernel: >> >> FreeBSD galvatron.taku.ie 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: >> Wed Dec 29 04:00:27 UTC 2010 >> root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON =C2=A0amd64 >> >> >> I'll file a PR to get it fixed. >> >> -- >> >> Conall O'Brien >> _______________________________________________ >> 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" > --=20 Conall O'Brien From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 13:49:07 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 3A6C9106566B for ; Tue, 26 Apr 2011 13:49:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id D8CD78FC0C for ; Tue, 26 Apr 2011 13:49:05 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id cDlg1g00A1YDfWL5BDp6Mw; Tue, 26 Apr 2011 13:49:06 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.westchester.pa.mail.comcast.net with comcast id cDp41g01Q1t3BNj3gDp5l7; Tue, 26 Apr 2011 13:49:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2879A9B418; Tue, 26 Apr 2011 06:49:03 -0700 (PDT) Date: Tue, 26 Apr 2011 06:49:03 -0700 From: Jeremy Chadwick To: Conall O'Brien Message-ID: <20110426134903.GA62578@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Problems Terminating zpool scrub... 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, 26 Apr 2011 13:49:07 -0000 On Tue, Apr 26, 2011 at 02:25:00PM +0100, Conall O'Brien wrote: > On 26 April 2011 13:15, ambrosehuang ambrose wrote: > > Could you post your PR number?I was curious about the driver used by > > West Digital Disk, cause I use > > the WR10EARS? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=156647 > > I chalked it up to the SATA controller, since only 2 of my 5 identical > WD20EARS disks were reporting DMA issues. > > > > > 2011/4/25 Conall O'Brien > >> > >> On 15 April 2011 15:59, Conall O'Brien wrote: > >> > Hello, > >> > > >> > > >> > I've got a NAS box running 8-STABLEW [1] which I'm running with 5x > >> > Western Digital 2TB disks. > >> > > >> > > >> > One of the disks was having DMA issues as reported in dmesg, so I > >> > began the usual zfs workflow of "zpool offline pool dev", physically > >> > removing it and tried to "zpool replace pool dev" but my attempts to > >> > do so fail, actually the zpool command keeps ending up in > >> > uninterruptable wait (the D state). Before resorting to replacing the > >> > disk, a zpool scrub was in progress. Now, I can't kill it using "zpool > >> > scrub -s pool", it too ends up in the D state. > >> > > >> > > >> > Is there another way than "zpool scrub -s pool" to terminate a scrub > >> > process, so I can proceed with the disk replacement. I care more about > >> > resilvering my pool before getting around to scrubbing it. > >> > > >> > > >> > Thanks! > >> > > >> > > >> > [1] For completeness, uname -a reports FreeBSD galvatron.taku.ie > >> > 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Mar 19 13:18:46 UTC 2011 > >> > root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON ??amd64 > >> > >> I worked out the problem. There's a regression in one of the drivers > >> between the kernel I was running and my previous kernel: > >> > >> FreeBSD galvatron.taku.ie 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: > >> Wed Dec 29 04:00:27 UTC 2010 > >> root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON ??amd64 > >> > >> > >> I'll file a PR to get it fixed. The PR is extremely terse/sub-part quality. There isn't actual evidence of the problem being a driver regression. What needs to be provided in the PR: - Relevant dmesg output (pertaining to ataX and adX devices and anything else seen around that time; stuff from /var/adm/messages might be more useful since it contains timestamps) - Full dmesg seen during a fresh reboot - vmstat -i - atacontrol cap ataX (for each ataX channel. You can XXX out the serial number if desired) - smartctl -a /dev/adX (for each disk, be sure to label which disk is associated with what data. You can XXX out the serial number if desired) What really needs to be shown are the actual errors themselves, and in sequential order / with timestamps. "DMA errors" is too vague; I want to assume READ_DMA48 but I cannot assume that. Next: I'm not sure if your system support its, but can you run the controller in AHCI mode (BIOS setting) and load ahci.ko instead (ahci_load="yes" in /boot/loader.conf, your disks will change to /dev/adaX)? If so, this would allow you to narrow down whether or not the issue is truly a driver problem. You should try this *before* attempting the below. Next: Try updating your source to something newer than March 19th. There have been ata(4) changes since then that might pertain to your issue. If the same issue happens on a present-day build of RELENG_8 then we can start by trying to narrow it down to commits between, roughly, late December 2010 to mid-March 2011. Since you follow RELENG_8, you will need to follow commits. src/sys/dev/ata is what's relevant here, as well as the chipsets/ directory under that. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ Let's get this figured out before other users start correlating their problems with whatever this is. -- | 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 Tue Apr 26 13:55:31 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 2F5401065689; Tue, 26 Apr 2011 13:55:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 082608FC1C; Tue, 26 Apr 2011 13:55:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A9B0946B2A; Tue, 26 Apr 2011 09:55:30 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2A73E8A027; Tue, 26 Apr 2011 09:55:30 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Tue, 26 Apr 2011 09:45:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DB5CF3C.9030002@FreeBSD.org> <201104251734.30284.jhb@freebsd.org> <4DB5EB5C.6040906@FreeBSD.org> In-Reply-To: <4DB5EB5C.6040906@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104260945.11691.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 26 Apr 2011 09:55:30 -0400 (EDT) Cc: freebsd-fs@freebsd.org Subject: Re: panic: ext2fs_alloccg: map corrupted 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, 26 Apr 2011 13:55:31 -0000 On Monday, April 25, 2011 5:45:00 pm Doug Barton wrote: > Since I was just able to trigger the problem I'm seeing without heavy > access on my ext2fs partition, I'm thinking that what I might do is back > all of my sources up to the point in the binary search that I'm testing > but then 'cd /sys/fs/ext2fs && svn up', does that sound safe? Yes. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 14:49:32 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 4E1C6106566C for ; Tue, 26 Apr 2011 14:49:32 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 79DAB8FC13 for ; Tue, 26 Apr 2011 14:49:31 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id p3Q7SMm8037891; Tue, 26 Apr 2011 02:28:23 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id p3Q7SMLW037890; Tue, 26 Apr 2011 02:28:22 -0500 (CDT) (envelope-from brooks) Date: Tue, 26 Apr 2011 02:28:22 -0500 From: Brooks Davis To: Doug Barton Message-ID: <20110426072822.GB37806@lor.one-eyed-alien.net> References: <4DB5D1BA.5030100@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <4DB5D1BA.5030100@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 26 Apr 2011 02:28:23 -0500 (CDT) Cc: freebsd-fs@FreeBSD.org Subject: Re: Do the IDs under /dev/ufsid change when the partition is newfs'ed? 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, 26 Apr 2011 14:49:32 -0000 --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2011 at 12:55:38PM -0700, Doug Barton wrote: > INRE the current discussion about labeling and how to refer to devices=20 > in fstab, I'm curious if the IDs in /dev/ufsid change when the partition= =20 > is newfs'ed. A simple experiment confirms the answer is yes: [2:33pm] brooks@stormwind (~): ls -la /dev/ufsid/ total 1 dr-xr-xr-x 2 root wheel 512 Apr 1 21:37 . dr-xr-xr-x 7 root wheel 512 Apr 1 21:37 .. crw-r----- 1 root operator 0, 108 Apr 26 14:33 4db6d7a0726eab90 crw-r----- 1 root operator 0, 123 Apr 26 14:33 4db6d7a0726eab90s1 [2:33pm] brooks@stormwind (~): sudo newfs /dev/ad7 > /dev/null [2:33pm] brooks@stormwind (~): ls -la /dev/ufsid/ total 1 dr-xr-xr-x 2 root wheel 512 Apr 1 21:37 . dr-xr-xr-x 7 root wheel 512 Apr 1 21:37 .. crw-r----- 1 root operator 0, 108 Apr 26 14:33 4db6d7c2389adac2 crw-r----- 1 root operator 0, 123 Apr 26 14:33 4db6d7c2389adac2s1 [2:33pm] brooks@stormwind (~):=20 -- Brooks --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFNtnQWXY6L6fI4GtQRApCNAJ0WDNl7dyQ7p1z5KiqEPnXoQ6vTyACgmnKO yyltqe2oyD3z0kLEXccdZfo= =fxvR -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 17:39:59 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 EEFFC106566C for ; Tue, 26 Apr 2011 17:39:59 +0000 (UTC) (envelope-from conall@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B85F8FC12 for ; Tue, 26 Apr 2011 17:39:59 +0000 (UTC) Received: by wyf23 with SMTP id 23so835121wyf.13 for ; Tue, 26 Apr 2011 10:39:58 -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=eZs0OxCKMhch8UOWlI1/94K5DSCIsLB0x8a6XqkB7KU=; b=g8EUQY1BGP3K2kmoeEIR1TjidbqvzlxbySqrfhgVZwJ27am/nKZ5oqu0r2GGtx9Yr4 FPl/avcvp/B0xFIrSTCeDEANRstCYEjdRB6r865jT6ApTRB6m82l3OLw8kAliGb+bk/+ 9N/yfhgYH8Dp9Qg3YFDRPTptI6U8igmM9bS4k= 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=mDiFoWECV30p/ZeOFCA6+gd8rBRGBOq2EOEN+wVE0QNJ98uw4sm8RO7Zrm79tz+rCq SJppp+/aMutojhT2S+JbdmVJtDckhz7IsU5pZB03HEwYLJ99fsBMfehN33dtQzKeGuAL aZnBmYH9RKtxKs3WsCYgKKSjsk/csy4qb+8lY= MIME-Version: 1.0 Received: by 10.216.46.21 with SMTP id q21mr4909663web.113.1303839598246; Tue, 26 Apr 2011 10:39:58 -0700 (PDT) Sender: conall@gmail.com Received: by 10.216.48.18 with HTTP; Tue, 26 Apr 2011 10:39:58 -0700 (PDT) In-Reply-To: <20110426134903.GA62578@icarus.home.lan> References: <20110426134903.GA62578@icarus.home.lan> Date: Tue, 26 Apr 2011 18:39:58 +0100 X-Google-Sender-Auth: mHj2Qk83XYWE7eeqnfyin_ytkSY Message-ID: From: "Conall O'Brien" To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Problems Terminating zpool scrub... 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, 26 Apr 2011 17:40:00 -0000 On 26 April 2011 14:49, Jeremy Chadwick wrote: > On Tue, Apr 26, 2011 at 02:25:00PM +0100, Conall O'Brien wrote: >> On 26 April 2011 13:15, ambrosehuang ambrose wrot= e: >> > Could you post your PR number?I was curious about the driver used by >> > West Digital Disk, cause I use >> > the WR10EARS? >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D156647 >> >> I chalked it up to the SATA controller, since only 2 of my 5 identical >> WD20EARS disks were reporting DMA issues. >> >> > >> > 2011/4/25 Conall O'Brien >> >> >> >> On 15 April 2011 15:59, Conall O'Brien wrote: >> >> > Hello, >> >> > >> >> > >> >> > I've got a NAS box running 8-STABLEW [1] which I'm running with 5x >> >> > Western Digital 2TB disks. >> >> > >> >> > >> >> > One of the disks was having DMA issues as reported in dmesg, so I >> >> > began the usual zfs workflow of "zpool offline pool dev", physicall= y >> >> > removing it and tried to "zpool replace pool dev" but my attempts t= o >> >> > do so fail, actually the zpool command keeps ending up in >> >> > uninterruptable wait (the D state). Before resorting to replacing t= he >> >> > disk, a zpool scrub was in progress. Now, I can't kill it using "zp= ool >> >> > scrub -s pool", it too ends up in the D state. >> >> > >> >> > >> >> > Is there another way than "zpool scrub -s pool" to terminate a scru= b >> >> > process, so I can proceed with the disk replacement. I care more ab= out >> >> > resilvering my pool before getting around to scrubbing it. >> >> > >> >> > >> >> > Thanks! >> >> > >> >> > >> >> > [1] For completeness, uname -a reports FreeBSD galvatron.taku.ie >> >> > 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Mar 19 13:18:46 UTC 2011 >> >> > root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON ??amd64 >> >> >> >> I worked out the problem. There's a regression in one of the drivers >> >> between the kernel I was running and my previous kernel: >> >> >> >> FreeBSD galvatron.taku.ie 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: >> >> Wed Dec 29 04:00:27 UTC 2010 >> >> root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON ??amd64 >> >> >> >> >> >> I'll file a PR to get it fixed. > > The PR is extremely terse/sub-part quality. =C2=A0There isn't actual evid= ence > of the problem being a driver regression. =C2=A0What needs to be provided= in > the PR: Yeah, I wasn't sure what specifics would be needed, but I wanted to open a PR and go from there. It was the first time I've run into a kernel related issue, PRs for bugs in the ports collection are so much easier to describe. > - Relevant dmesg output (pertaining to ataX and adX devices and anything > =C2=A0else seen around that time; stuff from /var/adm/messages might be m= ore > =C2=A0useful since it contains timestamps) > - Full dmesg seen during a fresh reboot > - vmstat -i > - atacontrol cap ataX (for each ataX channel. =C2=A0You can XXX out the > =C2=A0serial number if desired) > - smartctl -a /dev/adX (for each disk, be sure to label which disk > =C2=A0is associated with what data. =C2=A0You can XXX out the serial numb= er if > =C2=A0desired) > > What really needs to be shown are the actual errors themselves, and in > sequential order / with timestamps. =C2=A0"DMA errors" is too vague; I wa= nt > to assume READ_DMA48 but I cannot assume that. Now that my RAID array is healthy again, I'm happy to reboot into my suspect kernel and collect better diagnostics reports. > Next: > > I'm not sure if your system support its, but can you run the controller > in AHCI mode (BIOS setting) and load ahci.ko instead (ahci_load=3D"yes" i= n > /boot/loader.conf, your disks will change to /dev/adaX)? =C2=A0If so, thi= s > would allow you to narrow down whether or not the issue is truly a > driver problem. =C2=A0You should try this *before* attempting the below. I actually intended to convert my disks over to AHCI anyway, to facilitiate hot swapping better. I assume I can do a "zpool import" to get my ZFS pool to work using the new devices. > Try updating your source to something newer than March 19th. =C2=A0There = have > been ata(4) changes since then that might pertain to your issue. =C2=A0If= the > same issue happens on a present-day build of RELENG_8 then we can start > by trying to narrow it down to commits between, roughly, late December > 2010 to mid-March 2011. =C2=A0Since you follow RELENG_8, you will need to > follow commits. =C2=A0src/sys/dev/ata is what's relevant here, as well as= the > chipsets/ directory under that. Agreed, I probably shouldn't have left it so long between kernel rebuilds. I guess I was hoping there weren't too many changes related to my SATA controller, but that does naively assume the problem is the SATA controller driver. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ > > Let's get this figured out before other users start correlating their > problems with whatever this is. Agreed. --=20 Conall O'Brien From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 17:41:07 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 5E161106566C; Tue, 26 Apr 2011 17:41:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C0EA914E05C; Tue, 26 Apr 2011 17:41:06 +0000 (UTC) Message-ID: <4DB703B2.3030106@FreeBSD.org> Date: Tue, 26 Apr 2011 10:41:06 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brooks Davis References: <4DB5D1BA.5030100@FreeBSD.org> <20110426072822.GB37806@lor.one-eyed-alien.net> In-Reply-To: <20110426072822.GB37806@lor.one-eyed-alien.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Do the IDs under /dev/ufsid change when the partition is newfs'ed? 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, 26 Apr 2011 17:41:07 -0000 On 04/26/2011 00:28, Brooks Davis wrote: > On Mon, Apr 25, 2011 at 12:55:38PM -0700, Doug Barton wrote: >> INRE the current discussion about labeling and how to refer to devices >> in fstab, I'm curious if the IDs in /dev/ufsid change when the partition >> is newfs'ed. > > A simple experiment confirms the answer is yes: Thanks. I didn't think I had a spare partition that I could newfs, then late last night I remembered that I did. So this sort of throws cold water on the idea of using ufsids in fstab as a way to avoid problems with the ata-cam conversion. I'll experiment with glabel on my own, meanwhile does anyone know off hand if there is a way to write something to a UFS partition that won't be erased when it is newfs'ed? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 18:00:57 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C2BBB106566C; Tue, 26 Apr 2011 18:00:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5D304150EE9; Tue, 26 Apr 2011 18:00:57 +0000 (UTC) Message-ID: <4DB70859.7040207@FreeBSD.org> Date: Tue, 26 Apr 2011 11:00:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4DB5CF3C.9030002@FreeBSD.org> <201104251734.30284.jhb@freebsd.org> <4DB5EB5C.6040906@FreeBSD.org> <201104260945.11691.jhb@freebsd.org> In-Reply-To: <201104260945.11691.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: panic: ext2fs_alloccg: map corrupted 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, 26 Apr 2011 18:00:57 -0000 On 04/26/2011 06:45, John Baldwin wrote: > On Monday, April 25, 2011 5:45:00 pm Doug Barton wrote: >> Since I was just able to trigger the problem I'm seeing without heavy >> access on my ext2fs partition, I'm thinking that what I might do is back >> all of my sources up to the point in the binary search that I'm testing >> but then 'cd /sys/fs/ext2fs&& svn up', does that sound safe? > > Yes. Good to know, since that's what I did all day yesterday. :) Thanks again, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 18:04:58 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id DC3B61065670; Tue, 26 Apr 2011 18:04:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C701415114C; Tue, 26 Apr 2011 18:04:57 +0000 (UTC) Message-ID: <4DB70949.6090104@FreeBSD.org> Date: Tue, 26 Apr 2011 11:04:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Motin , freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 18:04:58 -0000 Alexander, I'm not nearly as smart as you are, so please explain to me like I'm dense. :) Why can we not simply give the devices created by ata-cam the same names they have under the old ata system? Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 18:20:17 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 73ADA1065676; Tue, 26 Apr 2011 18:20:17 +0000 (UTC) Date: Tue, 26 Apr 2011 18:20:17 +0000 From: Alexander Best To: Doug Barton Message-ID: <20110426182017.GA92471@freebsd.org> References: <4DB70949.6090104@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DB70949.6090104@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, Alexander Motin Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 18:20:17 -0000 On Tue Apr 26 11, Doug Barton wrote: > Alexander, > > I'm not nearly as smart as you are, so please explain to me like I'm > dense. :) Why can we not simply give the devices created by ata-cam the > same names they have under the old ata system? personally i think maintaining backwards compatibility to adX is unnecessary. the adaY names will appear in 9.0. anybody upgrading to a major new release should expect to adjust certain config files and it's not really a big deal. other parts like networking e.g. change variable names for /etc/rc.conf quite often and even when bumping the minor version number. however why ATA_CAM is using adaX and not keep the adY naming convention i do not know. cheers. alex ps: i know your question was referring to alexander motin. ;) just wanted to blabber out my 0.02$. ;) > > > Thanks, > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > -- a13x From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 18:29:57 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 81E01106566C; Tue, 26 Apr 2011 18:29:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8B63B1A62A4; Tue, 26 Apr 2011 18:29:39 +0000 (UTC) Message-ID: <4DB70F13.6060002@FreeBSD.org> Date: Tue, 26 Apr 2011 11:29:39 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Best References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> In-Reply-To: <20110426182017.GA92471@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Alexander Motin Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 18:29:57 -0000 On 04/26/2011 11:20, Alexander Best wrote: > personally i think maintaining backwards compatibility to adX is unnecessary. > the adaY names will appear in 9.0. anybody upgrading to a major new release > should expect to adjust certain config files and it's not really a big deal. The problem is that this is not a realistic point of view. When there are very good reasons to make changes like this we do it, but there has to be a *really* good reason. Something like this which is going to cause systems to fail when users reboot them better have an overwhelmingly good reason. And yes, I get that from a developer perspective we expect users to read documentation, they should know what they are doing before they do it, blah blah blah. Like I said, this is NOT a reasonable perspective, and screwing the users over in this way is going to do nothing but damage FreeBSD's reputation. Need I remind everyone on this list of the problems that have resulted from removing support for "dangerously dedicated" disks? Now imagine that 100 times over. So, my question stands. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 18:46:42 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B3CCB10656E7; Tue, 26 Apr 2011 18:46:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0A025153BCA; Tue, 26 Apr 2011 18:46:41 +0000 (UTC) Message-ID: <4DB71311.7080203@FreeBSD.org> Date: Tue, 26 Apr 2011 11:46:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Motin References: <4DB70949.6090104@FreeBSD.org> <4DB70F97.1070809@FreeBSD.org> In-Reply-To: <4DB70F97.1070809@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 18:46:42 -0000 On 04/26/2011 11:31, Alexander Motin wrote: > Hi. > > Doug Barton wrote: >> I'm not nearly as smart as you are, so please explain to me like I'm >> dense. :) Why can we not simply give the devices created by ata-cam the >> same names they have under the old ata system? > > Don't underestimate yourself, or don't make me blush. ;) > > There are two problems: names and unit numbers. > > We can't use same names because old and new stacks coexisting last 18 > months (and they will forever in 8.x), and it was possible to just load > single ahci module of new stack for SATA devices, while PATA were > working via old stack. Using same name would cause collisions. Now when > we are going to switch to the new stack completely, coexistence could be > a bit less important, but there is already number of migrated systems > and they would suffer from the second renaming. > > Even if we do something with names, there is a problem with device unit > numbers. Previous numbering scheme of ATA_STATIC_ID reserved only two > device numbers per ATA channel. It was working fine for PATA times, but > it is not now. When SATA port multipliers are used (and it is not so > rare now), there could be up to 15 devices per channel, plus multiplier > itself. They just won't fit. Thanks for breaking this down so that even I can understand it. :) Given what you've explained here it sounds like the dev symlink stuff that you just committed is the right way to go. If that plan proves successful what I'm thinking is that I can put some code in mergemaster on 9.0-RELEASE that checks for the old device names in /etc/fstab and suggests that the user change them to the new names. I don't generally like to give mergemaster specific knowledge of certain files, but there is precedent for doing so for changes like this, and as long as we are not relying on mergemaster to _fix_ the problem, I'm Ok with doing it that way. So I will stay tuned to see how this develops. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 18:57: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 E9A35106564A for ; Tue, 26 Apr 2011 18:57:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7848FC08 for ; Tue, 26 Apr 2011 18:57:18 +0000 (UTC) Received: by bwz12 with SMTP id 12so1126572bwz.13 for ; Tue, 26 Apr 2011 11:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=A74fnpAPvmZQ5LURRfld/rkx/TwmOR8gDEMY+0aA50A=; b=CeXYNDap6erZxnycSdxP7eC+fQ3rkNd4c82phcgdca7KdE5OffBHWv1y910PXEV5Pt 3Su+2aT4vP+n+wJpDBHhAFr4SchVEknmViriwrq4xXq65tpMPhlLxrZRJIZLbVLU3wov CT1/yXDjpajv9imFZClGlDGn+sY3/DNQt6m+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=GHChLIXh5ii9r783XghzthgbwxKKYukx71bgGWKeKK2Nq7ZzwIJycliCMx12z1y98P z2Aw2joj4sYM1W3oYRflT5JGBSIbXb+ac5B31R7tgeP/n2+2a1h+zwSdGa58FXFx87+M NqJROuWP9agKWDzBouLl3EKAawuBI5ut089Is= Received: by 10.204.49.87 with SMTP id u23mr1040392bkf.171.1303842719978; Tue, 26 Apr 2011 11:31:59 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm4012788bkm.6.2011.04.26.11.31.58 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 11:31:59 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB70F97.1070809@FreeBSD.org> Date: Tue, 26 Apr 2011 21:31:51 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Doug Barton References: <4DB70949.6090104@FreeBSD.org> In-Reply-To: <4DB70949.6090104@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 18:57:19 -0000 Hi. Doug Barton wrote: > I'm not nearly as smart as you are, so please explain to me like I'm > dense. :) Why can we not simply give the devices created by ata-cam the > same names they have under the old ata system? Don't underestimate yourself, or don't make me blush. ;) There are two problems: names and unit numbers. We can't use same names because old and new stacks coexisting last 18 months (and they will forever in 8.x), and it was possible to just load single ahci module of new stack for SATA devices, while PATA were working via old stack. Using same name would cause collisions. Now when we are going to switch to the new stack completely, coexistence could be a bit less important, but there is already number of migrated systems and they would suffer from the second renaming. Even if we do something with names, there is a problem with device unit numbers. Previous numbering scheme of ATA_STATIC_ID reserved only two device numbers per ATA channel. It was working fine for PATA times, but it is not now. When SATA port multipliers are used (and it is not so rare now), there could be up to 15 devices per channel, plus multiplier itself. They just won't fit. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 19:00:47 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 269CB106564A; Tue, 26 Apr 2011 19:00:47 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E619014E62F; Tue, 26 Apr 2011 19:00:45 +0000 (UTC) Message-ID: <4DB71654.5060008@FreeBSD.org> Date: Tue, 26 Apr 2011 23:00:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Thunderbird/3.1.9 MIME-Version: 1.0 To: Doug Barton References: <4DB70949.6090104@FreeBSD.org> <4DB70F97.1070809@FreeBSD.org> <4DB71311.7080203@FreeBSD.org> In-Reply-To: <4DB71311.7080203@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDCDFBDBF06BD3BD5F0680976" Cc: freebsd-fs@FreeBSD.org, Alexander Motin Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 19:00:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDCDFBDBF06BD3BD5F0680976 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 26.04.2011 22:46, Doug Barton wrote: > If that plan proves successful what I'm thinking is that I can put some= > code in mergemaster on 9.0-RELEASE that checks for the old device names= > in /etc/fstab and suggests that the user change them to the new names. = I > don't generally like to give mergemaster specific knowledge of certain > files, but there is precedent for doing so for changes like this, and a= s > long as we are not relying on mergemaster to _fix_ the problem, I'm Ok > with doing it that way. So I will stay tuned to see how this develops. mergemaster usually used a bit later than it can help, i mean that we recommend run it after installing kernel and first reboot. --=20 WBR, Andrey V. Elsukov --------------enigDCDFBDBF06BD3BD5F0680976 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJNtxZZAAoJEAHF6gQQyKF61MAH/R2Cv2EmIltf/sYvWB0dTK3g lIqHAUK7oLzRu6DeqNER5He2kB3LN7O30GHI3IwhhsoZmCLUENemQgqlAdUMqGca BgeoijfYO4PY5oxjdAqcwSO3AnUpYPfAZ8Tk3kLPBK9Hhfb+FdFUkZ5T2MRrWyiH qA3F/jkZ4FzAAgE3pMCVXWbzC/Sk+L2DYgRaljmjs8XWsWdjKuB5WS7/8K4M0Hnw DdRkXYwY7UF7aK35B8k1cJIEbhKZvOazt5iQpxJnvmJQXveqIjOqoR7OVjAwcHGL jt2rAjU1xtusbHCyExP2QClrDIAj9dIdkobaywzdlodKSDFCAXc84bP0lWInoMQ= =nSyW -----END PGP SIGNATURE----- --------------enigDCDFBDBF06BD3BD5F0680976-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 19:05:01 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 38337106566B; Tue, 26 Apr 2011 19:05:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F1AB714E9AF; Tue, 26 Apr 2011 19:05:00 +0000 (UTC) Message-ID: <4DB7175C.6060408@FreeBSD.org> Date: Tue, 26 Apr 2011 12:05:00 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4DB70949.6090104@FreeBSD.org> <4DB70F97.1070809@FreeBSD.org> <4DB71311.7080203@FreeBSD.org> <4DB71654.5060008@FreeBSD.org> In-Reply-To: <4DB71654.5060008@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Alexander Motin Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 19:05:01 -0000 On 04/26/2011 12:00, Andrey V. Elsukov wrote: > On 26.04.2011 22:46, Doug Barton wrote: >> If that plan proves successful what I'm thinking is that I can put some >> code in mergemaster on 9.0-RELEASE that checks for the old device names >> in /etc/fstab and suggests that the user change them to the new names. I >> don't generally like to give mergemaster specific knowledge of certain >> files, but there is precedent for doing so for changes like this, and as >> long as we are not relying on mergemaster to _fix_ the problem, I'm Ok >> with doing it that way. So I will stay tuned to see how this develops. > > mergemaster usually used a bit later than it can help, i mean that we > recommend run it after installing kernel and first reboot. Right, that's one reason I don't want mergemaster to be the solution for fixing this. Another is that not everyone uses it, and almost noone who uses freebsd-update uses it. To be clear about what I meant, assuming that there is some solution which allows users with the old adN entries to boot with the new cam-ata devices, mergemaster can detect this condition, and warn the user that they should update their fstab. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 20:46:13 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 C14E21065670; Tue, 26 Apr 2011 20:46:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F94D8FC14; Tue, 26 Apr 2011 20:46:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bc6b:a78d:dcd1:3a34]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 606E54AC1C; Wed, 27 Apr 2011 00:46:11 +0400 (MSD) Date: Wed, 27 Apr 2011 00:46:08 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <5710150841.20110427004608@serebryakov.spb.ru> To: "Andrey V. Elsukov" In-Reply-To: <4DB71654.5060008@FreeBSD.org> References: <4DB70949.6090104@FreeBSD.org> <4DB70F97.1070809@FreeBSD.org> <4DB71311.7080203@FreeBSD.org> <4DB71654.5060008@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.org, Alexander Motin , Doug Barton Subject: Re: Why not just name the cam-ata devices the same as the old names? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:46:13 -0000 Hello, Andrey. You wrote 26 =C1=D0=D2=C5=CC=D1 2011 =C7., 23:00:36: >> files, but there is precedent for doing so for changes like this, and as >> long as we are not relying on mergemaster to _fix_ the problem, I'm Ok >> with doing it that way. So I will stay tuned to see how this develops. > mergemaster usually used a bit later than it can help, i mean that we > recommend run it after installing kernel and first reboot. There is special option `-p', am I right? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 21:41:07 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 1F1F7106566C for ; Tue, 26 Apr 2011 21:41:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 042948FC14 for ; Tue, 26 Apr 2011 21:41:06 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta09.emeryville.ca.mail.comcast.net with comcast id cMfF1g0060x6nqcA9Mh6xL; Tue, 26 Apr 2011 21:41:06 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id cMh41g00K1t3BNj8YMh4Xb; Tue, 26 Apr 2011 21:41:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 47FE49B418; Tue, 26 Apr 2011 14:41:04 -0700 (PDT) Date: Tue, 26 Apr 2011 14:41:04 -0700 From: Jeremy Chadwick To: Conall O'Brien Message-ID: <20110426214104.GA69929@icarus.home.lan> References: <20110426134903.GA62578@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Problems Terminating zpool scrub... 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, 26 Apr 2011 21:41:07 -0000 On Tue, Apr 26, 2011 at 06:39:58PM +0100, Conall O'Brien wrote: > On 26 April 2011 14:49, Jeremy Chadwick wrote: > > On Tue, Apr 26, 2011 at 02:25:00PM +0100, Conall O'Brien wrote: > >> On 26 April 2011 13:15, ambrosehuang ambrose wrote: > >> > Could you post your PR number?I was curious about the driver used by > >> > West Digital Disk, cause I use > >> > the WR10EARS? > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=156647 > >> > >> I chalked it up to the SATA controller, since only 2 of my 5 identical > >> WD20EARS disks were reporting DMA issues. > >> > >> > > >> > 2011/4/25 Conall O'Brien > >> >> > >> >> On 15 April 2011 15:59, Conall O'Brien wrote: > >> >> > Hello, > >> >> > > >> >> > > >> >> > I've got a NAS box running 8-STABLEW [1] which I'm running with 5x > >> >> > Western Digital 2TB disks. > >> >> > > >> >> > > >> >> > One of the disks was having DMA issues as reported in dmesg, so I > >> >> > began the usual zfs workflow of "zpool offline pool dev", physically > >> >> > removing it and tried to "zpool replace pool dev" but my attempts to > >> >> > do so fail, actually the zpool command keeps ending up in > >> >> > uninterruptable wait (the D state). Before resorting to replacing the > >> >> > disk, a zpool scrub was in progress. Now, I can't kill it using "zpool > >> >> > scrub -s pool", it too ends up in the D state. > >> >> > > >> >> > > >> >> > Is there another way than "zpool scrub -s pool" to terminate a scrub > >> >> > process, so I can proceed with the disk replacement. I care more about > >> >> > resilvering my pool before getting around to scrubbing it. > >> >> > > >> >> > > >> >> > Thanks! > >> >> > > >> >> > > >> >> > [1] For completeness, uname -a reports FreeBSD galvatron.taku.ie > >> >> > 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Mar 19 13:18:46 UTC 2011 > >> >> > root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON ??amd64 > >> >> > >> >> I worked out the problem. There's a regression in one of the drivers > >> >> between the kernel I was running and my previous kernel: > >> >> > >> >> FreeBSD galvatron.taku.ie 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: > >> >> Wed Dec 29 04:00:27 UTC 2010 > >> >> root@galvatron.taku.ie:/usr/src/obj/usr/src/sys/GALVATRON ??amd64 > >> >> > >> >> > >> >> I'll file a PR to get it fixed. > > > > The PR is extremely terse/sub-part quality. ??There isn't actual evidence > > of the problem being a driver regression. ??What needs to be provided in > > the PR: > > Yeah, I wasn't sure what specifics would be needed, but I wanted to > open a PR and go from there. It was the first time I've run into a > kernel related issue, PRs for bugs in the ports collection are so much > easier to describe. I understand the situation; "okay, there's some issue here, but I don't know what to put into the PR... well, better file it anyway". It's better than not doing anything at all. > > - Relevant dmesg output (pertaining to ataX and adX devices and anything > > ??else seen around that time; stuff from /var/adm/messages might be more > > ??useful since it contains timestamps) > > - Full dmesg seen during a fresh reboot > > - vmstat -i > > - atacontrol cap ataX (for each ataX channel. ??You can XXX out the > > ??serial number if desired) > > - smartctl -a /dev/adX (for each disk, be sure to label which disk > > ??is associated with what data. ??You can XXX out the serial number if > > ??desired) > > > > What really needs to be shown are the actual errors themselves, and in > > sequential order / with timestamps. ??"DMA errors" is too vague; I want > > to assume READ_DMA48 but I cannot assume that. > > Now that my RAID array is healthy again, I'm happy to reboot into my > suspect kernel and collect better diagnostics reports. Perfect, thank you very much! > > Next: > > > > I'm not sure if your system support its, but can you run the controller > > in AHCI mode (BIOS setting) and load ahci.ko instead (ahci_load="yes" in > > /boot/loader.conf, your disks will change to /dev/adaX)? ??If so, this > > would allow you to narrow down whether or not the issue is truly a > > driver problem. ??You should try this *before* attempting the below. > > I actually intended to convert my disks over to AHCI anyway, to > facilitiate hot swapping better. I assume I can do a "zpool import" to > get my ZFS pool to work using the new devices. You actually don't have to do anything (export or import); ZFS will taste the disks during kernel start, find ZFS metadata, and naturally import everything automatically. Super convenient. > > Try updating your source to something newer than March 19th. ??There have > > been ata(4) changes since then that might pertain to your issue. ??If the > > same issue happens on a present-day build of RELENG_8 then we can start > > by trying to narrow it down to commits between, roughly, late December > > 2010 to mid-March 2011. ??Since you follow RELENG_8, you will need to > > follow commits. ??src/sys/dev/ata is what's relevant here, as well as the > > chipsets/ directory under that. > > Agreed, I probably shouldn't have left it so long between kernel > rebuilds. I guess I was hoping there weren't too many changes related > to my SATA controller, but that does naively assume the problem is the > SATA controller driver. > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ > > > > Let's get this figured out before other users start correlating their > > problems with whatever this is. > > Agreed. I'll be watching the PR. -- | 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 Tue Apr 26 23:30:46 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 90F6E106566B; Tue, 26 Apr 2011 23:30:46 +0000 (UTC) (envelope-from frimik@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 281248FC14; Tue, 26 Apr 2011 23:30:46 +0000 (UTC) Received: by vws18 with SMTP id 18so1135436vws.13 for ; Tue, 26 Apr 2011 16:30:45 -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:cc:content-type; bh=SIjxGBdteM6ANCB4+MCiOYONEorCLv1NGdrrNPKGMaQ=; b=YTwplWhEQphyTskevMQdgaBcL+bbS1Gf7Wsddhgk8BNmTP3bdcarEzMv+V0NDnUXWO gh/VFjDfS151EPw8m57e0jEtnYCNhHrPC5eCjzEtVUtPAnXfExuYgoSD8DneDOwp9cY7 ofAaznrfr8inIih7nDrSMgz+YfIMIrqP20iA4= 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 :cc:content-type; b=Xv2TpOKEMBI0w0hOFLQ45svAiYOZWZgBocsbBhMfy+HGMzxwxAIVN/io2gqa3O7fp+ oU5bawNgmAeJqTdy5iahpLObdPccMV94HgvZZwRInzjVnO1J7wToTjtgpmeB0L90s9VG Bo7VB4F37OC4ryTFl3N1yiTyEyslodsM1bvSw= MIME-Version: 1.0 Received: by 10.52.98.225 with SMTP id el1mr1920788vdb.174.1303859092289; Tue, 26 Apr 2011 16:04:52 -0700 (PDT) Received: by 10.52.163.165 with HTTP; Tue, 26 Apr 2011 16:04:52 -0700 (PDT) In-Reply-To: <4DB70F13.6060002@FreeBSD.org> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> Date: Wed, 27 Apr 2011 01:04:52 +0200 Message-ID: From: Mikael Fridh To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Alexander Best , Alexander Motin Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 23:30:46 -0000 On Tue, Apr 26, 2011 at 8:29 PM, Doug Barton wrote: > On 04/26/2011 11:20, Alexander Best wrote: >> >> personally i think maintaining backwards compatibility to adX is >> unnecessary. >> the adaY names will appear in 9.0. anybody upgrading to a major new >> release >> should expect to adjust certain config files and it's not really a big >> deal. > > The problem is that this is not a realistic point of view. When there are > very good reasons to make changes like this we do it, but there has to be a > *really* good reason. Something like this which is going to cause systems to > fail when users reboot them better have an overwhelmingly good reason. > > And yes, I get that from a developer perspective we expect users to read > documentation, they should know what they are doing before they do it, blah > blah blah. Like I said, this is NOT a reasonable perspective, and screwing > the users over in this way is going to do nothing but damage FreeBSD's > reputation. Need I remind everyone on this list of the problems that have > resulted from removing support for "dangerously dedicated" disks? Now > imagine that 100 times over. Regarding this documentation I gladly read since it's usually well-written - I would very much like for the recommendation to be not to change from adX to adaY, but instead tell me to change to using labels. Is there something missing in the Handbook on using labels or are there some gotchas I'm not thinking about? http://www.freebsd.org/doc/en/books/handbook/geom-glabel.html There was a post recently on freebsd-current: "Re: Switch from legacy ata(4) to CAM-based ATA" saying that "labels and stacked geoms do not work well together", but other than that I have no idea what to watch out for. The only fear I have is that I will one day insert a disk from a similar system with a clashing label such as "root" or "data" and it would mess up the boot, but I would have no one to blame but myself and I could easily reduce that risk by using a more host-unique labelling scheme, such as 'hostymdroot', 'hostymddata' etc (ymd = year month day). Maybe I'm naive and misinformed and really should be more paranoid? Are labels such a perilous affair that you can't just start recommending them and/or default to them? I don't have many FreeBSD systems yet but all of them are using labels in fstab for all disks, gmirrors or usb flash drives and so far it served me well when I had to move disks and usb boot sticks between different and/or failing motherboards and controllers. Mikael From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 23:47:47 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 58D1A106566C; Tue, 26 Apr 2011 23:47:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 92B8214E0F4; Tue, 26 Apr 2011 23:47:46 +0000 (UTC) Message-ID: <4DB759A1.4050201@FreeBSD.org> Date: Tue, 26 Apr 2011 16:47:45 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mikael Fridh References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Alexander Best , Alexander Motin Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 23:47:47 -0000 On 04/26/2011 16:04, Mikael Fridh wrote: > Are labels such a perilous affair that you can't just start > recommending them and/or default to them? As far as I can tell, yes. We have various different tools that do different things, all calling themselves "labels" which don't all work together well. It's also unclear how many (if any) of those solutions will survive the file system being newfs'ed. I made this point elsewhere, but this is an area where linux really has us beat. At install time a UUID is created for a file system if it doesn't already have one and it's referred to that way in fstab. My understanding (although I have yet to test it) is that they survive newfs because they are not located on the fs itself. When I first saw this I thought it was ugly (read, different) but having worked with it a little bit I think it's a much superior method, and would have made the current concerns completely irrelevant. http://www.linux.com/archive/feature/146951 Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 26 23:49:44 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9D2F81065672; Tue, 26 Apr 2011 23:49:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4390D179B84; Tue, 26 Apr 2011 23:49:22 +0000 (UTC) Message-ID: <4DB75A02.9050600@FreeBSD.org> Date: Tue, 26 Apr 2011 16:49:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: lev@FreeBSD.org References: <4DB70949.6090104@FreeBSD.org> <4DB70F97.1070809@FreeBSD.org> <4DB71311.7080203@FreeBSD.org> <4DB71654.5060008@FreeBSD.org> <5710150841.20110427004608@serebryakov.spb.ru> In-Reply-To: <5710150841.20110427004608@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org, "Andrey V. Elsukov" , Alexander Motin Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 26 Apr 2011 23:49:44 -0000 On 04/26/2011 13:46, Lev Serebryakov wrote: > Hello, Andrey. > You wrote 26 апреля 2011 г., 23:00:36: > >>> files, but there is precedent for doing so for changes like this, and as >>> long as we are not relying on mergemaster to _fix_ the problem, I'm Ok >>> with doing it that way. So I will stay tuned to see how this develops. >> mergemaster usually used a bit later than it can help, i mean that we >> recommend run it after installing kernel and first reboot. > There is special option `-p', am I right? mergemaster is not the answer to fixing this problem for the user. Please read the whole thread for the answer to "why not?" -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 00:37: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 9C3401065670 for ; Wed, 27 Apr 2011 00:37:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7F94F8FC0A for ; Wed, 27 Apr 2011 00:37:58 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta04.emeryville.ca.mail.comcast.net with comcast id cPUq1g0051zF43QA4Qdyek; Wed, 27 Apr 2011 00:37:58 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id cQdw1g00n1t3BNj8kQdxUf; Wed, 27 Apr 2011 00:37:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 977009B418; Tue, 26 Apr 2011 17:37:56 -0700 (PDT) Date: Tue, 26 Apr 2011 17:37:56 -0700 From: Jeremy Chadwick To: Doug Barton Message-ID: <20110427003756.GA71905@icarus.home.lan> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DB759A1.4050201@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, Alexander Motin , Alexander Best Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 00:37:58 -0000 On Tue, Apr 26, 2011 at 04:47:45PM -0700, Doug Barton wrote: > On 04/26/2011 16:04, Mikael Fridh wrote: > >Are labels such a perilous affair that you can't just start > >recommending them and/or default to them? > > As far as I can tell, yes. We have various different tools that do > different things, all calling themselves "labels" which don't all > work together well. It's also unclear how many (if any) of those > solutions will survive the file system being newfs'ed. > > I made this point elsewhere, but this is an area where linux really > has us beat. At install time a UUID is created for a file system if > it doesn't already have one and it's referred to that way in fstab. > My understanding (although I have yet to test it) is that they > survive newfs because they are not located on the fs itself. When I > first saw this I thought it was ugly (read, different) but having > worked with it a little bit I think it's a much superior method, and > would have made the current concerns completely irrelevant. > http://www.linux.com/archive/feature/146951 I concur regarding the many different things all calling themselves labels. The most common mistake is for folks to assume glabel(8) is the same thing as newfs(8)'s -L flag. They're unrelated things. Regarding the latter, I'm under the impression FreeBSD GEOM already does exactly that (creates a UUID) -- but only when GPT is in use. The glabel(8) man page hints at this: Support for partition metadata is implemented for: o GPT labels (directory /dev/gpt/). o GPT UUIDs (directory /dev/gptid/). Folks reading the man page should also pay very, very close attention to the difference between "automatic" and "manual" labels. They matter. This topic comes up a couple times a year and tends to bite a user in the butt. The reason I don't care to use name-based labels: They all rely on metadata, which usually involves use of the last LBA on the disk (and metadata implementations vary per filesystem and OS). If the administrator forgets to zero that out before decommissioning a disk (or worse, re-using the disk in another machine), there could be a label conflict and I have no idea how that's handled internally. I'd love to assume "glabel clear" does the right thing when zeroing the metadata, but I have not confirmed this. My personal preference is to rely entirely on device names. I know exactly what physical bay /dev/ada1 correlates with. Thankfully, "camcontrol devlist -v" makes this easier for folks. There was (but no longer) some evidence that use of GPT UUIDs, at least on ZFS, may fail or surprise the user with problems. This has since been fixed, but situations like this have made me very wary: http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007895.html I also remember there being a time where UFS UUIDs were printed on console, but this made a lot of people angry (me not so much, but I was quite surprised) and I think their printing was disabled, or the functionality was turned off entirely. I'm not sure which. I'm talking about this stuff (when you see it, it will bring back memories): http://www.mail-archive.com/freebsd-questions@freebsd.org/msg218431.html GEOM is one of those things on FreeBSD which is like the rabbit hole in Alice in Wonderland. It's never as it appears on the surface; how deep the hole goes is quite amazing. For example, did you know "gpart list" works despite being undocumented? And that "geom part list" is the same command? src/sbin/geom/core contains the magic. Once you see how it's implemented (specifically: everything is "blindly" handed off to the kernel). I spent some time reading all of this code many moons ago. Yup, rabbit hole. The irony (to me anyway) is that all of the userland-centric "stuff" is actually implemented in the kernel via callbacks. When I realised this, it immediately made me think of the whole "Porting OpenBSD's sensors framework to FreeBSD" debacle ~4 years ago. Specifically this post: http://lists.freebsd.org/pipermail/freebsd-arch/2007-July/006625.html libgeom(3) should be doing all the heavy lifting, but that library has been greatly neglected and its documentation even more so. For example, sysinstall still gets its disk geometry data by parsing the hidden sysctl OIB kern.geom.conftxt (you need to use "sysctl -b" to view it). There's also kern.geom.confxml (its purpose is unknown to me). The data in both OIDs isn't available via any other means, yet the entire thing screams "userland API". I came across that tunnel in the rabbit hole when I found that use of gsched(8) flat out breaks sysinstall. There's also libdisk(3), which is used as well, yet the top of the man page states "you should probably be using libgeom(3)". Oh really? This stuff is in such a state of disarray... :-( -- | 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 Apr 27 05:42: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 C93F3106566B; Wed, 27 Apr 2011 05:42:24 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 375D68FC12; Wed, 27 Apr 2011 05:42:24 +0000 (UTC) Received: by gwb15 with SMTP id 15so632861gwb.13 for ; Tue, 26 Apr 2011 22:42:23 -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 :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=EQdtlnsz/Z0UWASKx6eLaUptXCOG7UX9hb9Si7ThmHo=; b=TWuBZs2SLHrgaWPyDT1FGofWL2d5Iusne0khQlueRffCqWC1s3UHvlAYDHDmNZB4U0 aNjhtn1FDfsgjW/ngLV0lDorGxz8kjQ27XoO2muAKLvutk/5KLbSxqw+3t7vpNcAFkSO qBIq87ogGSx4TwSMd/n/xqihfsAN4UGQu8lZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=kpesfuLXmocaKC3LywVuzQdj2qOQA5f3WdH3ejL/DkxAQBo+prdBs5DnZlyN9VghcI 7D0lEgotXxx8z9RZ1GXgdctzca13iyaVS963qwsxQKxkoglm2YPZGgZzq74Nci4gbOfU JSNV22gC1OyUIJo3cSrCNmpPsVz/YTcva4NuU= Received: by 10.151.131.15 with SMTP id i15mr1474208ybn.386.1303882943555; Tue, 26 Apr 2011 22:42:23 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id w15sm701559ybk.1.2011.04.26.22.42.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 22:42:22 -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 p3R5gJhh090388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 01:42:19 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3R5gIZ9090387; Wed, 27 Apr 2011 01:42:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Wed, 27 Apr 2011 01:42:18 -0400 From: "Jason J. Hellenthal" To: Doug Barton Message-ID: <20110427054218.GA88420@DataIX.net> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <4DB759A1.4050201@FreeBSD.org> 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: freebsd-fs@freebsd.org, Alexander Motin , Alexander Best Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 05:42:24 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2011 at 04:47:45PM -0700, Doug Barton wrote: >On 04/26/2011 16:04, Mikael Fridh wrote: >> Are labels such a perilous affair that you can't just start >> recommending them and/or default to them? > >As far as I can tell, yes. We have various different tools that do=20 >different things, all calling themselves "labels" which don't all work=20 >together well. It's also unclear how many (if any) of those solutions=20 >will survive the file system being newfs'ed. > >I made this point elsewhere, but this is an area where linux really has=20 >us beat. At install time a UUID is created for a file system if it=20 >doesn't already have one and it's referred to that way in fstab. My=20 >understanding (although I have yet to test it) is that they survive=20 >newfs because they are not located on the fs itself. When I first saw=20 >this I thought it was ugly (read, different) but having worked with it a= =20 >little bit I think it's a much superior method, and would have made the=20 >current concerns completely irrelevant.=20 >http://www.linux.com/archive/feature/146951 > Hi Doug, I do not know if this was summed up in a easy way by Jeremy's nice message below but in short a summary can be made here to clear that up. /dev/gptid/* /dev/gpt/* * These survive its raw partition being newfs'd * Are only created for disks that are partitioned and contain a GPT table as can be seen with gpart show * Operations on these or the raw partition will not remove them. /dev/ufsid/* /dev/ufs/* * Will not survive a newfs * Are created upon being newfs'd * /dev/ufs/* is the equiv of (tunefs -L) * /dev/ufsid/* is only created by newfs(8) * Operations on these or the raw slice will not remove them. /dev/label/* * Are created by glabel(8) * Will remain with the disk until its raw disk is newfs'd or data overwrites the metadata on the raw disk. * When created only the label should be newfs'd directly as a new on the disk itself would overwrite the metadata stored. * Operations on the label itself is only supported to retain the metadata. =09 The best possible thing you could use here is a GPT scheme for the disks to remain consistent across newfs's. But relying on GPT for all disks will not always work in situations where the disk also involves a operating system that does not support booting off of a GPT disk, like all of Windows XP and then Win7 for non-Itanium based architectures. Yes Win7 last checked was said to only support booting GPT schemes on Itanium systems, so this leaves a lot of systems to only rely on /dev/ufs*/ labels or generic labels. --=20 Regards, (jhell) Jason Hellenthal --KsGdsel6WgEHnImy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNt6y5AAoJEJBXh4mJ2FR+oKAH/05PIBZ2f4QMu5Byb/l0MK7l VR0bjcbwUQg+bYnqDPKwIfUCwo/kfiVYOnlFkAiMA5EBKlR9K/P2XYUHa3edE/ss 2AuO/aOjBqv/TOpVN/N9XsB8zHexu5A5/rZxN1FRSTiK/oKLanhmc69UO5tJqUxm PIEzTunKF4GhG8jBj83q8GFyPLhWiegArTuKgaYs2XgWYAH+5SWVYk1OFfLNxfcz kYM/mHDOlzzASm4axiXa7I+iGFRvoy5W7hNry/aAm4wMu8GOL+gtSkA17O8THEuT R9gugndpnvrL2rinaZyr+QPf1R60EwxNO9FVkEpRkJmPQEefVb4XDE/anoWCV4M= =BqRe -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 05:46:21 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 6F7F9106564A; Wed, 27 Apr 2011 05:46:21 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8E8A8FC0C; Wed, 27 Apr 2011 05:46:20 +0000 (UTC) Received: by gxk28 with SMTP id 28so628557gxk.13 for ; Tue, 26 Apr 2011 22:46:20 -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:cc:content-type; bh=boNt9t5J57VAh4jZnc6m9oIM5rALCalUSTyNBJPoYjo=; b=v7xK5xpvS47BBzwozLyogvycXmwfkTSj47zazbequoBZ9wrAQvu62EZOv6zvQm+P9q uXYQlMWpdP2ETl53NiK1Qpz9TWDLyv/Wv08eyIjQVBKVEOwM8nSNdFchLbkvQQV0/bXI CUw6rPloJk20IbUEo5OB8QnjIb64P/SF95v84= 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 :cc:content-type; b=aCYeMyQWGyfnTUUrVUQP8HMl63EnjDvrlpabjnAHNICnXJLoNDDlDZSAw6ig+7DRVu M0aCNobjWe4N+cT85z3qjC4rVHDc4ITHdr0IQoXhRlFqaNd9vJkG8FzihJlCFjB22Ufl jK2+ORAL00baFGIwzy+3JgdZm8dbhmB+hmL1k= MIME-Version: 1.0 Received: by 10.91.164.27 with SMTP id r27mr1523607ago.204.1303883180062; Tue, 26 Apr 2011 22:46:20 -0700 (PDT) Received: by 10.90.70.18 with HTTP; Tue, 26 Apr 2011 22:46:20 -0700 (PDT) In-Reply-To: <4DB759A1.4050201@FreeBSD.org> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> Date: Tue, 26 Apr 2011 22:46:20 -0700 Message-ID: From: Freddie Cash To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, Alexander Motin , Alexander Best Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 05:46:21 -0000 On Tue, Apr 26, 2011 at 4:47 PM, Doug Barton wrote: > On 04/26/2011 16:04, Mikael Fridh wrote: >> >> Are labels such a perilous affair that you can't just start >> recommending them and/or default to them? > > As far as I can tell, yes. We have various different tools that do different > things, all calling themselves "labels" which don't all work together well. > It's also unclear how many (if any) of those solutions will survive the file > system being newfs'ed. This is where labelling *disks* is the better route. Filesystems come and go, but the disks don't change very often. This is one the nicest things about using FreeBSD systems (all the GEOM stacking and labelling). The only issue I've come across is that GPT stores the secondary header in the last physical sector of the *disk* and not the last physical sector of the GEOM provider, so you end up with spurious "errors" when using labelled disks, gmirror'd labels, and GPT-partitioned mirrors. :( If that one issue was resolved, than a glabel'd disk would be the perfect solution. (going from memory) glabel label mydisk0 da0 glabel label mydisk1 da1 gmirror label label/mydisk0 gm0 gmirror add label/mydisk1 gm0 gpart -s GPT mirror/gm0 Doesn't matter where you move the disks in the system, everything "just works" (with that one "error" message about the secondary GPT label). -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 05:51:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1A1421065670; Wed, 27 Apr 2011 05:51:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 35DBA14FBB1; Wed, 27 Apr 2011 05:51:21 +0000 (UTC) Message-ID: <4DB7AED8.5070602@FreeBSD.org> Date: Tue, 26 Apr 2011 22:51:20 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Jason J. Hellenthal" References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> <20110427054218.GA88420@DataIX.net> In-Reply-To: <20110427054218.GA88420@DataIX.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Alexander Motin , Alexander Best Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 05:51:25 -0000 On 04/26/2011 22:42, Jason J. Hellenthal wrote: > The best possible thing you could use here is a GPT scheme for the disks > to remain consistent across newfs's. But relying on GPT for all disks > will not always work in situations where the disk also involves a > operating system that does not support booting off of a GPT disk, like > all of Windows XP and then Win7 Right. It's also not possible to move to gpt in existing installations where it is impossible (or impractical) to wipe the disk and start over again. Thanks for summarizing, and confirming my concerns. Fortunately, Alexander has already committed a transition mechanism that should be transparent to the vast majority of our users. That will give us until 10.0 to adopt a sane labeling scheme. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 06:03:28 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 C3AB61065676; Wed, 27 Apr 2011 06:03:28 +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 502278FC0A; Wed, 27 Apr 2011 06:03:28 +0000 (UTC) Received: by iwn33 with SMTP id 33so1545949iwn.13 for ; Tue, 26 Apr 2011 23:03:27 -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 :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=x6QjNs+lvsV6NBoQ3alr1n1wQXjUGgHKG9/lkpHlAuA=; b=rZEFukZAVn+UA06HQiXfbQmpi2Dez1DzzfysituFj22gAa9bBTgnkkG0xyQYo8Civk sXHG15cRcZAIpCsLvLhs1ykSsH5NS4OvvNuGD07USVfS9zEVD6TOEG5vJ1Ye7CNX1Xke rQu6l2lK8nJA/rA99/FtSOqEsMS93wufy/nHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=CrF1jBIBQCH2tOqe0/cLokwqjXQ5i409cQMtCZjAZpKyn+Tzf5+D986cYfWmXt+N1J g3ViXiXJIA5e72FQscjaC2+v4XgtS/vUIGNH4S5GjR6w0UekSciLLPUDHx8ldoRdCqHG +V+U3j/VcizXVF/Wzwe2Cn8xWgfSaB3JSdEWo= Received: by 10.42.150.66 with SMTP id z2mr2174846icv.462.1303884207691; Tue, 26 Apr 2011 23:03:27 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id wu17sm182987icb.11.2011.04.26.23.03.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 23:03:26 -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 p3R63MTt091408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 02:03:23 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3R63MJ6091407; Wed, 27 Apr 2011 02:03:22 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Wed, 27 Apr 2011 02:03:22 -0400 From: "Jason J. Hellenthal" To: Doug Barton Message-ID: <20110427060322.GB88420@DataIX.net> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> <20110427054218.GA88420@DataIX.net> <4DB7AED8.5070602@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <4DB7AED8.5070602@FreeBSD.org> 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: freebsd-fs@freebsd.org, Alexander Motin , Alexander Best Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 06:03:28 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2011 at 10:51:20PM -0700, Doug Barton wrote: >On 04/26/2011 22:42, Jason J. Hellenthal wrote: >> The best possible thing you could use here is a GPT scheme for the disks >> to remain consistent across newfs's. But relying on GPT for all disks >> will not always work in situations where the disk also involves a >> operating system that does not support booting off of a GPT disk, like >> all of Windows XP and then Win7 > >Right. It's also not possible to move to gpt in existing installations=20 >where it is impossible (or impractical) to wipe the disk and start over=20 >again. Thanks for summarizing, and confirming my concerns. > >Fortunately, Alexander has already committed a transition mechanism that= =20 >should be transparent to the vast majority of our users. That will give=20 >us until 10.0 to adopt a sane labeling scheme. > Here's to looking forward! ;) --=20 Regards, (jhell) Jason Hellenthal --ftEhullJWpWg/VHq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNt7GqAAoJEJBXh4mJ2FR+HQkH+wbTXyiMhwl8aOmDVsQawNP3 QfPT6vd2oZRA4zCU2RRMTnkfYPyUH1mzNZEUUXMOF/hrgXuW+UbFYP2+qWMiXuPs HaBSC1ebv+gt9R2fh/7fjtydIKd+f/+nhDXN3fL/JHNIMJjvGTHp2N3G7QQSQGrs JNDyQrIzj6YzA73w7SDtdAaiwNrVSwGe+b4zBJhHNWJ+cGau2SemUh/pDuSs7yfa dW4Z2S1qtDD7Y5QyM4B8eN9YPmLopui47jZHomOURowSTRQzfgePstbh1WIBh9dn nEI/gM0+VX12MbcR2ply9GYvu2AkdqvTYOrr+gucOTRij22YexOUc8Ggswu4TPE= =acK+ -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 06:59:45 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 C71BE106566B for ; Wed, 27 Apr 2011 06:59:45 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C45B8FC0C for ; Wed, 27 Apr 2011 06:59:45 +0000 (UTC) Received: by iyj12 with SMTP id 12so1587843iyj.13 for ; Tue, 26 Apr 2011 23:59:44 -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 :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=Atk6IH6trx2ADQw0FhCubaKSWwfqB9m/1nTduDgSxrk=; b=GZ0KzCYjIBQlaM6Wc4QUXBz+G6fC1OTkkTET6C92XRibalaZjinG80nW7HYNwFN56J BHPRdrUsNeuOGqB0iNV7yddZfXkx/j3Sk2MtfXIBomLHMN4ZNvmVFZ6JK1WGGhwRCZvo 5GMHqp300yTIWOjWQMbvp+xnXquZ/yVH/WxX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=d0/B3PkZ/P5bbAWTkgIr9ZKVz5keTTcfVr37+xfL80Ow8Sjz40JFMjY1rYMInUXPaX nbSfl3DDyAB2CtsGYWg+e6aG049zU/X3ykMF+DChOZAYrzAROCSkJCM9NqzAmr0uQPXa 2ti6sUsw+fd8y7S/tTE8DtSZjFA9Dp+qHo+ys= Received: by 10.43.68.204 with SMTP id xz12mr2175092icb.354.1303887584709; Tue, 26 Apr 2011 23:59:44 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id d9sm221254ibb.36.2011.04.26.23.59.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 23:59:43 -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 p3R6xdN2093444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 02:59:40 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3R6xdgd093443; Wed, 27 Apr 2011 02:59:39 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Wed, 27 Apr 2011 02:59:39 -0400 From: "Jason J. Hellenthal" To: Pan Tsu Message-ID: <20110427065939.GD88420@DataIX.net> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> <20110427054218.GA88420@DataIX.net> <864o5kgplh.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Pql8miugIZX0722" Content-Disposition: inline In-Reply-To: <864o5kgplh.fsf@gmail.com> 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: freebsd-fs@freebsd.org Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 06:59:45 -0000 --3Pql8miugIZX0722 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2011 at 10:44:58AM +0400, Pan Tsu wrote: >"Jason J. Hellenthal" writes: > >> I do not know if this was summed up in a easy way by Jeremy's nice >> message below but in short a summary can be made here to clear that up. >> >> /dev/gptid/* /dev/gpt/* >> * These survive its raw partition being newfs'd >> * Are only created for disks that are partitioned >> and contain a GPT table as can be seen with gpart >> show >> * Operations on these or the raw partition will not remove them. > >Not sure if we have support for labels based on disk serial number >similar to /dev/serno/* from DragonFlyBSD but > >/dev/serno/* > * no extra step to setup, e.g. `gpart create' or `newfs' > * survive wiping entire disk, no metadata stored on-disk > * available on every ata disk > Not as far as I am aware. I have not seen anything similiar to that committed to the FreeBSD source within the last six months or before. >As CAM_ATA transition goes such labels could be a better choice as >they'd lessen the pain when compat naming is gone, e.g. in 10-CURRENT. > >> The best possible thing you could use here is a GPT scheme for the disks >> to remain consistent across newfs's. But relying on GPT for all disks >> will not always work in situations where the disk also involves a >> operating system that does not support booting off of a GPT disk, like >> all of Windows XP and then Win7 for non-Itanium based architectures. Yes >> Win7 last checked was said to only support booting GPT schemes on >> Itanium systems, so this leaves a lot of systems to only rely on >> /dev/ufs*/ labels or generic labels. --=20 Regards, (jhell) Jason Hellenthal --3Pql8miugIZX0722 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNt77aAAoJEJBXh4mJ2FR+7ioH/jrgN/KBfkn3vhjd3trtL7Ty gsUZdRgUnQyVG1UNrjxJSY3Psh6FwJRY5mH53DMKl/hfgcJ1SB/bzxxLc9UrnAwr g2l5GUCAcLGVCCn2abURZ4OMs3scEBgwMbshLIUpPQ568t/A49yvGQNPVuFh4EJm oA4205C05+Kz5fDd1fECebLAvU3Mk29pOuj2tbNhZnc/0wtbSQiJqm1w4BTdkEA6 P7O9ld+Oo+osFSbu3N92qP24hUKpIEYUjcEfE5E+SCT+yrX95qLlFO/2nLX8AWl4 W7/E4nQhka8wjAyZZjdlVJpppOgG0R0axFOYrvCUGWV2KZWhMXB7OTkiFj/ox8Y= =128h -----END PGP SIGNATURE----- --3Pql8miugIZX0722-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 07:08: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 E6FA1106566C for ; Wed, 27 Apr 2011 07:08:30 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0D88FC22 for ; Wed, 27 Apr 2011 07:08:30 +0000 (UTC) Received: by wyf23 with SMTP id 23so1316909wyf.13 for ; Wed, 27 Apr 2011 00:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=vQ06J9HnSZC2/UCJgbF+anP31BebyO0noEDCzeGMoE8=; b=TO87UCWu19QigzQ+gBAs3tPIBZzHHeUpfYE8fMX85LI7WPaDaAn8fIWq5ezGgLvunv BcxkEXnnzxNmGggUYVTZtsURdArAirc8qk28VGqrvv+Dfn3vds2HUwPybEVFPSpMVaCV HOkp25ojoNl0jyyDiOelNlaTZ8JzaoztYYTWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=Q9+gjOwI818MP1KquKZ0ERcCeHnvfNtIbU00bRsK45Q3tSQlN7NG6za+WJP7X5vTa/ quxdwxc6JzCGhr1Up8yTGmLnvXArxsMS+CDgcwJptrqNNlsafYqT0HdjNErN2+vPBm+l cBtHVh9avB1yHEIgdXo1vbKdfZ/ISG6Wk4KQg= Received: by 10.227.140.77 with SMTP id h13mr1718733wbu.217.1303886711159; Tue, 26 Apr 2011 23:45:11 -0700 (PDT) Received: from localhost ([87.118.92.174]) by mx.google.com with ESMTPS id p5sm249894wbg.28.2011.04.26.23.45.06 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 23:45:07 -0700 (PDT) From: Pan Tsu To: "Jason J. Hellenthal" References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> <20110427054218.GA88420@DataIX.net> Date: Wed, 27 Apr 2011 10:44:58 +0400 In-Reply-To: <20110427054218.GA88420@DataIX.net> (Jason J. Hellenthal's message of "Wed, 27 Apr 2011 01:42:18 -0400") Message-ID: <864o5kgplh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-fs@freebsd.org Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 07:08:31 -0000 "Jason J. Hellenthal" writes: > I do not know if this was summed up in a easy way by Jeremy's nice > message below but in short a summary can be made here to clear that up. > > /dev/gptid/* /dev/gpt/* > * These survive its raw partition being newfs'd > * Are only created for disks that are partitioned > and contain a GPT table as can be seen with gpart > show > * Operations on these or the raw partition will not remove them. Not sure if we have support for labels based on disk serial number similar to /dev/serno/* from DragonFlyBSD but /dev/serno/* * no extra step to setup, e.g. `gpart create' or `newfs' * survive wiping entire disk, no metadata stored on-disk * available on every ata disk As CAM_ATA transition goes such labels could be a better choice as they'd lessen the pain when compat naming is gone, e.g. in 10-CURRENT. > The best possible thing you could use here is a GPT scheme for the disks > to remain consistent across newfs's. But relying on GPT for all disks > will not always work in situations where the disk also involves a > operating system that does not support booting off of a GPT disk, like > all of Windows XP and then Win7 for non-Itanium based architectures. Yes > Win7 last checked was said to only support booting GPT schemes on > Itanium systems, so this leaves a lot of systems to only rely on > /dev/ufs*/ labels or generic labels. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 10:17: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 F09ED106566B for ; Wed, 27 Apr 2011 10:17:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id D50708FC1A for ; Wed, 27 Apr 2011 10:17:19 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta14.emeryville.ca.mail.comcast.net with comcast id caE81g0050vp7WLAEaHKdL; Wed, 27 Apr 2011 10:17:19 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta05.emeryville.ca.mail.comcast.net with comcast id caHJ1g0061t3BNj8RaHJom; Wed, 27 Apr 2011 10:17:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3B0F59B418; Wed, 27 Apr 2011 03:17:18 -0700 (PDT) Date: Wed, 27 Apr 2011 03:17:18 -0700 From: Jeremy Chadwick To: Pan Tsu Message-ID: <20110427101718.GA82324@icarus.home.lan> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> <20110427054218.GA88420@DataIX.net> <864o5kgplh.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <864o5kgplh.fsf@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, "Jason J. Hellenthal" , dillon@backplane.com Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 10:17:20 -0000 On Wed, Apr 27, 2011 at 10:44:58AM +0400, Pan Tsu wrote: > "Jason J. Hellenthal" writes: > > > I do not know if this was summed up in a easy way by Jeremy's nice > > message below but in short a summary can be made here to clear that up. > > > > /dev/gptid/* /dev/gpt/* > > * These survive its raw partition being newfs'd > > * Are only created for disks that are partitioned > > and contain a GPT table as can be seen with gpart > > show > > * Operations on these or the raw partition will not remove them. > > Not sure if we have support for labels based on disk serial number > similar to /dev/serno/* from DragonFlyBSD but > > /dev/serno/* > * no extra step to setup, e.g. `gpart create' or `newfs' > * survive wiping entire disk, no metadata stored on-disk > * available on every ata disk How is this number generated within DFBSD? I have seen hard disks that have literally no serial number (field is blank, and not space-padded either). Some systems vendors do this. I'm wondering if the generated number is based on a combination of details (ex. device model string + serial number string + total drive capacity in bytes), rather than just pure drive serial number. CC'ing Matt as he probably knows. :-) -- | 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 Apr 27 11:13: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 9CB70106564A for ; Wed, 27 Apr 2011 11:13:50 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2607B8FC0C for ; Wed, 27 Apr 2011 11:13:49 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p3RAtOP5083770 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Apr 2011 13:55:29 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DB7F61C.8060003@digsys.bg> Date: Wed, 27 Apr 2011 13:55:24 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20110427101728.49C801065709@hub.freebsd.org> In-Reply-To: <20110427101728.49C801065709@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Why not just name the cam-ata devices the same as the old, names? 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, 27 Apr 2011 11:13:50 -0000 This labeling issue has intrigued me recently, as ZFS has become more mature on FreeBSD. With ZFS, although you may have the same pool names on disks, you will not import the wrong zpool (unless you boot off it somehow) if you happen to have two pool with the same name in the system. The zpool has it's UUID and the zpool name is just for user's convenience. I believe, we could invent/adopt something similar for UFS labels as well. Now, the easiest answer for this device renaming problem is: use UFS labels. Or disk labels, as Freddie suggested. Or GPT partition labels. Or use GUUIDs instead (GPT or UFS) if you are paranoid. Why would it be a problem that UFS labels are gone, when you newfs the filesystem? Our intention to use labels is to preserve mount points across reboots, possible on different hardware (HBA). You don't keep the contents of the filesystem when you newfs it, so you may well provide newfs with the appropriate -L label. Or use new label if you will use the filesystem for a different purpose/mountpoint. What should be done, ideally before the 9.0 release is to find some sane resolution method of what happens when you happen to have two (for example) 'root' UFS labels during boot/mount time. Daniel From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 14:08:52 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 B3FF11065677 for ; Wed, 27 Apr 2011 14:08:52 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 72FDF8FC17 for ; Wed, 27 Apr 2011 14:08:52 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 6771B19E02E; Wed, 27 Apr 2011 15:52:19 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9D4FC19E02D; Wed, 27 Apr 2011 15:52:17 +0200 (CEST) Message-ID: <4DB81F90.6020108@quip.cz> Date: Wed, 27 Apr 2011 15:52:16 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.18) Gecko/20110320 SeaMonkey/2.0.13 MIME-Version: 1.0 To: Daniel Kalchev References: <20110427101728.49C801065709@hub.freebsd.org> <4DB7F61C.8060003@digsys.bg> In-Reply-To: <4DB7F61C.8060003@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Why not just name the cam-ata devices the same as the old, names? 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, 27 Apr 2011 14:08:52 -0000 Daniel Kalchev wrote: [...] > What should be done, ideally before the 9.0 release is to find some sane > resolution method of what happens when you happen to have two (for > example) 'root' UFS labels during boot/mount time. ...and that's the problem with labels in case of gmirror. When you create gm0 of ada0 and ada1, then sometime in the future ada0 timedout and is dropped by gmirror, on next reboot you will have same partitions available on device /dev/ada0 and /dev/mirror/gm0 so there will be two devices promoting same labels! I don't know the order of tasting devices, but there is a chance that system will boot (mount root by label) from broken ada0 instead of gm0. That's why I am staying away from labels on gmirrored disk. (I am using labels on USB flash disks or USB external drives) Miroslav Lachman From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 16:36: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 D5A5D106566C for ; Wed, 27 Apr 2011 16:36:04 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [65.120.238.197]) by mx1.freebsd.org (Postfix) with ESMTP id BC6E88FC08 for ; Wed, 27 Apr 2011 16:36:04 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id p3RGO6jb064718; Wed, 27 Apr 2011 09:24:06 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id p3RGO5ms064717; Wed, 27 Apr 2011 09:24:05 -0700 (PDT) Date: Wed, 27 Apr 2011 09:24:05 -0700 (PDT) From: Matthew Dillon Message-Id: <201104271624.p3RGO5ms064717@apollo.backplane.com> To: Jeremy Chadwick References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> <20110427054218.GA88420@DataIX.net> <864o5kgplh.fsf@gmail.com> <20110427101718.GA82324@icarus.home.lan> Cc: freebsd-fs@freebsd.org, "Jason J. Hellenthal" , Pan Tsu Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 16:36:05 -0000 :> Not sure if we have support for labels based on disk serial number :> similar to /dev/serno/* from DragonFlyBSD but :> :> /dev/serno/* :> * no extra step to setup, e.g. `gpart create' or `newfs' :> * survive wiping entire disk, no metadata stored on-disk :> * available on every ata disk : :How is this number generated within DFBSD? I have seen hard disks that :have literally no serial number (field is blank, and not space-padded :either). Some systems vendors do this. I'm wondering if the generated :number is based on a combination of details (ex. device model string + :serial number string + total drive capacity in bytes), rather than just :pure drive serial number. : :CC'ing Matt as he probably knows. :-) : :-- :| Jeremy Chadwick jdc@parodius.com | Basically what DragonFly does is extract the serial number if the device reports one (and it isn't trivially blank) and makes the drives and partitions available via /dev/serno/[.s#[a-o]], in addition to their device attachment point at /dev/daXX, /dev/adXX, etc. If no serial number is available the devices will not show up in /dev/serno/ but will still show up at their device attachment point. We try to discourage the use of device attachment points when the serial number is available. That is, we encourage the use of serial number specifications in /etc/fstab and /etc/rc.conf whenever possible. The installer will install w/ such specifications. This way the hard drive can be connected via multiple avenues or even switched between the IDE (ata) driver and the AHCI driver, or hot-plugged via E-Sata, or a port-multiplier, and it just works. Plus, of course, with multiple device drivers the probe order is not necessarily going to be consistent either for DAxx assignment, and PHY issues / drive dropouts or probe failures would renumber everything anyway. Device attachment points are a non-starter if you have more than one hard drive. Once users get used to /dev/serno and/or LVM the issue of trying to represent a consistent set of device attach points for different drivers goes away. I strongly discourage any attempt to make device attach points consistent... it's a lost cause from the start. I even discourage the use of LVM for simple installations. LVM labels (roughly equivalent to GEOM labels in FreeBSD) are useful for more complex situations but logical labels in simple situations (which is to say, 99% of the installations out there) are unnecessarily complex relative to the use of the drive serial number. -- Any IDE, SATA, or SCSI attached disk will have a real serial number. I've never come across disks attached that way which do not. VMWare and QEmu will generate a dummy serial number based on the order the drives are configured. VirtualBox does not support serial numbers. I think (not 100% sure). USB-connected sticks and USB drives which run through USB/SATA bridges (which is all of them) usually do not support serial numbers. Those bridge chips are broken in many ways :-( iSCSI drives... I don't know, it usually depends more on the mid-layer software. They are supposed to. RAID/OTHER - I don't know. I'd like to say that they had better support proper serial numbers but I don't have enough data points. -Matt From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 18:55: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 81AA1106566B for ; Wed, 27 Apr 2011 18:55:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2038FC08 for ; Wed, 27 Apr 2011 18:55:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:4ee:2016:db72:ee7c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 18C6D4AC2D; Wed, 27 Apr 2011 22:55:16 +0400 (MSD) Date: Wed, 27 Apr 2011 22:55:11 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <669365808.20110427225511@serebryakov.spb.ru> To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4DB81F90.6020108@quip.cz> References: <20110427101728.49C801065709@hub.freebsd.org> <4DB7F61C.8060003@digsys.bg> <4DB81F90.6020108@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Why not just name the cam-ata devices the same as the old, names? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 18:55:18 -0000 Hello, Miroslav. You wrote 27 =E0=EF=F0=E5=EB=FF 2011 =E3., 17:52:16: >> What should be done, ideally before the 9.0 release is to find some sane >> resolution method of what happens when you happen to have two (for >> example) 'root' UFS labels during boot/mount time. > ...and that's the problem with labels in case of gmirror. > When you create gm0 of ada0 and ada1, then sometime in the future ada0 > timedout and is dropped by gmirror, on next reboot you will have same=20 > partitions available on device /dev/ada0 and /dev/mirror/gm0 so there=20 > will be two devices promoting same labels! I don't know the order of=20 > tasting devices, but there is a chance that system will boot (mount root > by label) from broken ada0 instead of gm0. Even without broken mirror, in case of perfectly valid reboot, glabel could pick-up label first (before gmirror) from one of (both are non-broken) mirror components, and after that gmirror builds itself from one true component (ada0, for example) and one label-provided (instead of ada1) :( So, UFS labels CAN NOT BE MIXED with gmirror... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 20:10:53 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 104F21065670 for ; Wed, 27 Apr 2011 20:10:53 +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 CC6958FC0C for ; Wed, 27 Apr 2011 20:10:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip01.eastlink.ca ([unknown] [24.222.39.10]) by mta04.eastlink.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) with ESMTP id <0LKB00AMYUQ3A1S0@mta04.eastlink.ca> for freebsd-fs@freebsd.org; Wed, 27 Apr 2011 17:10:51 -0300 (ADT) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=mORQtGzMSGJSBwuMSvVfB0MKjPGmXehAuj88Uvu04o4= c=1 sm=1 a=e8U4T-BRE4EA:10 a=IkcTkHD0fZMA:10 a=QYf_FK3ziJuEyJ82DQgA:9 a=QEXdDO2ut3YA:10 a=E/PVjAe7IbPkHCM0BPV0xg==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip01.eastlink.ca with ESMTP; Wed, 27 Apr 2011 17:10:51 -0300 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Wed, 27 Apr 2011 17:10:49 -0300 From: Chris Forgeron To: Rick Macklem Date: Wed, 27 Apr 2011 17:10:46 -0300 Thread-topic: make the experimental NFS subsystem the default one Thread-index: AcwAKbxaQ/MyU6P1QY+So9wY48H1MgE7GykQ Message-id: References: <1143723691.393441.1303384281461.JavaMail.root@erie.cs.uoguelph.ca> In-reply-to: <1143723691.393441.1303384281461.JavaMail.root@erie.cs.uoguelph.ca> Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Cc: "freebsd-fs@freebsd.org" Subject: RE: make the experimental NFS subsystem the default one 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, 27 Apr 2011 20:10:53 -0000 Yes, as I noted in my message, you can't enable async client side - It's inside of ESX, and you don't have an option to modify. And yes, it would also mean that you could really screw things up, but even if you have to make it a hidden option, I know it would be invaluable to the ESX crowd. When you're running on a ZFS storage base, having sync writes in NFS doesn't add any security, as ZFS is handling all of that for us, and often with far more performance/reliability. I think it would give a nice advantage to a FreeBSD ZFS/NFS solution. It definitely makes a speed difference, even with a properly configured ZIL. Would it be enough to have a big warning on the man page for the switch that it breaks RFC compliance, to log that warning when it happens, and to generally warn of dire consequences to anyone who doesn't understand what they are doing? Otherwise I just have to hack up the source and release a patch to those who want the feature, which seems counterproductive. I'd be very appreciative of the switch, and can offer you some heavy testing of it and your NFS code and report back to help with your code adoption. -----Original Message----- From: Rick Macklem [mailto:rmacklem@uoguelph.ca] Sent: Thursday, April 21, 2011 8:11 AM Have you tries the "async" mount option on the client side? (or did you say you couldn't do that above?) I would be very hesitant to do it on the server side, since it would violate the RFC (and you do run a risk of losing data, which many might not realize uptil it is too late). rick From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 21:25:26 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 4CE871065675 for ; Wed, 27 Apr 2011 21:25:26 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id D0AD88FC19 for ; Wed, 27 Apr 2011 21:25:25 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p3RLPNv4031127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2011 07:25:23 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p3RLPMWs099526; Thu, 28 Apr 2011 07:25:22 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p3RLPMYE099525; Thu, 28 Apr 2011 07:25:22 +1000 (EST) (envelope-from peter) Date: Thu, 28 Apr 2011 07:25:21 +1000 From: Peter Jeremy To: Freddie Cash Message-ID: <20110427212521.GA99261@server.vk2pj.dyndns.org> References: <4DB70949.6090104@FreeBSD.org> <20110426182017.GA92471@freebsd.org> <4DB70F13.6060002@FreeBSD.org> <4DB759A1.4050201@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Why not just name the cam-ata devices the same as the old names? 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, 27 Apr 2011 21:25:26 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Apr-26 22:46:20 -0700, Freddie Cash wrote: >This is where labelling *disks* is the better route. Filesystems come >and go, but the disks don't change very often. This is one the nicest >things about using FreeBSD systems (all the GEOM stacking and >labelling). But disks _do_ get changed for various reasons (eg failure). If we move to a an identification approach that is based on the physical disk, rather than some variant on the path to a disk, we need to ensure that the disk replacement procedure is well documented. One associated issue is determining what disk you are booting from - my main system has 6 disks spread across 3 controllers. Whilst the BIOS reports size and model, it doesn't report serial number (and the mapping of SATA port to legacy PATA channel/master-slave is non-obvious and as tripped me up in the past). By the time I get to loader(8), I'm just presented with 'C' through 'H' (mapped to disk0 thru disk5). There is no way to map this to either physical disk (though this is probably the fault of my BIOS) or to FreeBSD device names. loader needs to grow enough smarts to be able to report a disk serial number (where possible) and there nees to be a tool that can map between loader and FreeBSD disk names (though it's not clear whether this belongs in loader(8), the kernel, userland or some combination). As for the ad->ada renaming: I went through this some time ago (by manually switching my kernel from ata to ahci), resulting in ad{4,6,8} becoming ada{0,1,2}. Whilst I was aware of the issue, I still managed to confuse myself and I think it took me at least one reboot to get the names straight. (Thought ZFS took the renaming of the devices underlying my data pool in its stride). --=20 Peter Jeremy --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk24icEACgkQ/opHv/APuIcvqgCcCe7p4SWQf7CVdec8PodQPFSb fbMAoLMKBFtIt//aFxc2XlRuKCLEPtcx =kao1 -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 23:58: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 7932A106566B for ; Wed, 27 Apr 2011 23:58:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 354418FC17 for ; Wed, 27 Apr 2011 23:58:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAICsuE2DaFvO/2dsb2JhbACEU6IjiHCqSZEhgSmDUH0EjlGOSA X-IronPort-AV: E=Sophos;i="4.64,277,1301889600"; d="scan'208";a="119722246" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 27 Apr 2011 19:58:14 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 93632B3F33; Wed, 27 Apr 2011 19:58:14 -0400 (EDT) Date: Wed, 27 Apr 2011 19:58:14 -0400 (EDT) From: Rick Macklem To: Chris Forgeron Message-ID: <640208384.682241.1303948694525.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: make the experimental NFS subsystem the default one 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, 27 Apr 2011 23:58:15 -0000 > Yes, as I noted in my message, you can't enable async client side - > It's inside of ESX, and you don't have an option to modify. > > And yes, it would also mean that you could really screw things up, but > even if you have to make it a hidden option, I know it would be > invaluable to the ESX crowd. When you're running on a ZFS storage > base, having sync writes in NFS doesn't add any security, as ZFS is > handling all of that for us, and often with far more > performance/reliability. > I'm not sure what you are saying here. Are you assuming that ZFS won't lose data when the server crashes, even if it isn't getting the VOP_SYNC() for the file when the client assumes it is saved to stable storage (disk or SSD or ...)? (You say "security", but it sounds like you are referring to data reliability along the lines of "won't lose any file data if it crashes/reboots.) I don't know anything about ZFS, but I would think that, if you see a major performance improvement, that ZFS isn't committing stuff to logs so that data won't be lost. Maybe the ZFS folks can comment? (I don't remember seeing the details of what you change? If you sent a patch, sorry, but I've misplaced it.) > I think it would give a nice advantage to a FreeBSD ZFS/NFS solution. > It definitely makes a speed difference, even with a properly > configured ZIL. > > Would it be enough to have a big warning on the man page for the > switch that it breaks RFC compliance, to log that warning when it > happens, and to generally warn of dire consequences to anyone who > doesn't understand what they are doing? > Well, my concern is that the sysadmins won't realize that they can lose file data if the server crashes/reboots with this enabled. Which is what I believe your changes would do, if I understood it correctly? If the client is specifying the FILE_SYNC on each write, it is saying that it expects the data and metadata for the file being written to be saved to stable storage (so that it won't be lost due to a crash/reboot) before the server replies to that write rpc. (If you choose not to do that, file corruption etc can happen. Some environments wouldn't care, but the sysadmins need to know what they are doing w.r.t. this.) The NFS spec. writers chose not to make this optional (RFC1813 says "must" for this) and I suspect it was because they understood that sysadmins wouldn't be ready for the consequences. I think it's up to the "collective" whether or not something like this goes in the code, but I personally thing it's a risky idea. rick From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 04:52:13 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 116AB106566B for ; Thu, 28 Apr 2011 04:52:13 +0000 (UTC) (envelope-from quazi@bk.ru) Received: from fallback8.mail.ru (fallback8.mail.ru [94.100.176.136]) by mx1.freebsd.org (Postfix) with ESMTP id BD6178FC14 for ; Thu, 28 Apr 2011 04:52:12 +0000 (UTC) Received: from smtp1.mail.ru (smtp1.mail.ru [94.100.176.129]) by fallback8.mail.ru (mPOP.Fallback_MX) with ESMTP id 6771116739B for ; Thu, 28 Apr 2011 08:36:56 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=4JvS7HaG9VdyQej1GrPZouYu1ASqvxzu4SWPdYVIJ7U=; b=O/mrdrDuU04Nn9nIsnebCJgx5krZShnlIwVItpqoGXZwrNOUXGqeZvdd3GSfKhsxNi4P3RSoiqtj3IOOVo4c6DS2qiXVVH4mbR+bvXuD1xtutxuxHA9Fn/r24jPxUv5f; Received: from [178.126.70.130] (port=55978 helo=QUAZIS.SNNLAN.local) by smtp1.mail.ru with asmtp id 1QFIyE-0005Hq-00 for freebsd-fs@freebsd.org; Thu, 28 Apr 2011 08:36:54 +0400 Message-ID: <4DB8EF02.8060406@bk.ru> Date: Thu, 28 Apr 2011 07:37:22 +0300 From: Ruslan Yakovlev User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110118 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: ZFS v28 for 8.2-STABLE 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, 28 Apr 2011 04:52:13 -0000 Does actually patch exist for 8.2-STABLE ? I probe http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz Building failed with: can't cd to /usr/src/cddl/usr.bin/zstreamdump Also sys/cddl/compat/opensolaris/sys/sysmacros.h failed to patch. Current FreeBSD 8.2-STABLE #35 Mon Apr 18 03:40:38 EEST 2011 i386 periodically frozen on high load like backup by rsync or find -sx ... (from default cron tasks). From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 05:01:17 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 340A9106564A for ; Thu, 28 Apr 2011 05:01:17 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id E9B9F8FC17 for ; Thu, 28 Apr 2011 05:01:16 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFJLn-000BQ4-Gb for freebsd-fs@freebsd.org; Thu, 28 Apr 2011 07:01:15 +0200 Date: Thu, 28 Apr 2011 07:03:00 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1079311802.20110428070300@nitronet.pl> To: Ruslan Yakovlev In-Reply-To: <4DB8EF02.8060406@bk.ru> References: <4DB8EF02.8060406@bk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-fs@freebsd.org Subject: Re: ZFS v28 for 8.2-STABLE 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, 28 Apr 2011 05:01:17 -0000 Hi Ruslan, > Does actually patch exist for 8.2-STABLE ? > I probe > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz > Building failed with: > can't cd to /usr/src/cddl/usr.bin/zstreamdump > Also sys/cddl/compat/opensolaris/sys/sysmacros.h failed to patch. > Current FreeBSD 8.2-STABLE #35 Mon Apr 18 03:40:38 EEST 2011 i386 > periodically frozen on high load like backup by rsync or find -sx ... > (from default cron tasks). sys/cddl/compat/opensolaris/sys/sysmacros.h is supposed to be deleted, so you can ignore the fail and delete the file manually. I was rebuilding my system two weeks ago and same patch applied correctly on amd64, and everything works fine. You could try wiping /usr/src (keeping kernel config somewhere safe), csuping it again, and deleting /usr/obj before building. BTW. Why people still cling to i386? From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 05:19:17 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 42FD7106564A for ; Thu, 28 Apr 2011 05:19:17 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A261C8FC12 for ; Thu, 28 Apr 2011 05:19:16 +0000 (UTC) Received: by pvg11 with SMTP id 11so2136618pvg.13 for ; Wed, 27 Apr 2011 22:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=5h+Hn3TiulWMRm2D547M//NslGLDLOGV2m0LJ+386bg=; b=xHH4VgqOaN8aJp/4mo97bLA+0Zxnx/FJ5tfthZ4vm6+rilPJosGfT9IKDYpGX4a62A wTfs5AHS5lpmvNQznKbODT3R804YrqWMzfAnQxWF5mmzWnu6fSu72pCTkJXxiMt2BX5I +tgB4Yrw/TpMmQugkwALA1EMmlDvVXTQF5ntQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PDkb68t31NZvDQmlg/+b3yaWIO7wcxXxS7uqrQQj53lFyfkyfrm4GffhpSmAsUjLLF Bib3RanbUEJPc/lX62KSYeQ3v0Tqt6I/g1KQaC0sOHjhSU94qK6WMcRES9EWgTWPqXUJ AJmlB3aRujIz5Q6gAL3o2/JAZSomCkzg3Ci6s= MIME-Version: 1.0 Received: by 10.142.218.15 with SMTP id q15mr995020wfg.311.1303966165285; Wed, 27 Apr 2011 21:49:25 -0700 (PDT) Received: by 10.142.177.20 with HTTP; Wed, 27 Apr 2011 21:49:25 -0700 (PDT) Date: Thu, 28 Apr 2011 00:49:25 -0400 Message-ID: From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Softupdates and umount, bug, fixed? 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, 28 Apr 2011 05:19:17 -0000 At one point in the not too distant past you could... - newfs -U and mount two disks - fill one fs with a reasonable hierarchy of a million inodes - rsync that over to the second fs - wait till df -i had the same inode count - blow away some number of inodes from the first, say 5000 - immediately after the rm ; umount the second fs That would leave you with a difference in df -i count. And a filesystem that needed fsck -fy umount didn't seem wait for, or sync, the fs. Has this been fixed yet? From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 09:40: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 A7DC1106564A for ; Thu, 28 Apr 2011 09:40:14 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5DBAA8FC0A for ; Thu, 28 Apr 2011 09:40:14 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155804.dip.t-dialin.net [91.21.88.4]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1229084400D for ; Thu, 28 Apr 2011 11:40:00 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 1D302116E for ; Thu, 28 Apr 2011 11:39:57 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p3S9du6m038343 for freebsd-fs@FreeBSD.org; Thu, 28 Apr 2011 11:39:56 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 28 Apr 2011 11:39:56 +0200 Message-ID: <20110428113956.26165fniv7wsvu4o@webmail.leidinger.net> Date: Thu, 28 Apr 2011 11:39:56 +0200 From: Alexander Leidinger To: freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1229084400D.A1B2B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0, required 6, autolearn=disabled) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1304588400.95371@QLoMG8oreBOm7z6mfmbedw X-EBL-Spam-Status: No Cc: Subject: GPT & dump-partition 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, 28 Apr 2011 09:40:14 -0000 Hi, I want to give GPT a try and I have a question so far. Which type do I configure for a kernel-dump partition, freebsd-swap, freebsd, or something else? Bye, Alexander. -- Matrimony is the root of all evil. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 10:30:46 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 9C597106564A for ; Thu, 28 Apr 2011 10:30:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 506C88FC15 for ; Thu, 28 Apr 2011 10:30:45 +0000 (UTC) Received: by qwc9 with SMTP id 9so1499225qwc.13 for ; Thu, 28 Apr 2011 03:30:45 -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:cc:content-type; bh=EVCm/EHtTzH6+5hJZUE16gTXb+wSKAlAFMebKc85Jgc=; b=hagcytWKniUZG0/FAps6fGHdFIsdIs6vYZrJlTGUdre1xNkHOVrM8LH6FY4EHJ6EvV 655EffFp4Yh5W3hwZkOwLF3L8PFNoXkgyt6Zu24dQtuYHw5Tyec+Vob/H22mn/4fuS74 V+7+Ym8SrlNh+vxGGH7GPM+0GUWcXuYwl3Jkw= 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 :cc:content-type; b=FKavyYtF6BZrFWiJ3vVOivc2ZfhDBvGQ1qLQN8OG9+m+wusgeHk9+ZHO5eRjjMx1hA XkTVu/cdJAGtTkH93sBU+tHZNgZZkn5elbpqx7dDAzAL8G3uXugOyUATLOVyB50ZVJLk kuTJ3RHU8nErjUnK1JeV0ZA07ODxyn7y7DU2E= MIME-Version: 1.0 Received: by 10.229.221.140 with SMTP id ic12mr2554326qcb.176.1303984807716; Thu, 28 Apr 2011 03:00:07 -0700 (PDT) Received: by 10.229.97.146 with HTTP; Thu, 28 Apr 2011 03:00:07 -0700 (PDT) In-Reply-To: <20110428113956.26165fniv7wsvu4o@webmail.leidinger.net> References: <20110428113956.26165fniv7wsvu4o@webmail.leidinger.net> Date: Thu, 28 Apr 2011 14:00:07 +0400 Message-ID: From: Sergey Kandaurov To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: GPT & dump-partition 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, 28 Apr 2011 10:30:46 -0000 On 28 April 2011 13:39, Alexander Leidinger wrote: > Hi, > > I want to give GPT a try and I have a question so far. > > Which type do I configure for a kernel-dump partition, freebsd-swap, > freebsd, or something else? > Hi. I use freebsd-swap for this purpose. # gpart show => 34 488397101 ada0 GPT (232G) 34 128 1 freebsd-boot (64k) 162 419430400 2 freebsd-ufs (200G) 419430562 8388608 3 freebsd-swap (4.0G) 427819170 60577965 - free - (28G) -- wbr, pluknet From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 12:18:21 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 3ECA3106566B for ; Thu, 28 Apr 2011 12:18:21 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B79418FC17 for ; Thu, 28 Apr 2011 12:18:20 +0000 (UTC) Received: by wwc33 with SMTP id 33so2753488wwc.31 for ; Thu, 28 Apr 2011 05:18:19 -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:cc:content-type; bh=bvYqDW17nM/8Oqd6FQ7Q6dszhK5SEPjeE0b1Rw1jTv8=; b=Pn+S+6p7xE6yeQslVG5pMIjOPKfU2cKciL8Nqvmh9/6EX9hv67VVVYseafZ7lq6DEb SA2F1/W289yETCHYTYjs3KMuSfIuYKxaoIIbVs6Z0WRSOt2x/throwtXow383vZGKZhx IIM1SKLGYQG/gxXmcOfRwpI7/pq4Kfg7e/vS0= 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 :cc:content-type; b=tWEiTU19ZHwNg2UIikSnsBRv754Y3MUjaBN3irBAoZzvlC+0gle27IkoHpi5+b9sUn MULag0HJQvOutN3R7zExuPPnZvUhbS6J0PACt/9xDmVb1wsAHIpReTXdLFG1G0o6l/vt NP51T44I7+g5x6Eolt6NOTjGQzUBXrUuoYCu4= MIME-Version: 1.0 Received: by 10.216.16.32 with SMTP id g32mr7125576weg.0.1303993099478; Thu, 28 Apr 2011 05:18:19 -0700 (PDT) Received: by 10.216.15.73 with HTTP; Thu, 28 Apr 2011 05:18:19 -0700 (PDT) In-Reply-To: <1079311802.20110428070300@nitronet.pl> References: <4DB8EF02.8060406@bk.ru> <1079311802.20110428070300@nitronet.pl> Date: Thu, 28 Apr 2011 13:18:19 +0100 Message-ID: From: krad To: Pawel Tyll Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS v28 for 8.2-STABLE 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, 28 Apr 2011 12:18:21 -0000 On 28 April 2011 06:03, Pawel Tyll wrote: > Hi Ruslan, > > > Does actually patch exist for 8.2-STABLE ? > > I probe > > > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz > > Building failed with: > > can't cd to /usr/src/cddl/usr.bin/zstreamdump > > Also sys/cddl/compat/opensolaris/sys/sysmacros.h failed to patch. > > > Current FreeBSD 8.2-STABLE #35 Mon Apr 18 03:40:38 EEST 2011 i386 > > periodically frozen on high load like backup by rsync or find -sx ... > > (from default cron tasks). > sys/cddl/compat/opensolaris/sys/sysmacros.h is supposed to be deleted, > so you can ignore the fail and delete the file manually. > > I was rebuilding my system two weeks ago and same patch applied > correctly on amd64, and everything works fine. You could try wiping > /usr/src (keeping kernel config somewhere safe), csuping it again, and > deleting /usr/obj before building. > > BTW. Why people still cling to i386? > > > _______________________________________________ > 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" > also there is no such thing as 8.2-STABLE, there is 8-STABLE, and 8.2-RELEASE, and 8.2-RELEASE with security patches aka RELENG_8_2_0 From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 12:49:41 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 8E6F41065673 for ; Thu, 28 Apr 2011 12:49:41 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 348938FC1C for ; Thu, 28 Apr 2011 12:49:40 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 7AC641D07; Thu, 28 Apr 2011 14:32:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1303993951; x= 1305808351; bh=DtTXd+XjW/h552Yqglc+hZdwgDj/BqIyhZxt7Xn8fp8=; b=T zQw7sojZXJwFaHOUHBkpMXu7/g2PdQYrrrF1xUpKY/1hwbM1DhGMJLF97UMJ+6WQ exBhwjkv3S/CJ1afrL7XfnKzOOCHVi1l5MFy/nS4Bt6rh9zFn+pH57q7oOFmTq3I wKTQBV9Db+onNov6ITB8wsxJ8Q+chHIiNkTqRZFPQs= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kl1Y0+9iaDzm; Thu, 28 Apr 2011 14:32:31 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 315951CFA; Thu, 28 Apr 2011 14:32:31 +0200 (CEST) Date: Thu, 28 Apr 2011 14:32:31 +0200 From: Guido Falsi To: Pawel Tyll Message-ID: <20110428123230.GA43084@megatron.madpilot.net> References: <4DB8EF02.8060406@bk.ru> <1079311802.20110428070300@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079311802.20110428070300@nitronet.pl> X-Operating-System: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS v28 for 8.2-STABLE 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, 28 Apr 2011 12:49:41 -0000 On Thu, Apr 28, 2011 at 07:03:00AM +0200, Pawel Tyll wrote: > > BTW. Why people still cling to i386? Unluckily there are some binary things which work only in i386. A friend of mine need a VM to run ports/databases/oracle8-client. Another thing which I think could force people n i386 is adobe software(this is true in linux too). There may be other examples around. P.S. I run on amd64 only whenever possible, and except for some old i386 only PC, I use amd64 exclusively and try to find alternatives whenever possible, but this is me. -- Guido Falsi From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 13:46: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 718E510656B2 for ; Thu, 28 Apr 2011 13:46:15 +0000 (UTC) (envelope-from quazi@bk.ru) Received: from f78.mail.ru (f78.mail.ru [217.69.128.226]) by mx1.freebsd.org (Postfix) with ESMTP id F05598FC1B for ; Thu, 28 Apr 2011 13:46:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:To:From; bh=ifey0rrU+nsYsyyv4RnTGypPTDOV6SoNi6ShpdPO/Z4=; b=IVJLEnGtoioLEskyqemmZKtuxAqWXu/ogFFBhSNarFbq3bIjsn3b1o81yzxPmziCil/t4aeDcrQfpabkFXo0KLqnJhoDBI6XYaFXVAKlDKmDz/NdGVSIPBloHV0Ko2Cn; Received: from mail by f78.mail.ru with local id 1QFRXo-00035S-00 for freebsd-fs@freebsd.org; Thu, 28 Apr 2011 17:46:12 +0400 Received: from [46.191.15.7] by e.mail.ru with HTTP; Thu, 28 Apr 2011 17:46:12 +0400 From: Ruslan QuAzI To: freebsd-fs Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 172.23.184.240 via proxy [46.191.15.7] Date: Thu, 28 Apr 2011 17:46:12 +0400 References: <4DB8EF02.8060406@bk.ru> <1079311802.20110428070300@nitronet.pl> In-Reply-To: <1079311802.20110428070300@nitronet.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok Subject: Re[2]: ZFS v28 for 8.2-STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ruslan QuAzI List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:46:15 -0000 SSByZW1vdmUgYWxsIHNvdXJjZXMgYW5kIGNzdXAgaXQgYWdhaW4uCktlcm5lbCBtYWtlZCwgYnV0 IHdvcmxkIGJyb2tlbiBhZ2FpbgoKPT09PiBjZGRsL3Vzci5iaW4vc2dzbXNnIChjbGVhbmRpcikK cm0gLWYgc2dzbXNnIGF2bC5vIHNnc21zZy5vIHN0cmluZ190YWJsZS5vIGZpbmRwcmltZS5vCnJt IC1mIC5kZXBlbmQgR1BBVEggR1JUQUdTIEdTWU1TIEdUQUdTCj09PT4gY2RkbC91c3IuYmluL3pp bmplY3QgKGNsZWFuZGlyKQpybSAtZiB6aW5qZWN0IHppbmplY3QubyB0cmFuc2xhdGUubwpybSAt ZiAuZGVwZW5kIEdQQVRIIEdSVEFHUyBHU1lNUyBHVEFHUwo9PT0+IGNkZGwvdXNyLmJpbi96c3Ry ZWFtZHVtcCAoY2xlYW5kaXIpCmNkOiBjYW4ndCBjZCB0byAvdXNyL3NyYy9jZGRsL3Vzci5iaW4v enN0cmVhbWR1bXAKKioqIEVycm9yIGNvZGUgMgoKU3RvcCBpbiAvdXNyL3NyYy9jZGRsL3Vzci5i aW4uCioqKiBFcnJvciBjb2RlIDEKClN0b3AgaW4gL3Vzci9zcmMvY2RkbC4KKioqIEVycm9yIGNv ZGUgMQoKU3RvcCBpbiAvdXNyL3NyYy4KKioqIEVycm9yIGNvZGUgMQoKU3RvcCBpbiAvdXNyL3Ny Yy4KKioqIEVycm9yIGNvZGUgMQoKU3RvcCBpbiAvdXNyL3NyYy4KCkkgd2lsbCB0cnkgdG8gcHJv YmUgcGF0Y2ggZm9yIDguMi1SRUxFTkc= From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 13:56: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 DED591065670 for ; Thu, 28 Apr 2011 13:56:58 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 91EEA8FC12 for ; Thu, 28 Apr 2011 13:56:58 +0000 (UTC) Received: from rron-2.local (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 074FECD92 for ; Thu, 28 Apr 2011 15:56:55 +0200 (CEST) Date: Thu, 28 Apr 2011 15:56:54 +0200 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20110428135654.GF64725@rron-2.local> References: <4DB8EF02.8060406@bk.ru> <1079311802.20110428070300@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Thu, 28 Apr 2011 15:56:56 +0200 (CEST) Subject: Re: ZFS v28 for 8.2-STABLE 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, 28 Apr 2011 13:56:58 -0000 According to Ruslan QuAzI: > I will try to probe patch for 8.2-RELENG I'm surprised, I just upgraded my main machine to r221058, applied the 20110317 patch from mm and apart from the sysmacros.h that you need to remove manually, it patched, compiled and ran ok. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 13:59:47 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 121D5106566B for ; Thu, 28 Apr 2011 13:59:47 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id BB7648FC20 for ; Thu, 28 Apr 2011 13:59:46 +0000 (UTC) Received: from rron-2.local (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id E26D6CD95 for ; Thu, 28 Apr 2011 15:59:45 +0200 (CEST) Date: Thu, 28 Apr 2011 15:59:44 +0200 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20110428135943.GG64725@rron-2.local> References: <20110428113956.26165fniv7wsvu4o@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110428113956.26165fniv7wsvu4o@webmail.leidinger.net> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Thu, 28 Apr 2011 15:59:46 +0200 (CEST) Subject: Re: GPT & dump-partition 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, 28 Apr 2011 13:59:47 -0000 According to Alexander Leidinger: > I want to give GPT a try and I have a question so far. > > Which type do I configure for a kernel-dump partition, freebsd-swap, > freebsd, or something else? See gpart(8) for the list of recognized partition types. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 16:01:53 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 83D56106566C; Thu, 28 Apr 2011 16:01: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 EA1958FC25; Thu, 28 Apr 2011 16:01:52 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p3SG1mn0067624; Thu, 28 Apr 2011 19:01:48 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4DB98F5D.2090108@ukr.net> Date: Thu, 28 Apr 2011 19:01:33 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: FreeBSD Mailing List , fs@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.97 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Cc: Subject: ZFS-Only FreeBSD and crashdump 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, 28 Apr 2011 16:01:53 -0000 I have the ZFS-Only FreeBSD 8.2. # gpart show => 34 321672893 ad4 GPT (153G) 34 128 1 freebsd-boot (64K) 162 33554432 2 freebsd-swap (16G) 33554594 288118333 3 freebsd-zfs (137G) How to obtain crash dump, so he kept on zfs? Is it enough for it to correct /etc/rc.d/zfs, adding: "# BEFORE: dumpon" ? -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 16:50: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 45533106564A for ; Thu, 28 Apr 2011 16:50:54 +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 8C4618FC14 for ; Thu, 28 Apr 2011 16:50:53 +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 TAA05690; Thu, 28 Apr 2011 19:40:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DB99860.3070701@FreeBSD.org> Date: Thu, 28 Apr 2011 19:40:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Vladislav V. Prodan" References: <4DB98F5D.2090108__2814.45118967003$1304006598$gmane$org@ukr.net> In-Reply-To: <4DB98F5D.2090108__2814.45118967003$1304006598$gmane$org@ukr.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Mailing List , fs@FreeBSD.org Subject: Re: ZFS-Only FreeBSD and crashdump 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, 28 Apr 2011 16:50:54 -0000 on 28/04/2011 19:01 Vladislav V. Prodan said the following: > I have the ZFS-Only FreeBSD 8.2. > # gpart show > => 34 321672893 ad4 GPT (153G) > 34 128 1 freebsd-boot (64K) > 162 33554432 2 freebsd-swap (16G) > 33554594 288118333 3 freebsd-zfs (137G) > > How to obtain crash dump, so he kept on zfs? > Is it enough for it to correct /etc/rc.d/zfs, adding: > "# BEFORE: dumpon" ? At the moment FreeBSD doesn't support dumping to ZFS zvols, if that's what you are asking. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 19:14: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 B83FF106566B; Thu, 28 Apr 2011 19:14: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 25BF48FC0A; Thu, 28 Apr 2011 19:14:29 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p3SJENLC083780; Thu, 28 Apr 2011 22:14:23 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4DB9BC80.9010401@ukr.net> Date: Thu, 28 Apr 2011 22:14:08 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <4DB98F5D.2090108__2814.45118967003$1304006598$gmane$org@ukr.net> <4DB99860.3070701@FreeBSD.org> In-Reply-To: <4DB99860.3070701@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.97 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Cc: fs@freebsd.org Subject: Re: ZFS-Only FreeBSD and crashdump 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, 28 Apr 2011 19:14:30 -0000 28.04.2011 19:40, Andriy Gapon wrote: > At the moment FreeBSD doesn't support dumping to ZFS zvols, if that's what you are > asking. And when do planning to add support? :) Option to use to dump the usb-flash has its limitations, both on disk size and write speed? -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 19:46:46 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 12FA5106566C for ; Thu, 28 Apr 2011 19:46:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C31978FC1A for ; Thu, 28 Apr 2011 19:46:45 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155804.dip.t-dialin.net [91.21.88.4]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 671A4844016; Thu, 28 Apr 2011 21:46:30 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 828161171; Thu, 28 Apr 2011 21:46:27 +0200 (CEST) Date: Thu, 28 Apr 2011 21:46:25 +0200 From: Alexander Leidinger To: Ollivier Robert Message-ID: <20110428214625.00001851@unknown> In-Reply-To: <20110428135943.GG64725@rron-2.local> References: <20110428113956.26165fniv7wsvu4o@webmail.leidinger.net> <20110428135943.GG64725@rron-2.local> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 671A4844016.AD570 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1304624792.70798@v01SOeH/4e3b32ZX7ajPZQ X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: GPT & dump-partition 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, 28 Apr 2011 19:46:46 -0000 On Thu, 28 Apr 2011 15:59:44 +0200 Ollivier Robert wrote: > According to Alexander Leidinger: > > I want to give GPT a try and I have a question so far. > > > > Which type do I configure for a kernel-dump partition, freebsd-swap, > > freebsd, or something else? > > See gpart(8) for the list of recognized partition types. The list I presented above was based upon reading gpart(8). There is one mention of the word "dump", and it is for the backup command of gpart (so not related). There is no mention of "core" or "save" or "crash". My guess would have been freebsd-swap, and in another mail I got informed that this is what is used by other people. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 19:50:49 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 ACBB51065670 for ; Thu, 28 Apr 2011 19:50:49 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 32BF48FC0C for ; Thu, 28 Apr 2011 19:50:48 +0000 (UTC) Received: by fxm11 with SMTP id 11so2967488fxm.13 for ; Thu, 28 Apr 2011 12:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:x-authentication-warning:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=r7ZCfCqHuesG6+M+kr033FPXUwYbytGCQ50Hi37qctc=; b=UgLsmgntconLrC5jk8AUdVmjMYYkaIbvmV219jbymjWq4RG0T0UZuK0JSKYXp2Cfte sL5IWOyHp6r0Ji2LgqF9INi6WvaIT4ZLGrsJdvOPinA90gjBiojazJMJuMO8eYSGwf+R Mmwx4uqR/kzV7rreI0bQQM2qBZtFaV9znV6P8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=qf+MeGhLO9KAxbzQ+106HGpevIVdeLKzYbHRTdQ1u7/xZ/cTab+HyTlVu9rkBui5RJ dO/UGzW4/2ZjWAY2lGqK96kqff7Vvua2cY4b2ovsKCQLtx6nWylvqtggMxN8sK/Jv5w3 8KFtQMpuO0fMiX4CbSnfrd+0p2S6HKaFxPtlE= Received: by 10.223.6.11 with SMTP id 11mr525701fax.101.1304018724212; Thu, 28 Apr 2011 12:25:24 -0700 (PDT) Received: from procyon.xvoid.org ([213.132.76.142]) by mx.google.com with ESMTPS id n26sm677205fam.13.2011.04.28.12.25.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 12:25:23 -0700 (PDT) Received: from procyon.xvoid.org (yuri@localhost [IPv6:::1]) by procyon.xvoid.org (8.14.4/8.14.4) with ESMTP id p3SJPKx6015902; Thu, 28 Apr 2011 23:25:20 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by procyon.xvoid.org (8.14.4/8.14.4/Submit) id p3SJPKR5015901; Thu, 28 Apr 2011 23:25:20 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: procyon.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Thu, 28 Apr 2011 23:25:20 +0400 From: Yuri Pankov To: "Vladislav V. Prodan" Message-ID: <20110428192520.GA15893@procyon.xvoid.org> References: <4DB98F5D.2090108__2814.45118967003$1304006598$gmane$org@ukr.net> <4DB99860.3070701@FreeBSD.org> <4DB9BC80.9010401@ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DB9BC80.9010401@ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-questions@freebsd.org, fs@freebsd.org Subject: Re: ZFS-Only FreeBSD and crashdump 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, 28 Apr 2011 19:50:49 -0000 On Thu, Apr 28, 2011 at 10:14:08PM +0300, Vladislav V. Prodan wrote: > 28.04.2011 19:40, Andriy Gapon wrote: > > At the moment FreeBSD doesn't support dumping to ZFS zvols, if that's what you are > > asking. > > And when do planning to add support? :) > Option to use to dump the usb-flash has its limitations, both on disk > size and write speed? Why not just use your swap partition as dumpdev? Yuri From owner-freebsd-fs@FreeBSD.ORG Fri Apr 29 06:57:13 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 F111F106566C for ; Fri, 29 Apr 2011 06:57:12 +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 A4CF98FC08 for ; Fri, 29 Apr 2011 06:57:12 +0000 (UTC) Received: by iwn33 with SMTP id 33so3971280iwn.13 for ; Thu, 28 Apr 2011 23:57:12 -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 :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=SyYFeDh5qvUMZb3Lnf6CYsef6tpeT9DcvesotldanGs=; b=eEvH4M1wPXwaPPXn2gxTNY1PLrzufQ3Vbkm8TIhGySqr453V0RC4YAoBzCnoOpRHpi vzyGtkKDG8LdexoIFzl/QDBQYgeMytN+YTHDyTD1NSl8n3OapVWYyeDZwNMpbzDb2FvE dkbOKi+bOmv7x5xUG27Zm04E3yOHufomX6mo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=R2f8fq493peGtsJOkt4QIRxWVia9Dgg8f0hoWD/LncpLYSzTpUOZRCD7A5pxWC2QOi 8kHGL6sycSUqC7WrhNk61jrSI1gQT+0b+4oLIrQ14tiuL5C27Lk3x7BMMpU/6XP+Hwr8 aDS0bvE/Ib6sHIGqLBbglkgDoT2dhyKAXtEXE= Received: by 10.42.1.12 with SMTP id 12mr5810982ice.366.1304060231894; Thu, 28 Apr 2011 23:57:11 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id ww2sm942483icb.3.2011.04.28.23.57.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 23:57:10 -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 p3T6v6Nu082720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2011 02:57:07 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3T6v5IA082719; Fri, 29 Apr 2011 02:57:05 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Fri, 29 Apr 2011 02:57:05 -0400 From: "Jason J. Hellenthal" To: Ollivier Robert Message-ID: <20110429065705.GA82365@DataIX.net> References: <4DB8EF02.8060406@bk.ru> <1079311802.20110428070300@nitronet.pl> <20110428135654.GF64725@rron-2.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20110428135654.GF64725@rron-2.local> 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: freebsd-fs@freebsd.org Subject: Re: ZFS v28 for 8.2-STABLE 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, 29 Apr 2011 06:57:13 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ollivier, On Thu, Apr 28, 2011 at 03:56:54PM +0200, Ollivier Robert wrote: >According to Ruslan QuAzI: >> I will try to probe patch for 8.2-RELENG > >I'm surprised, I just upgraded my main machine to r221058, applied the 201= 10317 patch from mm and apart from the sysmacros.h that you need to remove = manually, it patched, compiled and ran ok. > >--=20 >Ollivier ROBERT -=3D- FreeBSD: The Power to Serve! -=3D- roberto@keltia.net >In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ > He should be applying the patch with ( patch -p0 -E ) and removing the sysmacros.h Leaving -E off of patch(1) will cause this to happen. --=20 Regards, (jhell) Jason Hellenthal --liOOAslEiF7prFVr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNumFBAAoJEJBXh4mJ2FR+whIH/0Tm2+bUdXoO0oXzpr6L6T3N IssBsB6YTQttWQcAFTCpyIJzO8ktrmYJKCIxXSpcmsw7oP3ErxmesjNG4vtqShz1 1kLivT2KR9QN/3VAI+U+k7hhJqnxR7ZhDURezcI5ZUT/JCOYgA4cMCVm3Vtz2WuM eaNk10ChXecAH1JkzZ1gyQYiKGsINEzii5FRPIAeR1qfgedWhiYg6usA+BLMRt2N wcB9QtoU/DstxOfnhe8XoPNx8FlpfeWb5TI8bug65AtDoK4ri9uoeKsT2ZkzfoCe 4ejmzcjRFfMkkRZlU387cFoCnfcs7kM8vRBDELg/ysrnqxweZxwtbWD7Gzpze+4= =z8K8 -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 29 07:30: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 03D3A10656A6 for ; Fri, 29 Apr 2011 07:30:15 +0000 (UTC) (envelope-from marco@tolstoy.tols.org) Received: from tolstoy.tols.org (tolstoy.tols.org [IPv6:2a02:898:0:20::57:1]) by mx1.freebsd.org (Postfix) with ESMTP id BD4B28FC19 for ; Fri, 29 Apr 2011 07:30:10 +0000 (UTC) Received: from tolstoy.tols.org (localhost [127.0.0.1]) by tolstoy.tols.org (8.14.4/8.14.4) with ESMTP id p3T7U882018370 for ; Fri, 29 Apr 2011 07:30:08 GMT (envelope-from marco@tolstoy.tols.org) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at tolstoy.tols.org Received: (from marco@localhost) by tolstoy.tols.org (8.14.4/8.14.4/Submit) id p3T7U8rX018369 for freebsd-fs@freebsd.org; Fri, 29 Apr 2011 09:30:08 +0200 (CEST) (envelope-from marco) Resent-Message-Id: <201104290730.p3T7U8rX018369@tolstoy.tols.org> Date: Fri, 29 Apr 2011 09:28:56 +0200 From: Marco van Tol To: freebsd-questions@freebsd.org Message-ID: <20110429072856.GB18271@tolstoy.tols.org> References: <4DB98F5D.2090108__2814.45118967003$1304006598$gmane$org@ukr.net> <4DB99860.3070701@FreeBSD.org> <4DB9BC80.9010401@ukr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DB9BC80.9010401@ukr.net> User-Agent: Mutt/1.4.2.3i Resent-From: marco@tols.org Resent-Date: Fri, 29 Apr 2011 09:30:08 +0200 Resent-To: freebsd-fs@freebsd.org X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on tolstoy.tols.org Cc: Subject: Re: ZFS-Only FreeBSD and crashdump 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, 29 Apr 2011 07:30:15 -0000 On Thu, Apr 28, 2011 at 10:14:08PM +0300, Vladislav V. Prodan wrote: > 28.04.2011 19:40, Andriy Gapon wrote: > >At the moment FreeBSD doesn't support dumping to ZFS zvols, if that's what > >you are > >asking. > > And when do planning to add support? :) > Option to use to dump the usb-flash has its limitations, both on disk > size and write speed? Well, to be honest, how do you suppose dumping core to a software raid should work in a situation where the software has crashed? :-) Marco van Tol -- Je moet me niet dood maken met een blije mus From owner-freebsd-fs@FreeBSD.ORG Fri Apr 29 09:56:34 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 3A926106564A for ; Fri, 29 Apr 2011 09:56:34 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id E3EA18FC1B for ; Fri, 29 Apr 2011 09:56:33 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 97EC3EA02; Fri, 29 Apr 2011 11:56:32 +0200 (CEST) Date: Fri, 29 Apr 2011 11:56:30 +0200 From: Ollivier Robert To: Alexander Leidinger Message-ID: <20110429095630.GD69969@roberto-al.eurocontrol.fr> References: <20110428113956.26165fniv7wsvu4o@webmail.leidinger.net> <20110428135943.GG64725@rron-2.local> <20110428214625.00001851@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110428214625.00001851@unknown> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Fri, 29 Apr 2011 11:56:32 +0200 (CEST) Cc: freebsd-fs@freebsd.org Subject: Re: GPT & dump-partition 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, 29 Apr 2011 09:56:34 -0000 According to Alexander Leidinger: > (so not related). There is no mention of "core" or "save" or "crash". > My guess would have been freebsd-swap, and in another mail I got > informed that this is what is used by other people. Right, I misunderstood then. As usual, the swap is the main area fior dumps yes. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Fri Apr 29 09:58:53 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 C8DCD106566C for ; Fri, 29 Apr 2011 09:58:53 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3DF8FC23 for ; Fri, 29 Apr 2011 09:58:53 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 975F3EA05; Fri, 29 Apr 2011 11:58:52 +0200 (CEST) Date: Fri, 29 Apr 2011 11:58:50 +0200 From: Ollivier Robert To: "Jason J. Hellenthal" Message-ID: <20110429095849.GE69969@roberto-al.eurocontrol.fr> References: <4DB8EF02.8060406@bk.ru> <1079311802.20110428070300@nitronet.pl> <20110428135654.GF64725@rron-2.local> <20110429065705.GA82365@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110429065705.GA82365@DataIX.net> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Fri, 29 Apr 2011 11:58:52 +0200 (CEST) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS v28 for 8.2-STABLE 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, 29 Apr 2011 09:58:53 -0000 According to Jason J. Hellenthal: > Leaving -E off of patch(1) will cause this to happen. Agreed. I was commenting more on the "does not patch" or "does not compile" part. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Fri Apr 29 20:20:37 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 A057F1065678 for ; Fri, 29 Apr 2011 20:20:37 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE258FC08 for ; Fri, 29 Apr 2011 20:20:35 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QFuB0-0000Hg-BC for freebsd-fs@freebsd.org; Fri, 29 Apr 2011 22:20:34 +0200 Received: from 195.225.157.86 ([195.225.157.86]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Apr 2011 22:20:34 +0200 Received: from c.kworr by 195.225.157.86 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Apr 2011 22:20:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Volodymyr Kostyrko Date: Fri, 29 Apr 2011 23:20:21 +0300 Lines: 19 Message-ID: References: <4DB8EF02.8060406@bk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 195.225.157.86 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; uk-UA; rv:1.9.2.15) Gecko/20110306 Thunderbird/3.1.9 In-Reply-To: <4DB8EF02.8060406@bk.ru> Subject: Re: ZFS v28 for 8.2-STABLE 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, 29 Apr 2011 20:20:37 -0000 28.04.2011 07:37, Ruslan Yakovlev wrote: > Does actually patch exist for 8.2-STABLE ? > I probe > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz > > Building failed with: > can't cd to /usr/src/cddl/usr.bin/zstreamdump > Also sys/cddl/compat/opensolaris/sys/sysmacros.h failed to patch. > > Current FreeBSD 8.2-STABLE #35 Mon Apr 18 03:40:38 EEST 2011 i386 > periodically frozen on high load like backup by rsync or find -sx ... > (from default cron tasks). Well ZFSv28 should be very close to STABLE for now? http://lists.freebsd.org/pipermail/freebsd-current/2011-February/023152.html -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 00:15:28 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 9F8BD106566B for ; Sat, 30 Apr 2011 00:15:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 49F8C8FC12 for ; Sat, 30 Apr 2011 00:15:28 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id dcFU1g0050mv7h05BcFU6e; Sat, 30 Apr 2011 00:15:28 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta11.westchester.pa.mail.comcast.net with comcast id dcFS1g01X1t3BNj3XcFTva; Sat, 30 Apr 2011 00:15:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C00939B418; Fri, 29 Apr 2011 17:15:24 -0700 (PDT) Date: Fri, 29 Apr 2011 17:15:24 -0700 From: Jeremy Chadwick To: Volodymyr Kostyrko Message-ID: <20110430001524.GA58845@icarus.home.lan> References: <4DB8EF02.8060406@bk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS v28 for 8.2-STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 00:15:28 -0000 On Fri, Apr 29, 2011 at 11:20:21PM +0300, Volodymyr Kostyrko wrote: > 28.04.2011 07:37, Ruslan Yakovlev wrote: > >Does actually patch exist for 8.2-STABLE ? > >I probe > >http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz > > > >Building failed with: > >can't cd to /usr/src/cddl/usr.bin/zstreamdump > >Also sys/cddl/compat/opensolaris/sys/sysmacros.h failed to patch. > > > >Current FreeBSD 8.2-STABLE #35 Mon Apr 18 03:40:38 EEST 2011 i386 > >periodically frozen on high load like backup by rsync or find -sx ... > >(from default cron tasks). > > Well ZFSv28 should be very close to STABLE for now? > > http://lists.freebsd.org/pipermail/freebsd-current/2011-February/023152.html It's now a matter of opinion. The whole idea of ZFSv28 being committed to HEAD was to be tested. I haven't seen any indication of a progress report provided for anything on HEAD that pertains to ZFSv28, have you? Furthermore, the FreeBSD Quarterly Status Report just came out on 04/27 for the months of January-March (almost a 2 month delay, sigh): 1737 04/27 10:58 Daniel Gerzo ( 41K) FreeBSD Status Report January-March, 2011 http://www.freebsd.org/news/status/report-2011-01-2011-03.html Which states that ZFSv28 is "now available in CURRENT", which we've known for months: http://www.freebsd.org/news/status/report-2011-01-2011-03.html#ZFSv28-available-in-FreeBSD-9-CURRENT But again, no progress report, so nobody except those who follow HEAD/CURRENT know what the progress is. And that progress has not been relayed to any of the non-HEAD/CURRENT lists. I'm a total hard-ass about this stuff, and have been for years, because it all boils down to communication (or lack there-of). It seems very hasty to say "Yeah! MFC this!" when we (folks who only follow STABLE) have absolutely no idea if what's in CURRENT is actually broken in some way or if there are outstanding problems -- and if there are, what those are so users can be aware of them in advance. -- | 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 Sat Apr 30 03:24:17 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 E7A86106566C for ; Sat, 30 Apr 2011 03:24:17 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A8B248FC14 for ; Sat, 30 Apr 2011 03:24:17 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 380421FFC35; Sat, 30 Apr 2011 03:07:10 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B1DFC84530; Sat, 30 Apr 2011 05:07:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Rick Macklem References: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 30 Apr 2011 05:07:09 +0200 In-Reply-To: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> (Rick Macklem's message of "Fri, 15 Apr 2011 20:57:00 -0400 (EDT)") Message-ID: <86r58kfndu.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 03:24:18 -0000 Rick Macklem writes: > Well, I've PXE booted from it using the old pxeboot code that used NFSv2 > and the recent code that I modified to use NFSv3. I don't see why there > would be a problem, but obviously I can't guarantee that. I've seen some pxeboot-related weirdness with the new code... Server: ds4.des.no, amd64, FreeBSD 9.0 r221100 Client: via.des.no, i386, FreeBSD 9.0 r221205 (both with mods, but none that would affect NFS) Note that they conveniently bracket the switch - the server runs the old NFS code while the client runs the new. Booting a customized kernel with the new NFS stack results in a weird error message from mountroot: Trying to mount root from nfs:ds4:/jail/via [rw]... mountroot: waiting for device ds4:/jail/via ... Mounting from nfs:ds4:/jail/via failed with error 19. Trying to mount root from nfs: []... NFS ROOT: 10.0.0.4:/jail/via (error 19 is ENODEV) Booting a customized kernel with the old NFS stack (and with /etc/fstab altered to list / as oldnfs instead of nfs) produces a slightly different result: Trying to mount root from oldnfs:ds4:/jail/via [rw]... mountroot: waiting for device ds4:/jail/via ... Mounting from oldnfs:ds4:/jail/via failed with error 19. Trying to mount root from nfs: []... Mounting from nfs failed with error 2: unknown file system. Note that after the first attempt fails, it tries again with "nfs" instead of "oldnfs". If I type "oldnfs:" at the mountroot prompt, I get: Trying to mount root from oldnfs: []... NFS ROOT: 10.0.0.4:/jail/via The rc scripts also get confused because they think the NFS client code is not loaded, and try to load it again, leading to the following kernel error message: interface oldnfs.1 already present in the KLD 'kernel'! accompanied by a message from the script itself: /etc/rc: WARNING: Unable to load kernel module nfsclient So there are (at least) two kernel issues: 1) the "error 19" that occurs with both the old and the new stack 2) the fallback that always uses "nfs" instead of using the correct fstype for whichever NFS stack is loaded. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 06:54:20 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 F1249106564A for ; Sat, 30 Apr 2011 06:54:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7FBAB8FC0C for ; Sat, 30 Apr 2011 06:54:20 +0000 (UTC) Received: by bwz12 with SMTP id 12so5115554bwz.13 for ; Fri, 29 Apr 2011 23:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=IPduBIrpUY3JS2+a4w5HqEoa9a9dgdaqYyDCfBHHEn4=; b=Yln6w62MThqEDmKQny2yliXNq3y4pLcCPDvYh5P4w502hdCqfgOupaWM5fCAZHynf+ mMfoqty8glQRBJSxZ7xn2h3CoV68jevMZ1zYhPRbqvwrETtqpiX9rva89PEvW2VFSNk0 MDaGT5V/UlQwG5RGbCZ758C148C9wGvgUdU2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=Ow6zC56BttEbEYZjbBZOxyteDxcrqmqAd0TIvK/rkCtqRiDf4XnZpP9R2vmjaC5qoY tIStObjF5pLlCVvSxb5Bf4k2H2fwFPDmzXu26DIO4HxTJBctO43ALS6RxrY32S8V40Zl reC7TtvLcb2mjZRL/3C14YpYoCo+BY9aIcaLo= Received: by 10.204.20.132 with SMTP id f4mr1478291bkb.169.1304146459427; Fri, 29 Apr 2011 23:54:19 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w3sm2006281bkt.17.2011.04.29.23.54.18 (version=SSLv3 cipher=OTHER); Fri, 29 Apr 2011 23:54:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DBBB20A.5050102@FreeBSD.org> Date: Sat, 30 Apr 2011 09:54:02 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 06:54:21 -0000 Hi. I've noticed that on file deletion from UFS with TRIM enabled, kernel issues BIO_DELETE for each 16K (block size?) separately -- thousands per second for single big file deletion. Fortunately ada driver will try to aggregate them for the device, but won't some clustering code worth to be there? -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 07:28:34 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 3C962106567A for ; Sat, 30 Apr 2011 07:28:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id F2B878FC18 for ; Sat, 30 Apr 2011 07:28:33 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id djTK1g0041uE5Es55jUar8; Sat, 30 Apr 2011 07:28:34 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta16.westchester.pa.mail.comcast.net with comcast id djUY1g00B1t3BNj3cjUZG7; Sat, 30 Apr 2011 07:28:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 86A969B418; Sat, 30 Apr 2011 00:28:31 -0700 (PDT) Date: Sat, 30 Apr 2011 00:28:31 -0700 From: Jeremy Chadwick To: Alexander Motin Message-ID: <20110430072831.GA65598@icarus.home.lan> References: <4DBBB20A.5050102@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DBBB20A.5050102@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 07:28:34 -0000 On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: > I've noticed that on file deletion from UFS with TRIM enabled, kernel > issues BIO_DELETE for each 16K (block size?) separately -- thousands per > second for single big file deletion. Fortunately ada driver will try to > aggregate them for the device, but won't some clustering code worth to > be there? I'd like to know who decided it would be best to submit the TRIM command automatically on every single block that is deemed free by UFS during inode removal. The performance hit, from what I've been reading, from doing this is quite severe. Many SSDs take hundreds of milliseconds to complete TRIM operations, which greatly impacts filesystem performance. I appreciate the efforts to get TRIM into FreeBSD for UFS, but the implementation -- if what Alexander says is accurate -- seems like a bad choice. Solutions as I see them: a) Provide appropriate UFS framework to obtain a list of freed blocks (I do not know much about UFS under the hood so I don't know how to accomplish this), and let a userspace daemon issue the appropriate commands to the underlying ATA/CAM layer, providing a list (more importantly, a range of) LBAs to initiate TRIM for. Daemon could run at some particular interval (controlled by the user of course), or meet sets of required criteria before actually doing it. b) periodic(8) script (relying on appropriate ways of getting freed blocks) which could run weekly. Maybe the TRIM-issuing piece could be implemented in both atacontrol(8) and camcontrol(8)? c) Don't want it in userspace? Okay, make it some kind of kernel thread. It still needs to be configurable, probably through sysctl. It should also provide some form of accounting details (how many LBAs its freed, as well as how many times TRIM itself has been run (these are two separate metrics)). d) Look at how Linux and/or Windows 7 does this. I believe Linux doesn't do it automatically at all, but instead provides necessary frameworks within libata and their SCSI layer to offer the capability. There was a script circling within the Linux community called "wiper.sh" which required use of a very new version of hdparm(8) that would find freed blocks on ext3 (I think?) and issue hdparm commands to induce TRIM on sets of LBAs. ext4 seems to offer some sort of "support" for this but only when the filesystem is mounted with an option called "discard" (and specifying that mount option is a manual process). Catches: whatever method needs to be able to handle the situation where a device is added on-the-fly (e.g. hot-swap insertion of a new disk), so for TRIM capability identification, probing kern.disks for TRIM capability per appropriate ioctls would be ideal. Other notes: TRIM needs to be supported on swap as well, and in my opinion this is just as important as it being in UFS. I'm not sure how one would implement that. Sorry for the long-winded Email, but when I see/read about things like what mav@ has brought up, I become immediately concerned (as someone who has many production systems using Intel X25-M and Intel 320-series SSDs for /, swap, /var, /tmp, and /usr). -- | 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 Sat Apr 30 07:53:17 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 07362106566B for ; Sat, 30 Apr 2011 07:53:17 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84B6A8FC15 for ; Sat, 30 Apr 2011 07:53:16 +0000 (UTC) Received: by bwz12 with SMTP id 12so5139053bwz.13 for ; Sat, 30 Apr 2011 00:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Of817jsW7Zg2qw1c3I6N15JIwVs0D1RDeZ2tezE/skU=; b=f2KlAQ1qMbEPUpFnAPBOkzV1YePiro+7mO/zl3OaPu1fHt6goNOee5qa/zpI59apJO KmK1XCj9fIfAaS2rFbNLWQit1T7Vi5/yzFww1nVJ5aIjEOgahbvTyptws8PeCBoABEjW nLoizWeXllqLVjZESx1BQVzYrnbCk8BB6ELXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=JoPHlAqaJizrm65rrIVXndfq/zfBD1dEEwPL4HK10BxxmMkfXYwb7czO/r0+QOL27d YE5SZfa17bZsCZwkbEG9XgTSUchmwWcXhW9VXgda4Cjse3azZ1+FKM2jj32B/rYHHyLR I3kpXFWkpB/eAx8jyRYeOjF+tlsIaYk4PxC2A= Received: by 10.204.155.80 with SMTP id r16mr2662892bkw.36.1304149995312; Sat, 30 Apr 2011 00:53:15 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q25sm2031779bkk.10.2011.04.30.00.53.13 (version=SSLv3 cipher=OTHER); Sat, 30 Apr 2011 00:53:14 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DBBBFDA.8040908@FreeBSD.org> Date: Sat, 30 Apr 2011 10:52:58 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Jeremy Chadwick References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan> In-Reply-To: <20110430072831.GA65598@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 07:53:17 -0000 Jeremy Chadwick wrote: > On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: >> I've noticed that on file deletion from UFS with TRIM enabled, kernel >> issues BIO_DELETE for each 16K (block size?) separately -- thousands per >> second for single big file deletion. Fortunately ada driver will try to >> aggregate them for the device, but won't some clustering code worth to >> be there? > > I'd like to know who decided it would be best to submit the TRIM command > automatically on every single block that is deemed free by UFS during > inode removal. The performance hit, from what I've been reading, from > doing this is quite severe. Many SSDs take hundreds of milliseconds to > complete TRIM operations, which greatly impacts filesystem performance. > I appreciate the efforts to get TRIM into FreeBSD for UFS, but the > implementation -- if what Alexander says is accurate -- seems like a bad > choice. There is a special code in ada driver, grouping multiple ranges into single disk command to address that hundreds of milliseconds delay. So it is not so major problem. But 25K BIO_DELETEs per second flowing through GEOM is not very good for the system. And 25K ranges still could be more difficult for the disk. And while ATA provides the way to delete multiple ranges with one command, I am not sure SCSI or proprietary drivers can do the same. > Solutions as I see them: > > a) Provide appropriate UFS framework to obtain a list of freed blocks (I > do not know much about UFS under the hood so I don't know how to > accomplish this), and let a userspace daemon issue the appropriate > commands to the underlying ATA/CAM layer, providing a list (more > importantly, a range of) LBAs to initiate TRIM for. Daemon could run at > some particular interval (controlled by the user of course), or meet > sets of required criteria before actually doing it. > > b) periodic(8) script (relying on appropriate ways of getting freed > blocks) which could run weekly. Maybe the TRIM-issuing piece could be > implemented in both atacontrol(8) and camcontrol(8)? > > c) Don't want it in userspace? Okay, make it some kind of kernel > thread. It still needs to be configurable, probably through sysctl. It > should also provide some form of accounting details (how many LBAs its > freed, as well as how many times TRIM itself has been run (these are two > separate metrics)). > > d) Look at how Linux and/or Windows 7 does this. I believe Linux > doesn't do it automatically at all, but instead provides necessary > frameworks within libata and their SCSI layer to offer the capability. > There was a script circling within the Linux community called "wiper.sh" > which required use of a very new version of hdparm(8) that would find > freed blocks on ext3 (I think?) and issue hdparm commands to induce > TRIM on sets of LBAs. ext4 seems to offer some sort of "support" for > this but only when the filesystem is mounted with an option called > "discard" (and specifying that mount option is a manual process). > > Catches: whatever method needs to be able to handle the situation where > a device is added on-the-fly (e.g. hot-swap insertion of a new disk), so > for TRIM capability identification, probing kern.disks for TRIM > capability per appropriate ioctls would be ideal. I don't think user level can/should do anything here for the live file systems. Otherwise it would require FS code to report it about blocks reuse and wait for running TRIM to complete. Bad choice. Existing implementation integrated into SU (as I understand it) is IMHO fine, except lack of clustering. If you like to do it offline - there is new -E option just added to the fsck_ffs. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 09:34:31 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 CDC1A106564A for ; Sat, 30 Apr 2011 09:34:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8AB8FC16 for ; Sat, 30 Apr 2011 09:34:31 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p3U9FQJK092375 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 30 Apr 2011 02:15:28 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DBBD368.7000301@freebsd.org> Date: Sat, 30 Apr 2011 02:16:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeremy Chadwick References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan> In-Reply-To: <20110430072831.GA65598@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Alexander Motin Subject: Re: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 09:34:31 -0000 On 4/30/11 12:28 AM, Jeremy Chadwick wrote: > On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: >> I've noticed that on file deletion from UFS with TRIM enabled, kernel >> issues BIO_DELETE for each 16K (block size?) separately -- thousands per >> second for single big file deletion. Fortunately ada driver will try to >> aggregate them for the device, but won't some clustering code worth to >> be there? > I'd like to know who decided it would be best to submit the TRIM command > automatically on every single block that is deemed free by UFS during > inode removal. The performance hit, from what I've been reading, from > doing this is quite severe. Many SSDs take hundreds of milliseconds to > complete TRIM operations, which greatly impacts filesystem performance. > I appreciate the efforts to get TRIM into FreeBSD for UFS, but the > implementation -- if what Alexander says is accurate -- seems like a bad > choice. well not all devices take it as a hit.. The suggestion of some sort of clustering is a good one but it should be tunable. > Sorry for the long-winded Email, but when I see/read about things like > what mav@ has brought up, I become immediately concerned (as someone who > has many production systems using Intel X25-M and Intel 320-series SSDs > for /, swap, /var, /tmp, and /usr). all of which I'd class as "really slow" :-) From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 10:51:05 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 29EF21065670; Sat, 30 Apr 2011 10:51:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7928E8FC13; Sat, 30 Apr 2011 10:51:04 +0000 (UTC) Received: by bwz12 with SMTP id 12so5214985bwz.13 for ; Sat, 30 Apr 2011 03:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=OO6yqiUV6+VUaPpPbkQE3CvsuGDnnWLNAmaei7Y7pb8=; b=JaH6BgTRt3CMqpw6TOzEbfuClgXhsrn0t0VdamZ1GDLQeFtEt7Z0Nk3saFszirE6fV 7ofxwe4QCUcOGaOxmAWkP3cnEn2vpwiL+BSbsf1Ocs6gfFeWo+6yeHbQjv6RgNchCOIj py9WftrIIaO56Qyjxnzgqnz52tcv7SKBNaUdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=bgg016E4TFvVdZihdf4MmWsko8mduL1kfgva2xcGIkbX5d+d3MvGLmvrE7TdTbDIKX 9E73A59Zj51DmTtrmnxEynTk68dtXX0CYd5DLd81/6FWGhea2KRzw8X1m4by8F/S62eT OJZwiBvWDiwGZJnzWflbuOt2m7QMFaYhJpIFs= Received: by 10.204.171.65 with SMTP id g1mr5485978bkz.45.1304160663297; Sat, 30 Apr 2011 03:51:03 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w3sm2106453bkt.5.2011.04.30.03.51.01 (version=SSLv3 cipher=OTHER); Sat, 30 Apr 2011 03:51:02 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DBBE985.9000701@FreeBSD.org> Date: Sat, 30 Apr 2011 13:50:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Julian Elischer References: <20110430072831.GA65598@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 10:51:05 -0000 Julian Elischer wrote: > On 4/30/11 12:28 AM, Jeremy Chadwick wrote: >> On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: >>> I've noticed that on file deletion from UFS with TRIM enabled, kernel >>> issues BIO_DELETE for each 16K (block size?) separately -- thousands per >>> second for single big file deletion. Fortunately ada driver will try to >>> aggregate them for the device, but won't some clustering code worth to >>> be there? >> I'd like to know who decided it would be best to submit the TRIM command >> automatically on every single block that is deemed free by UFS during >> inode removal. The performance hit, from what I've been reading, from >> doing this is quite severe. Many SSDs take hundreds of milliseconds to >> complete TRIM operations, which greatly impacts filesystem performance. >> I appreciate the efforts to get TRIM into FreeBSD for UFS, but the >> implementation -- if what Alexander says is accurate -- seems like a bad >> choice. > > well not all devices take it as a hit.. The suggestion of some sort of > clustering is a good one but it should be tunable. I believe any device should benefit from receiving single 128K request instead of 8*16k. Just because of command processing overhead. Am I wrong? -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 12:18:33 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 29804106566B for ; Sat, 30 Apr 2011 12:18:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DC7008FC12 for ; Sat, 30 Apr 2011 12:18:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAG/9u02DaFvO/2dsb2JhbACEUaI9iHGpPpAkgSqDVYEBBI55jj4 X-IronPort-AV: E=Sophos;i="4.64,292,1301889600"; d="scan'208";a="120007074" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Apr 2011 08:18:31 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CAEC6B3F22; Sat, 30 Apr 2011 08:18:31 -0400 (EDT) Date: Sat, 30 Apr 2011 08:18:31 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Message-ID: <410050117.807767.1304165911685.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <86r58kfndu.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 12:18:33 -0000 > Rick Macklem writes: > > Well, I've PXE booted from it using the old pxeboot code that used > > NFSv2 > > and the recent code that I modified to use NFSv3. I don't see why > > there > > would be a problem, but obviously I can't guarantee that. > > I've seen some pxeboot-related weirdness with the new code... > > Server: ds4.des.no, amd64, FreeBSD 9.0 r221100 > Client: via.des.no, i386, FreeBSD 9.0 r221205 > > (both with mods, but none that would affect NFS) > > Note that they conveniently bracket the switch - the server runs the > old > NFS code while the client runs the new. > > Booting a customized kernel with the new NFS stack results in a weird > error message from mountroot: > > Trying to mount root from nfs:ds4:/jail/via [rw]... > mountroot: waiting for device ds4:/jail/via ... > Mounting from nfs:ds4:/jail/via failed with error 19. > Trying to mount root from nfs: []... > NFS ROOT: 10.0.0.4:/jail/via > > (error 19 is ENODEV) > I always get this error and got it even before I did the switch, I think? It's caused by vfs_mountroot_parse() finding an entry in the fstab, which then calls parse_mount(). Basically anything that specifies a non-NULL "dev" argument is going to fail for NFS. (See the "waiting for device ds4:/jail/via" which indicates "dev" is set to that. The failure and error message is because parse_mount_dev_present() can't find a device file called "ds4:/jail/via", which it shouldn't be able to. I can't see anything that would have skipped doing this before the switchover? I don't think my changes made this any different. So, you didn't get this before you switched over? > Booting a customized kernel with the old NFS stack (and with > /etc/fstab > altered to list / as oldnfs instead of nfs) produces a slightly > different result: > > Trying to mount root from oldnfs:ds4:/jail/via [rw]... > mountroot: waiting for device ds4:/jail/via ... > Mounting from oldnfs:ds4:/jail/via failed with error 19. > Trying to mount root from nfs: []... > Mounting from nfs failed with error 2: unknown file system. > > Note that after the first attempt fails, it tries again with "nfs" > instead of "oldnfs". If I type "oldnfs:" at the mountroot prompt, I > get: > > Trying to mount root from oldnfs: []... > NFS ROOT: 10.0.0.4:/jail/via > You can get around this by putting a line like: vfs.root.mountfrom="oldnfs:" - in the boot/loader.conf on the root fs in the server. It will then use "oldnfs:" instead of the default "nfs:" (which is hardwired by setting rootdevnames[0] to it). > The rc scripts also get confused because they think the NFS client > code > is not loaded, and try to load it again, leading to the following > kernel > error message: > > interface oldnfs.1 already present in the KLD 'kernel'! > > accompanied by a message from the script itself: > > /etc/rc: WARNING: Unable to load kernel module nfsclient > Ok, I'll need to look at this. At a glance, I see a load_kld, but that won't get upset if it's already loaded. (It does need to be fixed, though, since it refers to nfsclient as the module for "nfs" instead of nfscl.) > So there are (at least) two kernel issues: > > 1) the "error 19" that occurs with both the old and the new stack > I don't know if this is considered a bug or a feature, but I think it has been there for a while and happened before the switchover. If you could test a pre-switchover (but recent) client and see if the message shows up, that would be appreciated. > 2) the fallback that always uses "nfs" instead of using the correct > fstype for whichever NFS stack is loaded. > The default is changed via the vfs.root.mountfrom="oldnfs:" line added to boot/loader.conf on the root fs on the server. That is mentioned in UPDATING. Thanks for pointing these out, rick From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 13:14:08 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 ECDDE106566B for ; Sat, 30 Apr 2011 13:14:08 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A96758FC1C for ; Sat, 30 Apr 2011 13:14:08 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C3F621FFC35; Sat, 30 Apr 2011 13:14:07 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 9C1D5844D9; Sat, 30 Apr 2011 15:14:07 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Rick Macklem References: <410050117.807767.1304165911685.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 30 Apr 2011 15:14:07 +0200 In-Reply-To: <410050117.807767.1304165911685.JavaMail.root@erie.cs.uoguelph.ca> (Rick Macklem's message of "Sat, 30 Apr 2011 08:18:31 -0400 (EDT)") Message-ID: <86iptvg9uo.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 13:14:09 -0000 Rick Macklem writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > interface oldnfs.1 already present in the KLD 'kernel'! > > /etc/rc: WARNING: Unable to load kernel module nfsclient > Ok, I'll need to look at this. At a glance, I see a load_kld, > but that won't get upset if it's already loaded. (It does need > to be fixed, though, since it refers to nfsclient as the module > for "nfs" instead of nfscl.) This comes from mountcritremote: case "`mount -d -a -t nfs 2> /dev/null`" in *mount_nfs*) # Handle absent nfs client support load_kld -m nfs nfsclient || return 1 ;; esac mount(8) will print "mount_oldnfs" instead of "mount_nfs". Note that until you flipped the switch, the exact same error would occur, in reverse, on systems running the new stack. > If you could test a pre-switchover (but recent) client and see if the > message shows up, that would be appreciated. It does, so it's not something new. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 17:42:46 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 EBD4C1065673 for ; Sat, 30 Apr 2011 17:42:46 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta03.eastlink.ca (mta03.eastlink.ca [24.224.136.9]) by mx1.freebsd.org (Postfix) with ESMTP id AE29F8FC12 for ; Sat, 30 Apr 2011 17:42:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip01.eastlink.ca ([24.222.39.10]) by mta03.eastlink.ca (Oracle Communications Messaging Exchange Server 7u4-21.01 64bit (built Feb 16 2011)) with ESMTP id <0LKH00GDG7V72M30@mta03.eastlink.ca> for freebsd-fs@freebsd.org; Sat, 30 Apr 2011 14:42:43 -0300 (ADT) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=j7CbBf0UjVt5t8oMLzyQ2uTroMF2aq/TSONqDSZKfgE= c=1 sm=1 a=kj9zAlcOel0A:10 a=WVrXK5GQesf_0j5XngEA:9 a=CjuIK1q_8ugA:10 a=E/PVjAe7IbPkHCM0BPV0xg==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip01.eastlink.ca with ESMTP; Sat, 30 Apr 2011 14:42:43 -0300 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Sat, 30 Apr 2011 14:42:43 -0300 From: Chris Forgeron To: Jeremy Chadwick , Volodymyr Kostyrko Date: Sat, 30 Apr 2011 14:42:41 -0300 Thread-topic: ZFS v28 for 8.2-STABLE Thread-index: AcwGy9GMoMlgOVVcSjGEbmYCd7spvAAkMXaw Message-id: References: <4DB8EF02.8060406@bk.ru> <20110430001524.GA58845@icarus.home.lan> In-reply-to: <20110430001524.GA58845@icarus.home.lan> Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Cc: "freebsd-fs@freebsd.org" Subject: RE: ZFS v28 for 8.2-STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 17:42:47 -0000 IMHO: I've been working with ZFS v28 since the early days that pjd made the patch available, and while I'm actually using it daily in (a very limited and controlled) production, I feel it needs more testing before it's under serious consideration to be included in Stable. It's got a few little catches and gotchas that will frustrate anyone who hasn't been working with it - Hangs here and there, and the potential to destroy your pool if you're not careful. Just last night, I added a spare drive to a 10 drive pool (two five-drive raidz striped) and it hung on me. After 20 minutes of waiting, I hard rebooted, and issued the command again, and it completed within 30 seconds. Was I suffering resource exhaustion someplace? It's hard to say, as it happened once and it's tricky to reproduce. This box was running for over 30 days, serving a lot of disk-io to an ESX cluster. This isn't a slight against pjd's work at all - He's done an excellent job, and the issues I'm running into aren't easily reproducible by others. It's up to me to take the time to trace the issues down so they can be properly squashed, but I'm busy putting out other fires for now. We all want to see v28 with the stamp of approval that Stable will give it, but I think that event is well into the summer months. Let's get more people stress testing it and trying it on different configurations, hopefully that will give the feedback that pjd needs for final tweaking and correction. If anything, make the v28 patchfile very easy to obtain and install - or possibly a kernel option like the old/new NFS server, so people can enable the new v28 code easier for testing purposes? From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 21: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 CF391106566B for ; Sat, 30 Apr 2011 21:03:14 +0000 (UTC) (envelope-from pierre@userid.org) Received: from mail.storm.ca (unknown [IPv6:2607:f0b0:0:6:209:87:239:66]) by mx1.freebsd.org (Postfix) with ESMTP id 9475A8FC0A for ; Sat, 30 Apr 2011 21:03:12 +0000 (UTC) Received: from mail.userid.org (pandora.userid.org [216.106.102.33]) by mail.storm.ca (8.14.2+Sun/8.14.2) with ESMTP id p3UFiXjf015812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Apr 2011 11:44:40 -0400 (EDT) Received: from [IPv6:2607:f0b0:1:3800:b13d:631b:1f8a:10d4] (unknown [IPv6:2607:f0b0:1:3800:b13d:631b:1f8a:10d4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre) by mail.userid.org (Postfix) with ESMTP id 60BA42C77A2; Sat, 30 Apr 2011 11:44:05 -0400 (EDT) Message-ID: <4DBC2E46.9060404@userid.org> Date: Sat, 30 Apr 2011 11:44:06 -0400 From: Pierre Lamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jeremy Chadwick References: <4DB8EF02.8060406@bk.ru> <20110430001524.GA58845@icarus.home.lan> In-Reply-To: <20110430001524.GA58845@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-userid-MailScanner-Information: Please contact the ISP for more information X-userid-MailScanner-ID: 60BA42C77A2.AC5D8 X-userid-MailScanner: Found to be clean X-userid-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=1.199, required 6, J_CHICKENPOX_33 0.60, J_CHICKENPOX_53 0.60, NO_RELAYS -0.00) X-userid-MailScanner-SpamScore: 1 X-userid-MailScanner-From: pierre@userid.org X-Spam-Status: No Cc: freebsd-fs@freebsd.org, Volodymyr Kostyrko Subject: Re: ZFS v28 for 8.2-STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 21:03:15 -0000 On 4/29/2011 8:15 PM, Jeremy Chadwick wrote: > On Fri, Apr 29, 2011 at 11:20:21PM +0300, Volodymyr Kostyrko wrote: >> 28.04.2011 07:37, Ruslan Yakovlev wrote: >>> Does actually patch exist for 8.2-STABLE ? >>> I probe >>> http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz >>> >>> Building failed with: >>> can't cd to /usr/src/cddl/usr.bin/zstreamdump >>> Also sys/cddl/compat/opensolaris/sys/sysmacros.h failed to patch. >>> >>> Current FreeBSD 8.2-STABLE #35 Mon Apr 18 03:40:38 EEST 2011 i386 >>> periodically frozen on high load like backup by rsync or find -sx ... >>> (from default cron tasks). >> Well ZFSv28 should be very close to STABLE for now? >> >> http://lists.freebsd.org/pipermail/freebsd-current/2011-February/023152.html > It's now a matter of opinion. The whole idea of ZFSv28 being committed > to HEAD was to be tested. I haven't seen any indication of a progress > report provided for anything on HEAD that pertains to ZFSv28, have you? > > Furthermore, the FreeBSD Quarterly Status Report just came out on 04/27 > for the months of January-March (almost a 2 month delay, sigh): > > 1737 04/27 10:58 Daniel Gerzo ( 41K) FreeBSD Status Report January-March, 2011 > > http://www.freebsd.org/news/status/report-2011-01-2011-03.html > > Which states that ZFSv28 is "now available in CURRENT", which we've > known for months: > > http://www.freebsd.org/news/status/report-2011-01-2011-03.html#ZFSv28-available-in-FreeBSD-9-CURRENT > > But again, no progress report, so nobody except those who follow > HEAD/CURRENT know what the progress is. And that progress has not been > relayed to any of the non-HEAD/CURRENT lists. > > I'm a total hard-ass about this stuff, and have been for years, because > it all boils down to communication (or lack there-of). It seems very > hasty to say "Yeah! MFC this!" when we (folks who only follow STABLE) > have absolutely no idea if what's in CURRENT is actually broken in some > way or if there are outstanding problems -- and if there are, what those > are so users can be aware of them in advance. > Hello, Here's a summary of my recent end-user work with ZFS on -current. I recently was lucky enough to purchase 2 NAS systems, which consist of 2 cheap new PCs loaded with 6 HD, one is a simple gpt boot device 1x 1tb and 5x 2tb data drives. The mobo has 6 sata connectors but I needed to purchase an additional PCI-E sata adapter since the DVD also uses a sata port. The system has 4gb memory and a new inexpensive quad core AMD CPU. I've been running it (recent -current) for a couple of weeks with heavy single-user use. 2.5tb/7.1tb. The only problem I found, was that deleting a file-backed log device from a degraded pool would immediately panic the system. I'm not running stock -current so I didn't report it. Resilvering seems absurdly slow, but since I won't be doing it much also didn't care. My NAS is side by side redundant, so if resilvering takes more than 2 days I would just replicate off of my other NAS. Throughput without a log device was in the range of 30mb/sec (3% of my 1gb interface). Adding a file-backed log device on a UFS partition that is used for boot, resulted in a 10x jump, saturating the SATA bus that I was sending data from over the network. It spiked up to 30% of interface throughput/max bus speed for disk, and did not vary much. This resolved the issues I saw that a lot of other people have posted about on the internet, about very spiky data transfers. I first used a 40mb/sec throughput USB device as the log device, which showed a dramatic smoothness in data transfer, but still had ~15 seconds where no data would xfer, while it was flushed from USB to disk. After researching I discovered that I could use a file backed log device and this fixed all the problems about spiky data transfers. Before that I had tuned the sysctl's as the poor out of the box settings were giving me very slow speeds (in the range of 1% network throughput, before log device). I played around with the vfs.zfs tunables but found that I did not need to after I added the log device, and the out of the box settings for that sysctl tree were just fine. I had first set this up before CAM was added to -current as default, and did not use labels. Due to troubleshooting some unrelated disk issues, I ended up switching to CAM without problems, and subsequently labeled the disks (recreated the zpool after the labeling). I am now using CAM and AHCI without any issues. Here are some personal notes about the tunables I set, I am sure they are not all helpful. I didn't add them one by one, I simply mass changed them and saw a positive result. Also noted are the commands I used and current system status. sysctl -w net.inet.tcp.sendspace=373760 sysctl -w net.inet.tcp.recvspace=373760 sysctl -w net.local.stream.sendspace=82320 sysctl -w net.local.stream.recvspace=82320 sysctl -w vfs.zfs.prefetch_disable=1 sysctl -w net.local.stream.recvspace=373760 sysctl -w net.local.stream.sendspace=373760 sysctl -w net.local.inflight=1 sysctl -w net.inet.tcp.ecn.enable=1 sysctl -w net.inet.flowtable.enable=0 sysctl -w net.raw.recvspace=373760 sysctl -w net.raw.sendspace=373760 sysctl -w net.inet.tcp.local_slowstart_flightsize=10 sysctl -a net.inet.tcp.delayed_ack=0 sysctl -w kern.maxvnodes=600000 sysctl -w net.local.dgram.recvspace=8192 sysctl -w net.local.dgram.maxdgram=8192 sysctl -w net.inet.tcp.slowstart_flightsize=10 sysctl -w net.inet.tcp.path_mtu_discovery=0 [/var/preserve/root] # glabel label g_ada0 /dev/ada0 [/var/preserve/root] # glabel label g_ada1 /dev/ada1 [/var/preserve/root] # glabel label g_ada3 /dev/ada3 [/var/preserve/root] # glabel label g_ada4 /dev/ada4 [/var/preserve/root] # glabel label g_ada5 /dev/ada5 Labels so that later I will be able to more easily identify disks. My mobo has a single ata bus slave port for SATA. That disk would "disappear" from the box. Moving the drive to a master sata port resolved the issue (? very odd). gnop create -S 4096 /dev/label/g_ada0 mkdir /var/preserve/zfs dd if=/dev/zero of=/var/preserve/zfs/log_device bs=1m count=5000 zpool create -f tank raidz /dev/label/g_ada0.nop /dev/label/g_ada1 /dev/label/g_ada3 /dev/label/g_ada4 /dev/label/g_ada5 log /var/preserve/zfs/log_device The 4 above lines are to set the alignment to 4kb, to create a file backed log device, and create the pool. zfs set atime=off tank I decided not to use dedup, because my files don't have a lot of dup. They're mostly large media files, ISOs etc. [/var/preserve/root] # zpool status pool: tank state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 label/g_ada0 ONLINE 0 0 0 label/g_ada1 ONLINE 0 0 0 label/g_ada3 ONLINE 0 0 0 label/g_ada4 ONLINE 0 0 0 label/g_ada5 ONLINE 0 0 0 logs /var/preserve/zfs/log_device ONLINE 0 0 0 errors: No known data errors [/var/preserve/root] # [/var/preserve/root] # df Filesystem Size Used Avail Capacity Mounted on /dev/gpt/pyros-a 9.7G 3.3G 5.6G 37% / /dev/gpt/pyros-c 884G 6.1G 808G 1% /var tank 7.1T 2.5T 4.6T 35% /tank [/var/preserve/root] # ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich2 bus 0 scbus3 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2 at ahcich3 bus 0 scbus4 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada3 at ahcich4 bus 0 scbus5 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4 at ahcich5 bus 0 scbus6 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5 at ata1 bus 0 scbus8 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: 150.000MB/s transfers (SATA, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) CPU: AMD Phenom(tm) II X4 920 Processor (2800.19-MHz K8-class CPU) ... real memory = 4294967296 (4096 MB) avail memory = 3840598016 (3662 MB) ZFS filesystem version 5 ZFS storage pool version 28 Best practices: Tune the sysctls related to buffer sizes / queue depth. Label your disks before you build the zpool. Use gnop to 4kb align the disks. Only one disk in the pool needs this before you create it. Use CAM. *** USE A LOG DEVICE! *** -Pierre From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 22:07:16 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 ED1061065672; Sat, 30 Apr 2011 22:07:15 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id A3AFE8FC12; Sat, 30 Apr 2011 22:07:15 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1548CE.dip.t-dialin.net [91.21.72.206]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 03ED484400D; Sun, 1 May 2011 00:07:02 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 1C2981192; Sun, 1 May 2011 00:06:59 +0200 (CEST) Date: Sun, 1 May 2011 00:06:56 +0200 From: Alexander Leidinger To: Jeremy Chadwick Message-ID: <20110501000656.00007ea1@unknown> In-Reply-To: <20110430072831.GA65598@icarus.home.lan> References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 03ED484400D.A453A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1304806022.18543@l0QDDI7V3BlTwyvVz6tuBg X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org, Alexander Motin Subject: Re: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 22:07:16 -0000 On Sat, 30 Apr 2011 00:28:31 -0700 Jeremy Chadwick wrote: > On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: > Other notes: TRIM needs to be supported on swap as well, and in my > opinion this is just as important as it being in UFS. I'm not sure > how one would implement that. This brings up the question if a ZFS cache (where the contents do not survive a reboot) is completely TRIMmed before used (and normally trimmed during use)... Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 22:27:29 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 E4333106566B; Sat, 30 Apr 2011 22:27:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B49FB8FC12; Sat, 30 Apr 2011 22:27:29 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p3UMRPmV096016 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 30 Apr 2011 15:27:28 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DBC8D08.7030000@freebsd.org> Date: Sat, 30 Apr 2011 15:28:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Motin References: <20110430072831.GA65598@icarus.home.lan> <4DBBE985.9000701@FreeBSD.org> In-Reply-To: <4DBBE985.9000701@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 22:27:30 -0000 On 4/30/11 3:50 AM, Alexander Motin wrote: > Julian Elischer wrote: >> On 4/30/11 12:28 AM, Jeremy Chadwick wrote: >>> On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: >>>> I've noticed that on file deletion from UFS with TRIM enabled, kernel >>>> issues BIO_DELETE for each 16K (block size?) separately -- thousands per >>>> second for single big file deletion. Fortunately ada driver will try to >>>> aggregate them for the device, but won't some clustering code worth to >>>> be there? >>> I'd like to know who decided it would be best to submit the TRIM command >>> automatically on every single block that is deemed free by UFS during >>> inode removal. The performance hit, from what I've been reading, from >>> doing this is quite severe. Many SSDs take hundreds of milliseconds to >>> complete TRIM operations, which greatly impacts filesystem performance. >>> I appreciate the efforts to get TRIM into FreeBSD for UFS, but the >>> implementation -- if what Alexander says is accurate -- seems like a bad >>> choice. >> well not all devices take it as a hit.. The suggestion of some sort of >> clustering is a good one but it should be tunable. > I believe any device should benefit from receiving single 128K request > instead of 8*16k. Just because of command processing overhead. Am I wrong? well if you never make the 16 k request because you are waiting for the other 112K to show up then I'd prefer the 16k request. I am not sure exactly of exact figures but I would think that about 16k would be a good cluster size for our devices. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 22:34:17 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 CC8A71065670; Sat, 30 Apr 2011 22:34:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 236388FC13; Sat, 30 Apr 2011 22:34:16 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p3UMYCLU056123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 May 2011 01:34:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p3UMYCkk021119; Sun, 1 May 2011 01:34:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p3UMYCx8021118; Sun, 1 May 2011 01:34:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 1 May 2011 01:34:12 +0300 From: Kostik Belousov To: fs@freebsd.org Message-ID: <20110430223412.GS48734@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BT+d3GSIvIc4kUSA" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: rmacklem@freebsd.org Subject: newnfs client and statfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 22:34:17 -0000 --BT+d3GSIvIc4kUSA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I just netbooted fresh GENERIC (with irrelevant local patch) over the pxe, and got the following: # df -h=20 Filesystem Size Used = Avail Capacity Mounted on 192.168.102.110:/usr/home/kostik/build/bsd/DEV/netboot/x -267G 130G = -539G -32% / On the server side, it is up-to-date stable/8 with oldnfs server, export is /dev/ada1p2 1.8T 129G 1.5T 8% /usr/home Do we have some long-typed var lurking in new nfs client code, instead of off_t ? I am almost sure this is nfs problem, since I booted i386 in the same setup month ago, and did not had the compaints from sendmail about low space on spool (which is why I noted this issue now). amd64 kernel (with nfscl loaded as module) correctly reports 192.168.102.110:/usr/home/kostik/build/bsd/DEV/netboot/x 1.8T 129G = 1.5T 8% / --BT+d3GSIvIc4kUSA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk28jmMACgkQC3+MBN1Mb4hZxwCg89/HbS/WU3yskGBVYiUXCHya dvkAoKBBvFuEF9BiCqYUD3MLOHH513OT =PMDF -----END PGP SIGNATURE----- --BT+d3GSIvIc4kUSA-- From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 23:45: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 30EC0106566B for ; Sat, 30 Apr 2011 23:45:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DA8888FC14 for ; Sat, 30 Apr 2011 23:45:53 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAOmdvE2DaFvO/2dsb2JhbACEUaI+iHGrRY9vgSqDVYEBBI55jj4 X-IronPort-AV: E=Sophos;i="4.64,294,1301889600"; d="scan'208";a="120037189" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Apr 2011 19:45:52 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C7EAFB3F37; Sat, 30 Apr 2011 19:45:52 -0400 (EDT) Date: Sat, 30 Apr 2011 19:45:52 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Message-ID: <1591833752.819973.1304207152724.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <86iptvg9uo.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 23:45:54 -0000 > > This comes from mountcritremote: > > case "`mount -d -a -t nfs 2> /dev/null`" in > *mount_nfs*) > # Handle absent nfs client support > load_kld -m nfs nfsclient || return 1 > ;; > esac > > mount(8) will print "mount_oldnfs" instead of "mount_nfs". Note that > until you flipped the switch, the exact same error would occur, in > reverse, on systems running the new stack. > Yep, I spotted that, but haven`t had a chance to reproduce it and test a fix yet. My first attempt at fixing it will be to change the line to: load_kld -m nfs nfscl ... if that works, I`ll see what the rc folks think is the best fix. > > If you could test a pre-switchover (but recent) client and see if > > the > > message shows up, that would be appreciated. > > It does, so it's not something new. > Ok, thanks for testing it, rick