From bugmaster at FreeBSD.org Mon Sep 1 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:07:44 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200809011106.m81B6sR8068415@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o kern/116170 fs [panic] Kernel panic when mounting /tmp o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t 7 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o bin/118249 fs mv(1): moving a directory changes its mtime o kern/124621 fs [ext3] Cannot mount ext2fs partition o kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file 9 problems total. From proace at gmail.com Tue Sep 2 06:33:55 2008 From: proace at gmail.com (ProAce) Date: Tue Sep 2 06:34:08 2008 Subject: how to cache nfs file in local disk Message-ID: <737a6d270809012309w2be16ba3s8937623841107557@mail.gmail.com> The question I posted on freebsd-question last week, maybe I post wrong mailing list. I describe the question here again. :) In order to reduce the throughput and ops for nas server, I just want to cache file from nfs to nfs client's local disk. And the cache system can controller the total size of cache file automatically ( the capacity of nas is more more more larger than local disk ). There are the cachefs on Solaris and FS-Cache on RedHat can cache file from nfs to local disk, does any similar software can be run on FreeBSD? From remko at FreeBSD.org Wed Sep 3 14:00:44 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Wed Sep 3 14:00:50 2008 Subject: i386/127029: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) Message-ID: <200809031400.m83E0isq094339@freefall.freebsd.org> Synopsis: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) Responsible-Changed-From-To: freebsd-i386->freebsd-fs Responsible-Changed-By: remko Responsible-Changed-When: Wed Sep 3 14:00:44 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=127029 From rmacklem at uoguelph.ca Wed Sep 3 14:19:37 2008 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Wed Sep 3 14:19:44 2008 Subject: how to cache nfs file in local disk In-Reply-To: <737a6d270809012309w2be16ba3s8937623841107557@mail.gmail.com> References: <737a6d270809012309w2be16ba3s8937623841107557@mail.gmail.com> Message-ID: On Tue, 2 Sep 2008, ProAce wrote: > The question I posted on freebsd-question last week, maybe I post > wrong mailing list. I describe the question here again. :) > > In order to reduce the throughput and ops for nas server, I just want > to cache file from nfs to nfs client's local disk. > And the cache system can controller the total size of cache file > automatically ( the capacity of nas is more more more larger than > local disk ). > > There are the cachefs on Solaris and FS-Cache on RedHat can cache file > from nfs to local disk, does any similar software can be run on > FreeBSD? Since no one else has answered, I toss out "None that I am aware of". I am planning on doing some work caching files on local disk when they are delegated to the client, but that will be NFSv4 specific and at least next summer before it is available. I also consider it experimental work, so it may never end up usable in a near production environment. To be honest, for LAN environments, ny hunch is that local disk caching will only help if the client keeps accessing the same files over and over again. But that's just a hunch at this point. rick From jh at saunalahti.fi Wed Sep 3 16:25:29 2008 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Wed Sep 3 16:25:40 2008 Subject: birthtime initialization In-Reply-To: <20080725192315.D27178@delplex.bde.org> References: <200806020800.m528038T072838@freefall.freebsd.org> <20080722075718.GA1881@a91-153-120-204.elisa-laajakaista.fi> <20080722215249.K17453@delplex.bde.org> <20080723103424.GA1856@a91-153-120-204.elisa-laajakaista.fi> <20080724000618.Q16961@besplex.bde.org> <20080725072314.GA807@a91-153-120-204.elisa-laajakaista.fi> <20080725192315.D27178@delplex.bde.org> Message-ID: <20080903160736.GA12587@a91-153-122-179.elisa-laajakaista.fi> Hi, I further updated the patch. On 2008-07-25, Bruce Evans wrote: > On Fri, 25 Jul 2008, Jaakko Heinonen wrote: > > On 2008-07-24, Bruce Evans wrote: > >> First, the fields shouldn't be initialized using VATTR_NULL() in > >> VOP_GETATTR(). I removed VATTR_NULL() from xfs, mqueuefs, pseudofs, tmpfs, devfs fdescfs and vattr_null() from devfs and portalfs. I also removed zeroing from nfs. > > What do you think that is a proper default value for va_rdev? Some file > > systems set it to 0 and some to VNOVAL. > > Either NODEV or VNOVAL explicitly translated late to NODEV. I changed following file systems to initialize va_rdev to NODEV instead of 0 or VNOVAL (when appropriate): mqueuefs, tmpfs, portalfs, smbfs, ntfs, fdescfs and msdosfs. Also in vn_stat() va_rdev is now initialized to VNOVAL and explicitly translated to NODEV after the VOP_GETATTR() call. I have tested the patch with these file systems: UFS2, UFS1, ext2fs, ntfs, cd9660, udf, procfs, devfs, xfs, reiserfs, fdescfs, msdosfs, mqueuefs, nfs, smbfs, portalfs. %%% Index: sys/nfsclient/nfs_vnops.c =================================================================== --- sys/nfsclient/nfs_vnops.c (revision 182592) +++ sys/nfsclient/nfs_vnops.c (working copy) @@ -631,6 +631,8 @@ nfs_getattr(struct vop_getattr_args *ap) struct vnode *vp = ap->a_vp; struct nfsnode *np = VTONFS(vp); struct thread *td = curthread; + struct vattr *vap = ap->a_vap; + struct vattr vattr; caddr_t bpos, dpos; int error = 0; struct mbuf *mreq, *mrep, *md, *mb; @@ -646,12 +648,12 @@ nfs_getattr(struct vop_getattr_args *ap) /* * First look in the cache. */ - if (nfs_getattrcache(vp, ap->a_vap) == 0) + if (nfs_getattrcache(vp, &vattr) == 0) goto nfsmout; if (v3 && nfsaccess_cache_timeout > 0) { nfsstats.accesscache_misses++; nfs3_access_otw(vp, NFSV3ACCESS_ALL, td, ap->a_cred); - if (nfs_getattrcache(vp, ap->a_vap) == 0) + if (nfs_getattrcache(vp, &vattr) == 0) goto nfsmout; } nfsstats.rpccnt[NFSPROC_GETATTR]++; @@ -661,10 +663,27 @@ nfs_getattr(struct vop_getattr_args *ap) nfsm_fhtom(vp, v3); nfsm_request(vp, NFSPROC_GETATTR, td, ap->a_cred); if (!error) { - nfsm_loadattr(vp, ap->a_vap); + nfsm_loadattr(vp, &vattr); } m_freem(mrep); nfsmout: + vap->va_type = vattr.va_type; + vap->va_mode = vattr.va_mode; + vap->va_nlink = vattr.va_nlink; + vap->va_uid = vattr.va_uid; + vap->va_gid = vattr.va_gid; + vap->va_fsid = vattr.va_fsid; + vap->va_fileid = vattr.va_fileid; + vap->va_size = vattr.va_size; + vap->va_blocksize = vattr.va_blocksize; + vap->va_atime = vattr.va_atime; + vap->va_mtime = vattr.va_mtime; + vap->va_ctime = vattr.va_ctime; + vap->va_gen = vattr.va_gen; + vap->va_flags = vattr.va_flags; + vap->va_rdev = vattr.va_rdev; + vap->va_bytes = vattr.va_bytes; + return (error); } Index: sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c =================================================================== --- sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c (revision 182592) +++ sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c (working copy) @@ -240,7 +240,6 @@ _xfs_getattr( /* extract the xfs vnode from the private data */ //xfs_vnode_t *xvp = (xfs_vnode_t *)vp->v_data; - VATTR_NULL(vap); memset(&va,0,sizeof(xfs_vattr_t)); va.va_mask = XFS_AT_STAT|XFS_AT_GENCOUNT|XFS_AT_XFLAGS; @@ -273,15 +272,9 @@ _xfs_getattr( /* * Fields with no direct equivalent in XFS - * leave initialized by VATTR_NULL */ -#if 0 vap->va_filerev = 0; - vap->va_birthtime = va.va_ctime; - vap->va_vaflags = 0; vap->va_flags = 0; - vap->va_spare = 0; -#endif return (0); } Index: sys/ufs/ufs/ufs_vnops.c =================================================================== --- sys/ufs/ufs/ufs_vnops.c (revision 182592) +++ sys/ufs/ufs/ufs_vnops.c (working copy) @@ -434,8 +434,6 @@ ufs_getattr(ap) vap->va_mtime.tv_nsec = ip->i_din1->di_mtimensec; vap->va_ctime.tv_sec = ip->i_din1->di_ctime; vap->va_ctime.tv_nsec = ip->i_din1->di_ctimensec; - vap->va_birthtime.tv_sec = 0; - vap->va_birthtime.tv_nsec = 0; vap->va_bytes = dbtob((u_quad_t)ip->i_din1->di_blocks); } else { vap->va_rdev = ip->i_din2->di_rdev; Index: sys/kern/uipc_mqueue.c =================================================================== --- sys/kern/uipc_mqueue.c (revision 182592) +++ sys/kern/uipc_mqueue.c (working copy) @@ -1128,7 +1128,6 @@ mqfs_getattr(struct vop_getattr_args *ap struct vattr *vap = ap->a_vap; int error = 0; - VATTR_NULL(vap); vap->va_type = vp->v_type; vap->va_mode = pn->mn_mode; vap->va_nlink = 1; @@ -1145,7 +1144,7 @@ mqfs_getattr(struct vop_getattr_args *ap vap->va_birthtime = pn->mn_birth; vap->va_gen = 0; vap->va_flags = 0; - vap->va_rdev = 0; + vap->va_rdev = NODEV; vap->va_bytes = 0; vap->va_filerev = 0; vap->va_vaflags = 0; Index: sys/kern/vfs_vnops.c =================================================================== --- sys/kern/vfs_vnops.c (revision 182592) +++ sys/kern/vfs_vnops.c (working copy) @@ -703,6 +703,17 @@ vn_stat(vp, sb, active_cred, file_cred, #endif vap = &vattr; + + /* + * Initialize defaults for new and unusual fields, so that file + * systems which don't support these fields don't need to know + * about them. + */ + vap->va_birthtime.tv_sec = -1; + vap->va_birthtime.tv_nsec = 0; + vap->va_fsid = VNOVAL; + vap->va_rdev = VNOVAL; + error = VOP_GETATTR(vp, vap, active_cred); if (error) return (error); @@ -750,7 +761,10 @@ vn_stat(vp, sb, active_cred, file_cred, sb->st_nlink = vap->va_nlink; sb->st_uid = vap->va_uid; sb->st_gid = vap->va_gid; - sb->st_rdev = vap->va_rdev; + if (vap->va_rdev == VNOVAL) + sb->st_rdev = NODEV; + else + sb->st_rdev = vap->va_rdev; if (vap->va_size > OFF_MAX) return (EOVERFLOW); sb->st_size = vap->va_size; Index: sys/fs/pseudofs/pseudofs_vnops.c =================================================================== --- sys/fs/pseudofs/pseudofs_vnops.c (revision 182592) +++ sys/fs/pseudofs/pseudofs_vnops.c (working copy) @@ -191,7 +191,6 @@ pfs_getattr(struct vop_getattr_args *va) if (!pfs_visible(curthread, pn, pvd->pvd_pid, &proc)) PFS_RETURN (ENOENT); - VATTR_NULL(vap); vap->va_type = vn->v_type; vap->va_fileid = pn_fileno(pn, pvd->pvd_pid); vap->va_flags = 0; Index: sys/fs/tmpfs/tmpfs_vnops.c =================================================================== --- sys/fs/tmpfs/tmpfs_vnops.c (revision 182592) +++ sys/fs/tmpfs/tmpfs_vnops.c (working copy) @@ -351,8 +351,6 @@ tmpfs_getattr(struct vop_getattr_args *v node = VP_TO_TMPFS_NODE(vp); - VATTR_NULL(vap); - tmpfs_update(vp); vap->va_type = vp->v_type; @@ -371,11 +369,9 @@ tmpfs_getattr(struct vop_getattr_args *v vap->va_gen = node->tn_gen; vap->va_flags = node->tn_flags; vap->va_rdev = (vp->v_type == VBLK || vp->v_type == VCHR) ? - node->tn_rdev : VNOVAL; + node->tn_rdev : NODEV; vap->va_bytes = round_page(node->tn_size); - vap->va_filerev = VNOVAL; - vap->va_vaflags = 0; - vap->va_spare = VNOVAL; /* XXX */ + vap->va_filerev = 0; return 0; } Index: sys/fs/portalfs/portal_vnops.c =================================================================== --- sys/fs/portalfs/portal_vnops.c (revision 182592) +++ sys/fs/portalfs/portal_vnops.c (working copy) @@ -452,8 +452,6 @@ portal_getattr(ap) struct vnode *vp = ap->a_vp; struct vattr *vap = ap->a_vap; - bzero(vap, sizeof(*vap)); - vattr_null(vap); vap->va_uid = 0; vap->va_gid = 0; vap->va_size = DEV_BSIZE; @@ -463,7 +461,7 @@ portal_getattr(ap) vap->va_ctime = vap->va_mtime; vap->va_gen = 0; vap->va_flags = 0; - vap->va_rdev = 0; + vap->va_rdev = NODEV; /* vap->va_qbytes = 0; */ vap->va_bytes = 0; /* vap->va_qsize = 0; */ Index: sys/fs/devfs/devfs_vnops.c =================================================================== --- sys/fs/devfs/devfs_vnops.c (revision 182592) +++ sys/fs/devfs/devfs_vnops.c (working copy) @@ -499,8 +499,6 @@ devfs_getattr(struct vop_getattr_args *a KASSERT(de != NULL, ("Null dir dirent in devfs_getattr vp=%p", vp)); } - bzero((caddr_t) vap, sizeof(*vap)); - vattr_null(vap); vap->va_uid = de->de_uid; vap->va_gid = de->de_gid; vap->va_mode = de->de_mode; Index: sys/fs/smbfs/smbfs_node.c =================================================================== --- sys/fs/smbfs/smbfs_node.c (revision 182592) +++ sys/fs/smbfs/smbfs_node.c (working copy) @@ -438,7 +438,7 @@ smbfs_attr_cachelookup(struct vnode *vp, va->va_atime = va->va_ctime = va->va_mtime; /* time file changed */ va->va_gen = VNOVAL; /* generation number of file */ va->va_flags = 0; /* flags defined for file */ - va->va_rdev = VNOVAL; /* device the special file represents */ + va->va_rdev = NODEV; /* device the special file represents */ va->va_bytes = va->va_size; /* bytes of disk space held by file */ va->va_filerev = 0; /* file modification number */ va->va_vaflags = 0; /* operations flags */ Index: sys/fs/ntfs/ntfs_vnops.c =================================================================== --- sys/fs/ntfs/ntfs_vnops.c (revision 182592) +++ sys/fs/ntfs/ntfs_vnops.c (working copy) @@ -191,7 +191,7 @@ ntfs_getattr(ap) vap->va_nlink = (ip->i_nlink || ip->i_flag & IN_LOADED ? ip->i_nlink : 1); vap->va_uid = ip->i_mp->ntm_uid; vap->va_gid = ip->i_mp->ntm_gid; - vap->va_rdev = 0; /* XXX UNODEV ? */ + vap->va_rdev = NODEV; vap->va_size = fp->f_size; vap->va_bytes = fp->f_allocated; vap->va_atime = ntfs_nttimetounix(fp->f_times.t_access); Index: sys/fs/fdescfs/fdesc_vnops.c =================================================================== --- sys/fs/fdescfs/fdesc_vnops.c (revision 182592) +++ sys/fs/fdescfs/fdesc_vnops.c (working copy) @@ -391,8 +391,6 @@ fdesc_getattr(ap) switch (VTOFDESC(vp)->fd_type) { case Froot: - VATTR_NULL(vap); - vap->va_mode = S_IRUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH; vap->va_type = VDIR; vap->va_nlink = 2; @@ -407,7 +405,7 @@ fdesc_getattr(ap) vap->va_ctime = vap->va_mtime; vap->va_gen = 0; vap->va_flags = 0; - vap->va_rdev = 0; + vap->va_rdev = NODEV; vap->va_bytes = 0; break; @@ -421,7 +419,6 @@ fdesc_getattr(ap) error = fo_stat(fp, &stb, td->td_ucred, td); fdrop(fp, td); if (error == 0) { - VATTR_NULL(vap); vap->va_type = IFTOVT(stb.st_mode); vap->va_mode = stb.st_mode; #define FDRX (VREAD|VEXEC) Index: sys/fs/msdosfs/msdosfs_vnops.c =================================================================== --- sys/fs/msdosfs/msdosfs_vnops.c (revision 182592) +++ sys/fs/msdosfs/msdosfs_vnops.c (working copy) @@ -334,7 +334,7 @@ msdosfs_getattr(ap) vap->va_uid = pmp->pm_uid; vap->va_gid = pmp->pm_gid; vap->va_nlink = 1; - vap->va_rdev = 0; + vap->va_rdev = NODEV; vap->va_size = dep->de_FileSize; fattime2timespec(dep->de_MDate, dep->de_MTime, 0, 0, &vap->va_mtime); vap->va_ctime = vap->va_mtime; %%% -- Jaakko From josh.carroll at gmail.com Wed Sep 3 18:30:05 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Wed Sep 3 18:30:11 2008 Subject: kern/124621: [ext3] Cannot mount ext2fs partition Message-ID: <200809031830.m83IU4OK030982@freefall.freebsd.org> The following reply was made to PR kern/124621; it has been noted by GNATS. From: "Josh Carroll" To: bug-followup@FreeBSD.org, paulf@free.fr Cc: Subject: Re: kern/124621: [ext3] Cannot mount ext2fs partition Date: Wed, 3 Sep 2008 14:28:58 -0400 Here is a simple patch that queries the inode size, rather than assuming 128. This may be a rather naive way to do this (querying it every time from (s)->s_es->s_inode_size), but it does seem to work. Perhaps there is a smarter way of doing this (setting something at mount time?). I tested this with mke2fs -I 128, mke2fs (defaults to -I 256 with the latest e2fsprogs port), and -I 512. Thanks, Josh diff -ud ext2fs.orig/ext2_fs.h ext2fs/ext2_fs.h --- ext2fs.orig/ext2_fs.h 2005-06-16 06:51:38.000000000 +0000 +++ ext2fs/ext2_fs.h 2008-09-03 14:10:27.000000000 +0000 @@ -150,7 +150,7 @@ #else /* !notyet */ #define EXT2_INODES_PER_BLOCK(s) ((s)->s_inodes_per_block) /* Should be sizeof(struct ext2_inode): */ -#define EXT2_INODE_SIZE 128 +#define EXT2_INODE_SIZE(s) ((s)->s_es->s_inode_size) #define EXT2_FIRST_INO 11 #endif /* notyet */ diff -ud ext2fs.orig/ext2_inode.c ext2fs/ext2_inode.c --- ext2fs.orig/ext2_inode.c 2006-09-26 04:15:58.000000000 +0000 +++ ext2fs/ext2_inode.c 2008-09-03 13:54:49.000000000 +0000 @@ -91,7 +91,7 @@ return (error); } ext2_i2ei(ip, (struct ext2_inode *)((char *)bp->b_data + - EXT2_INODE_SIZE * ino_to_fsbo(fs, ip->i_number))); + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip->i_number))); if (waitfor && (vp->v_mount->mnt_kern_flag & MNTK_ASYNC) == 0) return (bwrite(bp)); else { diff -ud ext2fs.orig/ext2_vfsops.c ext2fs/ext2_vfsops.c --- ext2fs.orig/ext2_vfsops.c 2008-04-03 18:51:13.000000000 +0000 +++ ext2fs/ext2_vfsops.c 2008-09-03 13:55:37.000000000 +0000 @@ -424,7 +424,7 @@ V(s_frags_per_group) fs->s_inodes_per_group = es->s_inodes_per_group; V(s_inodes_per_group) - fs->s_inodes_per_block = fs->s_blocksize / EXT2_INODE_SIZE; + fs->s_inodes_per_block = fs->s_blocksize / EXT2_INODE_SIZE(fs); V(s_inodes_per_block) fs->s_itb_per_group = fs->s_inodes_per_group /fs->s_inodes_per_block; V(s_itb_per_group) @@ -578,7 +578,7 @@ return (error); } ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + - EXT2_INODE_SIZE * ino_to_fsbo(fs, ip->i_number)), ip); + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip->i_number)), ip); brelse(bp); VOP_UNLOCK(vp, 0, td); vrele(vp); @@ -1013,7 +1013,7 @@ return (error); } /* convert ext2 inode to dinode */ - ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + EXT2_INODE_SIZE * + ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ino)), ip); ip->i_block_group = ino_to_cg(fs, ino); ip->i_next_alloc_block = 0; From rwatson at FreeBSD.org Wed Sep 3 23:11:13 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Sep 3 23:11:19 2008 Subject: how to cache nfs file in local disk In-Reply-To: References: <737a6d270809012309w2be16ba3s8937623841107557@mail.gmail.com> Message-ID: On Wed, 3 Sep 2008, Rick Macklem wrote: > On Tue, 2 Sep 2008, ProAce wrote: > >> The question I posted on freebsd-question last week, maybe I post wrong >> mailing list. I describe the question here again. :) >> >> In order to reduce the throughput and ops for nas server, I just want to >> cache file from nfs to nfs client's local disk. And the cache system can >> controller the total size of cache file automatically ( the capacity of nas >> is more more more larger than local disk ). >> >> There are the cachefs on Solaris and FS-Cache on RedHat can cache file from >> nfs to local disk, does any similar software can be run on FreeBSD? > > Since no one else has answered, I toss out "None that I am aware of". > > I am planning on doing some work caching files on local disk when they are > delegated to the client, but that will be NFSv4 specific and at least next > summer before it is available. I also consider it experimental work, so it > may never end up usable in a near production environment. > > To be honest, for LAN environments, ny hunch is that local disk caching will > only help if the client keeps accessing the same files over and over again. > But that's just a hunch at this point. The AFS argument may be relevant here: persistent client-side caching is as much about indirectly improving client performance through greater server scalability as about directly improving client performance through local disk I/O speed. Robert N M Watson Computer Laboratory University of Cambridge From proace at gmail.com Thu Sep 4 01:34:25 2008 From: proace at gmail.com (ProAce) Date: Thu Sep 4 01:34:32 2008 Subject: how to cache nfs file in local disk In-Reply-To: References: <737a6d270809012309w2be16ba3s8937623841107557@mail.gmail.com> Message-ID: <737a6d270809031834v54bab15bwb535b126cd36f38e@mail.gmail.com> > > 2008/9/3, Rick Macklem : > > > Since no one else has answered, I toss out "None that I am aware of". > > I am planning on doing some work caching files on local disk when they > are delegated to the client, but that will be NFSv4 specific and at least > next summer before it is available. I also consider it experimental work, > so it may never end up usable in a near production environment. > > To be honest, for LAN environments, ny hunch is that local disk caching > will only help if the client keeps accessing the same files over and over > again. But that's just a hunch at this point. > > rick > > Bingo! Currently, the bigest problem for me is client access some files over and over again. From proace at gmail.com Thu Sep 4 02:04:30 2008 From: proace at gmail.com (ProAce) Date: Thu Sep 4 02:04:38 2008 Subject: how to cache nfs file in local disk In-Reply-To: References: <737a6d270809012309w2be16ba3s8937623841107557@mail.gmail.com> Message-ID: <737a6d270809031904u31963f7au752e6fadae4536c3@mail.gmail.com> > > 2008/9/4, Robert Watson : > > The AFS argument may be relevant here: persistent client-side caching is as > much about indirectly improving client performance through greater server > scalability as about directly improving client performance through local > disk I/O speed. > > Robert N M Watson > Computer Laboratory > University of Cambridge > But change fs from nfs to afs maybe more complex, and need more evaluations for the production environment. If my cognition for AFS is wrong, could you give me more hints? :) From rwatson at FreeBSD.org Thu Sep 4 07:22:54 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Sep 4 07:23:12 2008 Subject: how to cache nfs file in local disk In-Reply-To: <737a6d270809031904u31963f7au752e6fadae4536c3@mail.gmail.com> References: <737a6d270809012309w2be16ba3s8937623841107557@mail.gmail.com> <737a6d270809031904u31963f7au752e6fadae4536c3@mail.gmail.com> Message-ID: On Thu, 4 Sep 2008, ProAce wrote: >> 2008/9/4, Robert Watson : >> >> The AFS argument may be relevant here: persistent client-side caching is as >> much about indirectly improving client performance through greater server >> scalability as about directly improving client performance through local >> disk I/O speed. > > But change fs from nfs to afs maybe more complex, and need more evaluations > for the production environment. > > If my cognition for AFS is wrong, could you give me more hints? :) Right, this is not an argument that you should switch to AFS, rather, an argument that the design approach of persistent client-side caching first adopted in AFS isn't just about raw bandwidth or latency to the client, but about improving the ability of the server to scale to large numbers of clients. All that said, I'm really pleased that Arla is working much beter on FreeBSD lately, and that significant work has gone into an OpenAFS port for 7.x and 8.x. Robert N M Watson Computer Laboratory University of Cambridge From josh.carroll at gmail.com Thu Sep 4 17:20:04 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Thu Sep 4 17:20:10 2008 Subject: kern/124621: [ext3] Cannot mount ext2fs partition Message-ID: <200809041720.m84HK3nw031379@freefall.freebsd.org> The following reply was made to PR kern/124621; it has been noted by GNATS. From: "Josh Carroll" To: bug-followup@FreeBSD.org, paulf@free.fr Cc: Subject: Re: kern/124621: [ext3] Cannot mount ext2fs partition Date: Thu, 4 Sep 2008 13:16:55 -0400 ------=_Part_61122_6937983.1220548615546 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, it appears the previous patch was munged by gmail. I'm trying it as an attachment this time. I apologize in advance if this attempt is also munged. Josh ------=_Part_61122_6937983.1220548615546 Content-Type: application/octet-stream; name=ext2fs.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_fkpn4bhq0 Content-Disposition: attachment; filename=ext2fs.diff ZGlmZiAtdWQgZXh0MmZzLm9yaWcvZXh0Ml9mcy5oIGV4dDJmcy9leHQyX2ZzLmgKLS0tIGV4dDJm cy5vcmlnL2V4dDJfZnMuaAkyMDA1LTA2LTE2IDA2OjUxOjM4LjAwMDAwMDAwMCArMDAwMAorKysg ZXh0MmZzL2V4dDJfZnMuaAkyMDA4LTA5LTAzIDE0OjEwOjI3LjAwMDAwMDAwMCArMDAwMApAQCAt MTUwLDcgKzE1MCw3IEBACiAjZWxzZSAvKiAhbm90eWV0ICovCiAjZGVmaW5lCUVYVDJfSU5PREVT X1BFUl9CTE9DSyhzKQkoKHMpLT5zX2lub2Rlc19wZXJfYmxvY2spCiAvKiBTaG91bGQgYmUgc2l6 ZW9mKHN0cnVjdCBleHQyX2lub2RlKTogKi8KLSNkZWZpbmUgRVhUMl9JTk9ERV9TSVpFCQkJMTI4 CisjZGVmaW5lIEVYVDJfSU5PREVfU0laRShzKQkJKChzKS0+c19lcy0+c19pbm9kZV9zaXplKQog I2RlZmluZSBFWFQyX0ZJUlNUX0lOTwkJCTExCiAjZW5kaWYgLyogbm90eWV0ICovCiAKZGlmZiAt dWQgZXh0MmZzLm9yaWcvZXh0Ml9pbm9kZS5jIGV4dDJmcy9leHQyX2lub2RlLmMKLS0tIGV4dDJm cy5vcmlnL2V4dDJfaW5vZGUuYwkyMDA2LTA5LTI2IDA0OjE1OjU4LjAwMDAwMDAwMCArMDAwMAor KysgZXh0MmZzL2V4dDJfaW5vZGUuYwkyMDA4LTA5LTAzIDEzOjU0OjQ5LjAwMDAwMDAwMCArMDAw MApAQCAtOTEsNyArOTEsNyBAQAogCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJZXh0Ml9pMmVpKGlw LCAoc3RydWN0IGV4dDJfaW5vZGUgKikoKGNoYXIgKilicC0+Yl9kYXRhICsKLQkgICAgRVhUMl9J Tk9ERV9TSVpFICogaW5vX3RvX2ZzYm8oZnMsIGlwLT5pX251bWJlcikpKTsKKwkgICAgRVhUMl9J Tk9ERV9TSVpFKGZzKSAqIGlub190b19mc2JvKGZzLCBpcC0+aV9udW1iZXIpKSk7CiAJaWYgKHdh aXRmb3IgJiYgKHZwLT52X21vdW50LT5tbnRfa2Vybl9mbGFnICYgTU5US19BU1lOQykgPT0gMCkK IAkJcmV0dXJuIChid3JpdGUoYnApKTsKIAllbHNlIHsKZGlmZiAtdWQgZXh0MmZzLm9yaWcvZXh0 Ml92ZnNvcHMuYyBleHQyZnMvZXh0Ml92ZnNvcHMuYwotLS0gZXh0MmZzLm9yaWcvZXh0Ml92ZnNv cHMuYwkyMDA4LTA0LTAzIDE4OjUxOjEzLjAwMDAwMDAwMCArMDAwMAorKysgZXh0MmZzL2V4dDJf dmZzb3BzLmMJMjAwOC0wOS0wMyAxMzo1NTozNy4wMDAwMDAwMDAgKzAwMDAKQEAgLTQyNCw3ICs0 MjQsNyBAQAogICAgIFYoc19mcmFnc19wZXJfZ3JvdXApCiAgICAgZnMtPnNfaW5vZGVzX3Blcl9n cm91cCA9IGVzLT5zX2lub2Rlc19wZXJfZ3JvdXA7CiAgICAgVihzX2lub2Rlc19wZXJfZ3JvdXAp Ci0gICAgZnMtPnNfaW5vZGVzX3Blcl9ibG9jayA9IGZzLT5zX2Jsb2Nrc2l6ZSAvIEVYVDJfSU5P REVfU0laRTsKKyAgICBmcy0+c19pbm9kZXNfcGVyX2Jsb2NrID0gZnMtPnNfYmxvY2tzaXplIC8g RVhUMl9JTk9ERV9TSVpFKGZzKTsKICAgICBWKHNfaW5vZGVzX3Blcl9ibG9jaykKICAgICBmcy0+ c19pdGJfcGVyX2dyb3VwID0gZnMtPnNfaW5vZGVzX3Blcl9ncm91cCAvZnMtPnNfaW5vZGVzX3Bl cl9ibG9jazsKICAgICBWKHNfaXRiX3Blcl9ncm91cCkKQEAgLTU3OCw3ICs1NzgsNyBAQAogCQkJ cmV0dXJuIChlcnJvcik7CiAJCX0KIAkJZXh0Ml9laTJpKChzdHJ1Y3QgZXh0Ml9pbm9kZSAqKSAo KGNoYXIgKilicC0+Yl9kYXRhICsKLQkJICAgIEVYVDJfSU5PREVfU0laRSAqIGlub190b19mc2Jv KGZzLCBpcC0+aV9udW1iZXIpKSwgaXApOworCQkgICAgRVhUMl9JTk9ERV9TSVpFKGZzKSAqIGlu b190b19mc2JvKGZzLCBpcC0+aV9udW1iZXIpKSwgaXApOwogCQlicmVsc2UoYnApOwogCQlWT1Bf VU5MT0NLKHZwLCAwLCB0ZCk7CiAJCXZyZWxlKHZwKTsKQEAgLTEwMTMsNyArMTAxMyw3IEBACiAJ CXJldHVybiAoZXJyb3IpOwogCX0KIAkvKiBjb252ZXJ0IGV4dDIgaW5vZGUgdG8gZGlub2RlICov Ci0JZXh0Ml9laTJpKChzdHJ1Y3QgZXh0Ml9pbm9kZSAqKSAoKGNoYXIgKilicC0+Yl9kYXRhICsg RVhUMl9JTk9ERV9TSVpFICoKKwlleHQyX2VpMmkoKHN0cnVjdCBleHQyX2lub2RlICopICgoY2hh ciAqKWJwLT5iX2RhdGEgKyBFWFQyX0lOT0RFX1NJWkUoZnMpICoKIAkJCWlub190b19mc2JvKGZz LCBpbm8pKSwgaXApOwogCWlwLT5pX2Jsb2NrX2dyb3VwID0gaW5vX3RvX2NnKGZzLCBpbm8pOwog CWlwLT5pX25leHRfYWxsb2NfYmxvY2sgPSAwOwo= ------=_Part_61122_6937983.1220548615546-- From josh.carroll at gmail.com Thu Sep 4 17:50:05 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Thu Sep 4 17:50:17 2008 Subject: kern/124621: [ext3] Cannot mount ext2fs partition Message-ID: <200809041750.m84Ho5Af034359@freefall.freebsd.org> The following reply was made to PR kern/124621; it has been noted by GNATS. From: "Josh Carroll" To: bug-followup@FreeBSD.org, paulf@free.fr Cc: Subject: Re: kern/124621: [ext3] Cannot mount ext2fs partition Date: Thu, 4 Sep 2008 13:42:36 -0400 Sigh. Apologies again. Let's try it this way. Here is the patch: http://pflog.net/~floyd/ext2fs.diff Thanks, Josh From wxs at FreeBSD.org Thu Sep 4 17:50:08 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Thu Sep 4 17:50:18 2008 Subject: kern/124621: [ext3] Cannot mount ext2fs partition Message-ID: <200809041750.m84Ho74B034375@freefall.freebsd.org> The following reply was made to PR kern/124621; it has been noted by GNATS. From: Wesley Shields To: bug-followup@FreeBSD.org Cc: josh.carroll@gmail.com Subject: Re: kern/124621: [ext3] Cannot mount ext2fs partition Date: Thu, 4 Sep 2008 13:50:07 -0400 From reading of the release notes it looks like this change was made in January 2008. http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.10 I tested the patch that is online from Josh and it works. Is anyone willing to step up and commit this? Seems like a simple enough fix and will start to hit more and more people as updated versions of e2fsprogs becomes more common. Thanks, Josh, for providing a fix for this. -- WXS From marck at rinet.ru Sun Sep 7 15:09:00 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Sep 7 15:09:07 2008 Subject: ZFS filesystem: export for more than one subnet Message-ID: Dear colleagues, is there any way so one can export ZFS file system to more than one net? in classic NFS I would use more than one line in /etc/exports -- how can I express such behaviour in zfs properties? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From koitsu at FreeBSD.org Sun Sep 7 22:17:07 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 7 22:17:13 2008 Subject: ZFS filesystem: export for more than one subnet In-Reply-To: References: Message-ID: <20080907220104.GA26094@icarus.home.lan> On Sun, Sep 07, 2008 at 06:39:11PM +0400, Dmitry Morozovsky wrote: > Dear colleagues, > > is there any way so one can export ZFS file system to more than one net? > > in classic NFS I would use more than one line in /etc/exports -- how can I > express such behaviour in zfs properties? Didn't you inadvertently ask this same question 6 months ago? :-) http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084079.html I believe if 'sharenfs=off' (the default), you can manage NFS mounts via /etc/exports like normal. Ideally, you should (?) be able to use multiple "-network xxx/netmask" entries on the same export line. If you absolutely must do it via the 'zfs' command, according to pjd@'s EuroBSDCon presentation, this should work: # /etc/rc.d/mountd start # zfs set sharenfs="ro,network=x.x.x.x,mask=y.y.y.y" some_fs # /etc/rc.d/mountd reload /etc/rc.d/mountd is already configured to read /etc/exports and /etc/zfs/exports, so all you should have to do is mountd_enable="yes" in rc.conf. You can also use CIDR syntax in network=xx/yy, which should decrease the line length. pjd@'s paper is here -- see page 18, "NFS is easy": http://2007.eurobsdcon.org/presentations/Pawel_Jakub_Dawidek/eurobsdcon07_zfs.pdf However, I'd advocate you consider running pf on the machine running mountd instead, and use an actual firewall to block who can talk to mountd on the machine exporting the shares. -- | Jeremy Chadwick jdc at 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 marck at rinet.ru Sun Sep 7 22:43:06 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Sep 7 22:43:13 2008 Subject: ZFS filesystem: export for more than one subnet In-Reply-To: <20080907220104.GA26094@icarus.home.lan> References: <20080907220104.GA26094@icarus.home.lan> Message-ID: On Sun, 7 Sep 2008, Jeremy Chadwick wrote: JC> > is there any way so one can export ZFS file system to more than one net? JC> > JC> > in classic NFS I would use more than one line in /etc/exports -- how can I JC> > express such behaviour in zfs properties? JC> JC> Didn't you inadvertently ask this same question 6 months ago? :-) JC> JC> http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084079.html Well, not exactly - that time I did not bump into different destination problem ;) JC> I believe if 'sharenfs=off' (the default), you can manage NFS mounts via JC> /etc/exports like normal. Ideally, you should (?) be able to use JC> multiple "-network xxx/netmask" entries on the same export line. Hmm, that would do the trick; however, it seems to me that ZFS file system properties should be producet from the single source. JC> If you absolutely must do it via the 'zfs' command, according to pjd@'s JC> EuroBSDCon presentation, this should work: JC> JC> # /etc/rc.d/mountd start JC> # zfs set sharenfs="ro,network=x.x.x.x,mask=y.y.y.y" some_fs JC> # /etc/rc.d/mountd reload Well, this configures only one network per file system, isn't it? BTW, mountd will be reloaded by zfs automagically (and, as Kris bumps ito it, it would create a problem with race hole of inaccessible NFS mounts while mountd reloads the list) JC> However, I'd advocate you consider running pf on the machine running JC> mountd instead, and use an actual firewall to block who can talk to JC> mountd on the machine exporting the shares. I would prefer to do both ;) Oh, and hosts.allow possibly too... Or, would it be too inefficient? Thanks! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From koitsu at FreeBSD.org Sun Sep 7 23:36:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 7 23:36:47 2008 Subject: ZFS filesystem: export for more than one subnet In-Reply-To: References: <20080907220104.GA26094@icarus.home.lan> Message-ID: <20080907233637.GA51889@icarus.home.lan> On Mon, Sep 08, 2008 at 02:43:03AM +0400, Dmitry Morozovsky wrote: > On Sun, 7 Sep 2008, Jeremy Chadwick wrote: > > JC> > is there any way so one can export ZFS file system to more than one net? > JC> > > JC> > in classic NFS I would use more than one line in /etc/exports -- how can I > JC> > express such behaviour in zfs properties? > JC> > JC> Didn't you inadvertently ask this same question 6 months ago? :-) > JC> > JC> http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084079.html > > Well, not exactly - that time I did not bump into different destination problem > ;) > > JC> I believe if 'sharenfs=off' (the default), you can manage NFS mounts via > JC> /etc/exports like normal. Ideally, you should (?) be able to use > JC> multiple "-network xxx/netmask" entries on the same export line. > > Hmm, that would do the trick; however, it seems to me that ZFS file system > properties should be producet from the single source. I interpret this to mean "there should be only one export(5) file used". That would be something to take up with pjd@, but I'm willing to bet that behaviour is not going to change. There is probably a good reason why /etc/zfs/exports exists. That said, what happens if you edit /etc/zfs/exports by hand, then run "zfs list -o sharenfs"? Does it show the changes you put in place? If so, then great -- it means there's two ways a person can edit the NFS-exported ZFS shares (by editing the file directly, or using "zfs"). > JC> If you absolutely must do it via the 'zfs' command, according to pjd@'s > JC> EuroBSDCon presentation, this should work: > JC> > JC> # /etc/rc.d/mountd start > JC> # zfs set sharenfs="ro,network=x.x.x.x,mask=y.y.y.y" some_fs > JC> # /etc/rc.d/mountd reload > > Well, this configures only one network per file system, isn't it? BTW, mountd > will be reloaded by zfs automagically (and, as Kris bumps ito it, it would > create a problem with race hole of inaccessible NFS mounts while mountd reloads > the list) Does the below work? # zfs set sharenfs="ro,network=aaa/xx,network=bbb/yy,network=ccc/zz" some_fs If not (e.g. mountd rejects it, or only the first network is used), then this would indicate a problem with the exports file syntax / problem with mountd, and not with ZFS. Solaris solves all of this, AFAIK, by having a central command that manages the export list: share(1). "zfs" on Solaris even calls this. BSD does not have this utility. > JC> However, I'd advocate you consider running pf on the machine running > JC> mountd instead, and use an actual firewall to block who can talk to > JC> mountd on the machine exporting the shares. > > I would prefer to do both ;) Oh, and hosts.allow possibly too... Or, would it > be too inefficient? There is absolutely no reason to do both. Packets arriving on the network will hit the pf stack before ever reaching mountd, which is perfect, and a good security model. Additionally, libwrap (hosts.allow/deny) is a travesty, and should be nuked from the face of the planet. It provides a false sense of security -- it doesn't stop someone (anyone!) from being able to actually connect to that TCP port (or in the case of UDP, I believe a deny/rejection will actually send back a packet of some kind), which means people will then know you've got (rpcbind|mountd|ftpd|whatever) running, which gives an attacker/hacker significant hints about what your system is running, and more ammunition. -- | Jeremy Chadwick jdc at 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 bugmaster at FreeBSD.org Mon Sep 8 02:22:20 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:22:59 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200809080222.m882MJUL006662@freefall.freebsd.org> The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/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/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/124621 fs [ext3] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp 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 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D 17 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From marck at rinet.ru Mon Sep 8 07:21:50 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Mon Sep 8 07:21:57 2008 Subject: ZFS filesystem: export for more than one subnet In-Reply-To: <20080907233637.GA51889@icarus.home.lan> References: <20080907220104.GA26094@icarus.home.lan> <20080907233637.GA51889@icarus.home.lan> Message-ID: On Sun, 7 Sep 2008, Jeremy Chadwick wrote: JC> That said, what happens if you edit /etc/zfs/exports by hand, then run JC> "zfs list -o sharenfs"? Does it show the changes you put in place? If JC> so, then great -- it means there's two ways a person can edit the JC> NFS-exported ZFS shares (by editing the file directly, or using "zfs"). Nope, ZFS does not track /etc/zfs/export, hence "Do not edit!" comment in it. JC> Does the below work? JC> JC> # zfs set sharenfs="ro,network=aaa/xx,network=bbb/yy,network=ccc/zz" some_fs JC> JC> If not (e.g. mountd rejects it, or only the first network is used), then JC> this would indicate a problem with the exports file syntax / problem JC> with mountd, and not with ZFS. It is of course FreeBSD' mountd problem (more than it does not understand CIDR slashed notation): marck@beaver:~# cat /etc/zfs/exports # !!! DO NOT EDIT THIS FILE MANUALLY !!! /FreeBSD -ro -alldirs -network 195.54.192.0 -mask 255.255.255.192 255.255.255.192 marck@beaver:~# zfs get sharenfs bv/FreeBSD NAME PROPERTY VALUE SOURCE bv/FreeBSD sharenfs -ro -alldirs -network 195.54.192.0 -mask 255.255.255.192 local marck@beaver:~# zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,192.168.39.0/24" bv/FreeBSD marck@beaver:~# zfs get sharenfs bv/FreeBSD NAME PROPERTY VALUE SOURCE bv/FreeBSD sharenfs ro,alldirs,network=195.54.192.0/26,192.168.39.0/24 local Sep 8 11:18:18 beaver mountd[25992]: can't get address info for host 192.168.39.0/24 Sep 8 11:18:18 beaver mountd[25992]: bad host 192.168.39.0/24, skipping Sep 8 11:18:18 beaver mountd[25992]: network/host conflict Sep 8 11:18:18 beaver mountd[25992]: bad exports list line /FreeBSD -ro -alldirs -network JC> > I would prefer to do both ;) Oh, and hosts.allow possibly too... Or, would it JC> > be too inefficient? JC> JC> There is absolutely no reason to do both. Packets arriving on the JC> network will hit the pf stack before ever reaching mountd, which is JC> perfect, and a good security model. JC> JC> Additionally, libwrap (hosts.allow/deny) is a travesty, and should be JC> nuked from the face of the planet. It provides a false sense of JC> security -- it doesn't stop someone (anyone!) from being able to JC> actually connect to that TCP port (or in the case of UDP, I believe a JC> deny/rejection will actually send back a packet of some kind), which JC> means people will then know you've got (rpcbind|mountd|ftpd|whatever) JC> running, which gives an attacker/hacker significant hints about what JC> your system is running, and more ammunition. Well, all there actually make sense. Thanks, I'll think about it a little bit more. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From koitsu at FreeBSD.org Mon Sep 8 09:10:54 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 09:11:01 2008 Subject: ZFS filesystem: export for more than one subnet In-Reply-To: References: <20080907220104.GA26094@icarus.home.lan> <20080907233637.GA51889@icarus.home.lan> Message-ID: <20080908091052.GA63182@icarus.home.lan> On Mon, Sep 08, 2008 at 11:21:48AM +0400, Dmitry Morozovsky wrote: > On Sun, 7 Sep 2008, Jeremy Chadwick wrote: > JC> That said, what happens if you edit /etc/zfs/exports by hand, then run > JC> "zfs list -o sharenfs"? Does it show the changes you put in place? If > JC> so, then great -- it means there's two ways a person can edit the > JC> NFS-exported ZFS shares (by editing the file directly, or using "zfs"). > > Nope, ZFS does not track /etc/zfs/export, hence "Do not edit!" comment in it. Understood. Then using "zfs" is the only option. > JC> If not (e.g. mountd rejects it, or only the first network is used), then > JC> this would indicate a problem with the exports file syntax / problem > JC> with mountd, and not with ZFS. > > It is of course FreeBSD' mountd problem (more than it does not understand CIDR > slashed notation): > > marck@beaver:~# cat /etc/zfs/exports > # !!! DO NOT EDIT THIS FILE MANUALLY !!! > > /FreeBSD -ro -alldirs -network 195.54.192.0 -mask 255.255.255.192 > 255.255.255.192 > marck@beaver:~# zfs get sharenfs bv/FreeBSD > NAME PROPERTY VALUE SOURCE > bv/FreeBSD sharenfs -ro -alldirs -network 195.54.192.0 -mask 255.255.255.192 local > marck@beaver:~# zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,192.168.39.0/24" bv/FreeBSD > marck@beaver:~# zfs get sharenfs bv/FreeBSD > NAME PROPERTY VALUE SOURCE > bv/FreeBSD sharenfs ro,alldirs,network=195.54.192.0/26,192.168.39.0/24 local > > Sep 8 11:18:18 beaver mountd[25992]: can't get address info for host 192.168.39.0/24 > Sep 8 11:18:18 beaver mountd[25992]: bad host 192.168.39.0/24, skipping > Sep 8 11:18:18 beaver mountd[25992]: network/host conflict > Sep 8 11:18:18 beaver mountd[25992]: bad exports list line /FreeBSD -ro -alldirs -network It does support CIDR, and the output mountd gave you even shows that it does (look closely at what "bad host" it's giving you -- that isn't the first host in the exports list!). You changed the syntax of what I gave you as an example. Look closely: # zfs set sharenfs="ro,network=aaa/xx,network=bbb/yy,network=ccc/zz" some_fs Here's what you typed in: # zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,192.168.39.0/24" bv/FreeBSD -- | Jeremy Chadwick jdc at 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 marck at rinet.ru Mon Sep 8 09:26:32 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Mon Sep 8 09:26:38 2008 Subject: ZFS filesystem: export for more than one subnet In-Reply-To: <20080908091052.GA63182@icarus.home.lan> References: <20080907220104.GA26094@icarus.home.lan> <20080907233637.GA51889@icarus.home.lan> <20080908091052.GA63182@icarus.home.lan> Message-ID: On Mon, 8 Sep 2008, Jeremy Chadwick wrote: [snip] JC> It does support CIDR, and the output mountd gave you even shows that JC> it does (look closely at what "bad host" it's giving you -- that isn't JC> the first host in the exports list!). Yes, I already catched it; see below. JC> You changed the syntax of what I gave you as an example. Look closely: JC> JC> # zfs set sharenfs="ro,network=aaa/xx,network=bbb/yy,network=ccc/zz" some_fs JC> JC> Here's what you typed in: JC> JC> # zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,192.168.39.0/24" bv/FreeBSD Anyway, it does not work, alas: marck@beaver:~# zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,network=192.168.39.0/24" bv/FreeBSD marck@beaver:~# tail /var/log/daemon Sep 8 13:22:11 beaver mountd[25992]: network/host conflict Sep 8 13:22:11 beaver mountd[25992]: bad exports list line /FreeBSD -ro -alldirs -network marck@beaver:~# cat /etc/zfs/exports # !!! DO NOT EDIT THIS FILE MANUALLY !!! /FreeBSD -ro -alldirs -network=195.54.192.0/26 -network=192.168.39.0/24 What I' m trying to express is that there would be need to export the same file system to different address blocks *with different options* - -such as rw/ro, and/or maproot/mapall. I'm starting to think we should either mimic such functionality from OpenSolaris or invent it. Thank you for cooperation! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From koitsu at FreeBSD.org Mon Sep 8 09:36:49 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 09:36:56 2008 Subject: ZFS filesystem: export for more than one subnet In-Reply-To: References: <20080907220104.GA26094@icarus.home.lan> <20080907233637.GA51889@icarus.home.lan> <20080908091052.GA63182@icarus.home.lan> Message-ID: <20080908093646.GA63681@icarus.home.lan> On Mon, Sep 08, 2008 at 01:26:30PM +0400, Dmitry Morozovsky wrote: > On Mon, 8 Sep 2008, Jeremy Chadwick wrote: > JC> You changed the syntax of what I gave you as an example. Look closely: > JC> > JC> # zfs set sharenfs="ro,network=aaa/xx,network=bbb/yy,network=ccc/zz" some_fs > JC> > JC> Here's what you typed in: > JC> > JC> # zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,192.168.39.0/24" bv/FreeBSD > > Anyway, it does not work, alas: > > marck@beaver:~# zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,network=192.168.39.0/24" bv/FreeBSD > marck@beaver:~# tail /var/log/daemon > Sep 8 13:22:11 beaver mountd[25992]: network/host conflict > Sep 8 13:22:11 beaver mountd[25992]: bad exports list line /FreeBSD -ro -alldirs -network > marck@beaver:~# cat /etc/zfs/exports > # !!! DO NOT EDIT THIS FILE MANUALLY !!! > > /FreeBSD -ro -alldirs -network=195.54.192.0/26 -network=192.168.39.0/24 Doh! Bummer. :-( > What I' m trying to express is that there would be need to export the same file > system to different address blocks *with different options* - -such as rw/ro, > and/or maproot/mapall. Correct me if I'm wrong: you want an equivalent of the below to actually work (speaking strictly from an /etc/exports perspective): /FreeBSD -ro -alldirs -network=192.168.1.0/24 /FreeBSD -rw -alldirs -network=192.168.100.0/24 /FreeBSD -ro -alldirs -network=10.0.0.0/8 Is this right? If so, I can imagine addressing/fixing this will be complex. > I'm starting to think we should either mimic such functionality from > OpenSolaris or invent it. I agree. A centralised command like share(1) would be sufficient for what's needed; in concept, something like pw(8) for NFS shares. -- | Jeremy Chadwick jdc at 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 linimon at FreeBSD.org Mon Sep 8 22:26:42 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 8 22:26:49 2008 Subject: kern/127213: [tmpfs] sendfile on tmpfs data corruption Message-ID: <200809082226.m88MQesR053782@freefall.freebsd.org> Old Synopsis: sendfile on tmpfs data corruption New Synopsis: [tmpfs] sendfile on tmpfs data corruption Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 8 22:26:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127213 From brde at optusnet.com.au Tue Sep 9 18:46:14 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Tue Sep 9 18:46:21 2008 Subject: birthtime initialization In-Reply-To: <20080903160736.GA12587@a91-153-122-179.elisa-laajakaista.fi> References: <200806020800.m528038T072838@freefall.freebsd.org> <20080722075718.GA1881@a91-153-120-204.elisa-laajakaista.fi> <20080722215249.K17453@delplex.bde.org> <20080723103424.GA1856@a91-153-120-204.elisa-laajakaista.fi> <20080724000618.Q16961@besplex.bde.org> <20080725072314.GA807@a91-153-120-204.elisa-laajakaista.fi> <20080725192315.D27178@delplex.bde.org> <20080903160736.GA12587@a91-153-122-179.elisa-laajakaista.fi> Message-ID: <20080909204354.Q3089@besplex.bde.org> On Wed, 3 Sep 2008, Jaakko Heinonen wrote: > I further updated the patch. > > On 2008-07-25, Bruce Evans wrote: >> On Fri, 25 Jul 2008, Jaakko Heinonen wrote: >>> On 2008-07-24, Bruce Evans wrote: >>>> First, the fields shouldn't be initialized using VATTR_NULL() in >>>> VOP_GETATTR(). > > I removed VATTR_NULL() from xfs, mqueuefs, pseudofs, tmpfs, devfs > fdescfs and vattr_null() from devfs and portalfs. I also removed zeroing > from nfs. > >>> What do you think that is a proper default value for va_rdev? Some file >>> systems set it to 0 and some to VNOVAL. >> >> Either NODEV or VNOVAL explicitly translated late to NODEV. > > I changed following file systems to initialize va_rdev to NODEV instead > of 0 or VNOVAL (when appropriate): mqueuefs, tmpfs, portalfs, smbfs, > ntfs, fdescfs and msdosfs. Also in vn_stat() va_rdev is now initialized > to VNOVAL and explicitly translated to NODEV after the VOP_GETATTR() > call. > > I have tested the patch with these file systems: UFS2, UFS1, ext2fs, > ntfs, cd9660, udf, procfs, devfs, xfs, reiserfs, fdescfs, msdosfs, > mqueuefs, nfs, smbfs, portalfs. I like this version, but didn't check many details. > Index: sys/kern/vfs_vnops.c > =================================================================== > --- sys/kern/vfs_vnops.c (revision 182592) > +++ sys/kern/vfs_vnops.c (working copy) > @@ -703,6 +703,17 @@ vn_stat(vp, sb, active_cred, file_cred, > #endif > > vap = &vattr; > + > + /* > + * Initialize defaults for new and unusual fields, so that file > + * systems which don't support these fields don't need to know > + * about them. > + */ > + vap->va_birthtime.tv_sec = -1; > + vap->va_birthtime.tv_nsec = 0; > + vap->va_fsid = VNOVAL; > + vap->va_rdev = VNOVAL; Shouldn't this be NODEV? NODEV is ((dev_t)-1) and VNOVAL is plain (-1), so their values are identical after assignment to va_rdev... > + > error = VOP_GETATTR(vp, vap, active_cred); > if (error) > return (error); > @@ -750,7 +761,10 @@ vn_stat(vp, sb, active_cred, file_cred, > sb->st_nlink = vap->va_nlink; > sb->st_uid = vap->va_uid; > sb->st_gid = vap->va_gid; > - sb->st_rdev = vap->va_rdev; > + if (vap->va_rdev == VNOVAL) > + sb->st_rdev = NODEV; > + else > + sb->st_rdev = vap->va_rdev; ... this change seems to have no effect on machines with 32-bit 2's complement ints and to be wrong on other machines. Assignment of VNOVAL to va_rdev changes its value from -1 to 0xFFFFFFFFU, so it can only compare equal to VNOVAL if int has the same size as dev_t or there is stronger magic. When the comparision is fixed to compare with the assigned value (dev_t)VNOVAL == (dev_t)(-1) == NODEV, it is clear that the change has no effect. Bruce From delphij at delphij.net Thu Sep 11 00:05:46 2008 From: delphij at delphij.net (Xin LI) Date: Thu Sep 11 00:05:53 2008 Subject: Documentation on VM/VFS? Message-ID: <48C860CD.4030507@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I think I get confused with some concepts, is there any place that I can find some (either brief overview or in-depth) documentation about VM/VFS, especially the caching mechanism? Specifically, e.g. is it possible to skip the VM/VFS cache, and hand a page directly to the cache subsystem which is already in main memory? Some surrounding information would be useful as well. Thanks in advance! Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjIYM0ACgkQi+vbBBjt66AQQACgj2C5u0rxJzIqrdH8dfGQfhTb c6sAn0dAPw2abFfIr7o9slPj56lEi0nK =J9ZU -----END PGP SIGNATURE----- From jh at saunalahti.fi Thu Sep 11 14:03:54 2008 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Thu Sep 11 14:04:00 2008 Subject: birthtime initialization In-Reply-To: <20080909204354.Q3089@besplex.bde.org> References: <200806020800.m528038T072838@freefall.freebsd.org> <20080722075718.GA1881@a91-153-120-204.elisa-laajakaista.fi> <20080722215249.K17453@delplex.bde.org> <20080723103424.GA1856@a91-153-120-204.elisa-laajakaista.fi> <20080724000618.Q16961@besplex.bde.org> <20080725072314.GA807@a91-153-120-204.elisa-laajakaista.fi> <20080725192315.D27178@delplex.bde.org> <20080903160736.GA12587@a91-153-122-179.elisa-laajakaista.fi> <20080909204354.Q3089@besplex.bde.org> Message-ID: <20080911140349.GA2221@a91-153-122-179.elisa-laajakaista.fi> On 2008-09-09, Bruce Evans wrote: > > @@ -703,6 +703,17 @@ vn_stat(vp, sb, active_cred, file_cred, > > + vap->va_rdev = VNOVAL; > > Shouldn't this be NODEV? NODEV is ((dev_t)-1) and VNOVAL is plain (-1), > so their values are identical after assignment to va_rdev... Yes, it's probably better to use NODEV here... > > - sb->st_rdev = vap->va_rdev; > > + if (vap->va_rdev == VNOVAL) > > + sb->st_rdev = NODEV; > > + else > > + sb->st_rdev = vap->va_rdev; ...and leave out this change. > ... this change seems to have no effect on machines with 32-bit 2's complement > ints and to be wrong on other machines. Assignment of VNOVAL to va_rdev > changes its value from -1 to 0xFFFFFFFFU, so it can only compare equal > to VNOVAL if int has the same size as dev_t or there is stronger magic. > When the comparision is fixed to compare with the assigned value > (dev_t)VNOVAL == (dev_t)(-1) == NODEV, it is clear that the change has > no effect. Some file systems seem to have vap->va_rdev != VNOVAL comparisons in VOP_SETATTR(). Thanks. -- Jaakko From ed at 80386.nl Fri Sep 12 18:27:24 2008 From: ed at 80386.nl (Ed Schouten) Date: Fri Sep 12 18:27:36 2008 Subject: Expanding vops in vop_vectors during startup Message-ID: <20080912182722.GK1191@hoeg.nl> Hello everyone, Yesterday I was talking with some friends of mine about the FreeBSD VFS layer. As an exercise, Jille was trying to patch nullfs to hide .svn directories (see hackers@), so that's how we got to the subject. After talking about the way our vop_vector works (vop_bypass and vop_default), we were wondering why we don't propagate all pointers in the vop_vector to its children to save the unneeded function pointer resolving inside the VOP_* calls. I've created a patch that adds a new routine to the kernel, vop_vector_init(), which recursively expands the vops. A new macro (DECLARE_VOP_VECTOR) is used to automatically perform this when loading modules/booting. There is no need to reference default_vnodeops anymore, because it is now used implicitly (when vop_vector == NULL). Any comments on the attached patch? I've only tested it with ufs, nullfs, devfs, etc. yet. I haven't tested `make universe' yet, but I suspect it shouldn't break hard. URL: http://80386.nl/files/vnode-vop-expand.diff Thanks! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080912/13515822/attachment.pgp From bugmaster at FreeBSD.org Mon Sep 15 15:18:47 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:19:42 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200809151518.m8FFIlDh018867@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption 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/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/124621 fs [ext3] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp 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 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D 18 problems total. From ahnjoan at gmail.com Mon Sep 15 23:53:41 2008 From: ahnjoan at gmail.com (Ahnjoan Amous) Date: Mon Sep 15 23:53:48 2008 Subject: host hangs, can only drop to ddb after accessing a file that is owned by a non privileged user Message-ID: <5e575c8a0809151621t55810568wd16fde9b501997f2@mail.gmail.com> A week or so ago we had a power bump and since then one of our servers now hangs on access to one of two files. Just `ls -al` will cause the machine to hang. The files are excel spreadsheets owned by a normal user and served out by samba. The host does not panic when the files are accessed but the only thing I can do is break in to ddb on the serial console. Once inside of ddb I'm able to see which of the two files was being accessed by typing in "show lockedvnods" and using the inode to identify the file via the find command. I'm not able to remove the files either as this causes the host to hang in the same manner. I really don't know anything about ddb other than how to type in "show lockedvnods" so far. I can reproduce this behavior every time if anyone would like me to trouble shoot this possible bug. One thing to note this is a 5.2.1-Release so if it is even a bug it might be fixed already. Most importantly does anyone have any thoughts on how I can remove this file? Its accessible by my users and even with a preemptive e-mail they seem to take delight in clicking the little icon twice and watching me run down the hall... FYI ? Here is the ddb output from two different hangings, the inodes correspond to the two files that make this happen. 0xcc880410: tag ufs, type VREG, usecount 1, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc9b58dc0 ino 3933646, on dev da2s1e (4, 29) 0xca42d71c: tag ufs, type VREG, usecount 1, writecount 0, refcount 1, lock type ufs: EXCL (count 1) by thread 0xca23da00 ino 3933648, on dev da2s1e (4, 29) Thanks Ahnjoan From olli at lurza.secnetix.de Tue Sep 16 09:19:32 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Sep 16 09:19:38 2008 Subject: host hangs, ?can only drop to ddb after accessing a file that is owned by a non ?privileged user In-Reply-To: <5e575c8a0809151621t55810568wd16fde9b501997f2@mail.gmail.com> Message-ID: <200809160919.m8G9JTC7021476@lurza.secnetix.de> Ahnjoan Amous wrote: > A week or so ago we had a power bump and since then one of our servers > now hangs on access to one of two files. Just `ls -al` will cause the > machine to hang. The files are excel spreadsheets owned by a normal > user and served out by samba. The host does not panic when the files > are accessed but the only thing I can do is break in to ddb on the > serial console. > > Once inside of ddb I'm able to see which of the two files was being > accessed by typing in "show lockedvnods" and using the inode to > identify the file via the find command. I'm not able to remove the > files either as this causes the host to hang in the same manner. > > I really don't know anything about ddb other than how to type in "show > lockedvnods" so far. I can reproduce this behavior every time if > anyone would like me to trouble shoot this possible bug. One thing to > note this is a 5.2.1-Release so if it is even a bug it might be fixed > already. > > Most importantly does anyone have any thoughts on how I can remove > this file? Its accessible by my users and even with a preemptive > e-mail they seem to take delight in clicking the little icon twice and > watching me run down the hall... First and most importantly, I assume you have good backups. Unmount the file system, use clri(8) to zero out the broken inodes, then run fsck(8) to clean up, then mount the file system and restore the lost files from your backup. Finally, update your FreeBSD version, because 5.x is EoL and not supported anymore. In particular, you don't get security fixes for it anymore. If your users take delight in causing harm to your server, they could certainly do more serious things than just cause it to crash. By the way, if clri(8) or fsck(8) hang, too, or if the problem persists afterwards, chances are that the disk hardware is broken and should be replaced. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From marck at rinet.ru Tue Sep 16 20:57:16 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Tue Sep 16 20:57:23 2008 Subject: gpt in-place editing Message-ID: Dear colleagues, is there a way to split existing GPT partition into two, like one can do in bsdlabel case? I found myself wanting to shrink swap to have an alternate root, but have no luck in my experiments. For the reference, I have da0p1 boot da0p2 bootdisk da0p3 swap da0p4 ZFS and want to place two partitions in place of da0p3... Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From linimon at FreeBSD.org Wed Sep 17 15:16:20 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 17 15:16:31 2008 Subject: kern/127420: [gjournal] [panic] Journal overflow on gmirrored gjournal Message-ID: <200809171516.m8HFGJJf088817@freefall.freebsd.org> Synopsis: [gjournal] [panic] Journal overflow on gmirrored gjournal Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 17 15:16:09 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127420 From softsearch at gmail.com Wed Sep 17 17:15:46 2008 From: softsearch at gmail.com (Michael Monashev) Date: Wed Sep 17 17:15:52 2008 Subject: gmirror performance patch Message-ID: <946072909.20080917204322@gmail.com> Hi, Pawel. Patch for improve gmirror performance: http://www.freebsd.org/cgi/query-pr.cgi?pr=113885 -- Michael From andrew at modulus.org Sat Sep 20 09:31:17 2008 From: andrew at modulus.org (Andrew Snow) Date: Sat Sep 20 09:31:22 2008 Subject: zfs benchmarks and 7 disk raidz oddity Message-ID: <48D4C2AA.8080000@modulus.org> Hi all, I am running 8-CURRENT with ZFS patches on a 3ghz Core2Duo with Intel P45 chipset. I took some benchmarks of ZFS on six old SATA disks and one PATA, onboard controllers only, and I expect you are interested to see the results. The disks range in size from 200gb to 320gb. I tried several configurations with quick and dirty testing. Listed below is the sequential megabytes/sec rating as measured by dd bs=1m for a 10GB file. All ZFS settings were left at their defaults. Conf Write Read (MB/s) ------------------------------------ 7 disk RAIDZ2 220 305 7 disk RAIDZ1 84 361 7 disk striped 318 409 7 disk stripe copies=2 140 164 6 disk RAIDZ2 173 260 6 disk RAIDZ1 238 307 6 disk striped 280 346 6 disk 2xRAIDZ1 striped 188 251 6 disk striped mirrors 164 323 6 disk stripe copies=2 151 179 A few notes: 1. using copies=2 is a nice way to be able to get RAID1-like mirroring reliability but on an odd number of disks. However you take a noticeable performance penalty: Write speed is fine but read speed is almost half of what RAID0+1 achieved. 2. RAIDZ1 and RAIDZ2 are fast and efficient. However in total it caused the system to use almost all of one CPU core during writing. 3. There seemed to be a bug with 7 disks and RAIDZ1 - the write performance was terrible! When I ran "gstat" I noticed it was spending much time writing to only two disks most of the time, which became a serious bottleneck - the worst write score of the lot. Read was fine. Perhaps the algorithm isn't optimised for choosing parity locations out of exactly 7 disks? - Andrew From softsearch at gmail.com Sat Sep 20 09:53:26 2008 From: softsearch at gmail.com (Michael Monashev) Date: Sat Sep 20 09:53:31 2008 Subject: gmirror performance patch In-Reply-To: <946072909.20080917204322@gmail.com> References: <946072909.20080917204322@gmail.com> Message-ID: <1441440775.20080920135308@gmail.com> Hi. MM> Patch for improve gmirror performance: MM> http://www.freebsd.org/cgi/query-pr.cgi?pr=113885 before: >gstat -I5s dT: 5.384s w: 5.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 12 118 117 1372 349.0 1 12 383.6 100.0| ad4 4 117 116 1349 297.5 1 12 30.7 99.8| ad6 38 131 130 1323 459.9 1 9 415.0 100.0| ad8 62 126 125 1418 534.5 1 9 291.9 98.9| ad10 34 131 129 1403 639.0 2 128 783.4 100.1| ad12 47 131 129 1525 747.4 2 128 1044.4 100.1| ad14 after patch: >gstat -I5s dT: 5.001s w: 5.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 40 93 92 1072 101.4 1 54 20.7 79.3| ad4 8 114 113 1645 285.0 1 54 87.7 95.8| ad6 6 52 45 451 23.8 7 312 19.0 44.3| ad8 85 143 136 1753 1428.8 7 312 556.6 100.2| ad10 28 91 91 707 217.0 0 0 0.1 79.1| ad12 100 129 128 1488 894.8 0 0 956.9 100.0| ad14 >gstat -I5s dT: 5.001s w: 5.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 10 84 83 1239 86.1 1 10 123.1 65.6| ad4 34 121 120 1698 254.2 1 10 215.8 97.3| ad6 50 132 132 1841 481.3 0 0 0.0 99.9| ad8 0 63 63 685 46.3 0 0 0.0 57.0| ad10 70 131 131 2124 532.5 0 0 166.7 100.0| ad12 0 92 91 893 69.1 1 0 49.6 80.4| ad14 -- Michael From yalur at mail.ru Sat Sep 20 18:53:17 2008 From: yalur at mail.ru (Ruslan Kovtun) Date: Sat Sep 20 21:27:45 2008 Subject: zfs benchmarks and 7 disk raidz oddity In-Reply-To: <48D4C2AA.8080000@modulus.org> References: <48D4C2AA.8080000@modulus.org> Message-ID: <200809202135.20730.yalur@mail.ru> Hi. Thank you very much, very useful information. It is interesting when we can use this on 7.x? ? ????????? ?? ??????? 20 ???????? 2008 Andrew Snow ???????(a): > Hi all, > > I am running 8-CURRENT with ZFS patches on a 3ghz Core2Duo with Intel > P45 chipset. I took some benchmarks of ZFS on six old SATA disks and > one PATA, onboard controllers only, and I expect you are interested to > see the results. The disks range in size from 200gb to 320gb. > > I tried several configurations with quick and dirty testing. Listed > below is the sequential megabytes/sec rating as measured by dd bs=1m for > a 10GB file. All ZFS settings were left at their defaults. > > > Conf Write Read (MB/s) > ------------------------------------ > 7 disk RAIDZ2 220 305 > 7 disk RAIDZ1 84 361 > 7 disk striped 318 409 > 7 disk stripe copies=2 140 164 > > 6 disk RAIDZ2 173 260 > 6 disk RAIDZ1 238 307 > 6 disk striped 280 346 > 6 disk 2xRAIDZ1 striped 188 251 > 6 disk striped mirrors 164 323 > 6 disk stripe copies=2 151 179 > > > A few notes: > > 1. using copies=2 is a nice way to be able to get RAID1-like mirroring > reliability but on an odd number of disks. However you take a > noticeable performance penalty: Write speed is fine but read speed is > almost half of what RAID0+1 achieved. > > 2. RAIDZ1 and RAIDZ2 are fast and efficient. However in total it caused > the system to use almost all of one CPU core during writing. > > 3. There seemed to be a bug with 7 disks and RAIDZ1 - the write > performance was terrible! When I ran "gstat" I noticed it was spending > much time writing to only two disks most of the time, which became a > serious bottleneck - the worst write score of the lot. Read was fine. > Perhaps the algorithm isn't optimised for choosing parity locations out > of exactly 7 disks? > > > > - Andrew > > _______________________________________________ > 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" -- ________________ Ruslan Kovtun mailto: yalur@mail.ru mob: +380503557878, +380919015095 ICQ: 277696182 From stas at FreeBSD.org Sun Sep 21 10:25:49 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sun Sep 21 10:25:54 2008 Subject: gpt in-place editing In-Reply-To: References: Message-ID: <20080921140932.adf51b5e.stas@FreeBSD.org> On Wed, 17 Sep 2008 00:57:14 +0400 (MSD) Dmitry Morozovsky mentioned: > Dear colleagues, > > is there a way to split existing GPT partition into two, like one can do in > bsdlabel case? > > I found myself wanting to shrink swap to have an alternate root, but have no > luck in my experiments. > > For the reference, I have > > da0p1 boot > da0p2 bootdisk > da0p3 swap > da0p4 ZFS > > and want to place two partitions in place of da0p3... > You can simpy remove the da0p3 partition and add two new instead of it. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080921/8923d000/attachment.pgp From bugmaster at FreeBSD.org Mon Sep 22 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:07:12 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200809221106.m8MB6qY4015355@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption 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/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/124621 fs [ext3] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp 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 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D 19 problems total. From marck at rinet.ru Mon Sep 22 18:12:57 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Mon Sep 22 18:13:00 2008 Subject: gpt in-place editing In-Reply-To: <20080921140932.adf51b5e.stas@FreeBSD.org> References: <20080921140932.adf51b5e.stas@FreeBSD.org> Message-ID: On Sun, 21 Sep 2008, Stanislav Sedov wrote: SS> > is there a way to split existing GPT partition into two, like one can do in SS> > bsdlabel case? SS> > SS> > I found myself wanting to shrink swap to have an alternate root, but have no SS> > luck in my experiments. SS> > SS> > For the reference, I have SS> > SS> > da0p1 boot SS> > da0p2 bootdisk SS> > da0p3 swap SS> > da0p4 ZFS SS> > SS> > and want to place two partitions in place of da0p3... SS> SS> You can simpy remove the da0p3 partition and add two new instead of it. It does not seem gpart wants allow me to delete da0p3 while disk is active... gpt did the trick though, with sysctl kern.geom.debugflags=16 root@beaver:/# gpt remove -i 3 da0 da0p3 removed root@beaver:/# gpt show da0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 1048576 2 GPT part - FreeBSD UFS/UFS2 1048738 33554432 34603170 4359862077 4 GPT part - FreeBSD ZFS 4394465247 32 Sec GPT table 4394465279 1 Sec GPT header root@beaver:/# gpt add -s 1048576 -t ufs da0 root@beaver:/# gpt show da0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 1048576 2 GPT part - FreeBSD UFS/UFS2 1048738 1048576 3 GPT part - FreeBSD UFS/UFS2 2097314 32505856 34603170 4359862077 4 GPT part - FreeBSD ZFS 4394465247 32 Sec GPT table 4394465279 1 Sec GPT header root@beaver:/# gpt add -t swap da0 BUT - system missed part 5: root@beaver:/# gpt show da0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 1048576 2 GPT part - FreeBSD UFS/UFS2 1048738 1048576 3 GPT part - FreeBSD UFS/UFS2 2097314 32505856 5 GPT part - FreeBSD swap 34603170 4359862077 4 GPT part - FreeBSD ZFS 4394465247 32 Sec GPT table 4394465279 1 Sec GPT header root@beaver:/# gpart show => 34 4394465213 da0 GPT (2.2TB) 34 128 1 freebsd-boot (65.5KB) 162 1048576 2 freebsd-ufs (536.9MB) 1048738 33554432 3 freebsd-swap (17.2GB) 34603170 4359862077 4 freebsd-zfs (2.2TB) root@beaver:/# ls /dev/da0* /dev/da0 /dev/da0p1 /dev/da0p2 /dev/da0p3 /dev/da0p4 Marcel, can you please comment too? Thanks. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From marck at rinet.ru Mon Sep 22 18:17:31 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Mon Sep 22 18:17:33 2008 Subject: gpt in-place editing In-Reply-To: References: <20080921140932.adf51b5e.stas@FreeBSD.org> Message-ID: On Mon, 22 Sep 2008, Dmitry Morozovsky wrote: [snip] DM> BUT - DM> DM> system missed part 5: DM> DM> root@beaver:/# gpt show da0 DM> start size index contents DM> 0 1 PMBR DM> 1 1 Pri GPT header DM> 2 32 Pri GPT table DM> 34 128 1 GPT part - FreeBSD boot DM> 162 1048576 2 GPT part - FreeBSD UFS/UFS2 DM> 1048738 1048576 3 GPT part - FreeBSD UFS/UFS2 DM> 2097314 32505856 5 GPT part - FreeBSD swap DM> 34603170 4359862077 4 GPT part - FreeBSD ZFS DM> 4394465247 32 Sec GPT table DM> 4394465279 1 Sec GPT header DM> root@beaver:/# gpart show DM> => 34 4394465213 da0 GPT (2.2TB) DM> 34 128 1 freebsd-boot (65.5KB) DM> 162 1048576 2 freebsd-ufs (536.9MB) DM> 1048738 33554432 3 freebsd-swap (17.2GB) DM> 34603170 4359862077 4 freebsd-zfs (2.2TB) DM> DM> root@beaver:/# ls /dev/da0* DM> /dev/da0 /dev/da0p1 /dev/da0p2 /dev/da0p3 /dev/da0p4 Small followup: Reboot does fix the problem, surely: marck@beaver:~> gpt -r show da0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 1048576 2 GPT part - FreeBSD UFS/UFS2 1048738 1048576 3 GPT part - FreeBSD UFS/UFS2 2097314 32505856 5 GPT part - FreeBSD swap 34603170 4359862077 4 GPT part - FreeBSD ZFS 4394465247 32 Sec GPT table 4394465279 1 Sec GPT header marck@beaver:~> gpart show => 34 4394465213 da0 GPT (2.2TB) 34 128 1 freebsd-boot (65.5KB) 162 1048576 2 freebsd-ufs (536.9MB) 1048738 1048576 3 freebsd-ufs (536.9MB) 2097314 32505856 5 freebsd-swap (16.6GB) 34603170 4359862077 4 freebsd-zfs (2.2TB) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From xcllnt at mac.com Mon Sep 22 21:23:49 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Sep 22 21:23:56 2008 Subject: gpt in-place editing In-Reply-To: References: <20080921140932.adf51b5e.stas@FreeBSD.org> Message-ID: <10719B6B-1F3B-44C6-BAC0-D8C3F42F7F3F@mac.com> On Sep 22, 2008, at 11:12 AM, Dmitry Morozovsky wrote: > On Sun, 21 Sep 2008, Stanislav Sedov wrote: > > SS> > is there a way to split existing GPT partition into two, like > one can do in > SS> > bsdlabel case? > SS> > > SS> > I found myself wanting to shrink swap to have an alternate > root, but have no > SS> > luck in my experiments. > SS> > > SS> > For the reference, I have > SS> > > SS> > da0p1 boot > SS> > da0p2 bootdisk > SS> > da0p3 swap > SS> > da0p4 ZFS > SS> > > SS> > and want to place two partitions in place of da0p3... > SS> > SS> You can simpy remove the da0p3 partition and add two new instead > of it. > > It does not seem gpart wants allow me to delete da0p3 while disk is > active... You probably have swapon and/or dumpon to set to the partition. You can't remove a partition that is in use. Run "swapoff /dev/da0p3" and/or "dumpon off" first. FYI, -- Marcel Moolenaar xcllnt@mac.com From marck at rinet.ru Mon Sep 22 21:34:59 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Mon Sep 22 21:35:01 2008 Subject: gpt in-place editing In-Reply-To: <10719B6B-1F3B-44C6-BAC0-D8C3F42F7F3F@mac.com> References: <20080921140932.adf51b5e.stas@FreeBSD.org> <10719B6B-1F3B-44C6-BAC0-D8C3F42F7F3F@mac.com> Message-ID: On Mon, 22 Sep 2008, Marcel Moolenaar wrote: MM> > SS> > is there a way to split existing GPT partition into two, like one MM> > can do in MM> > SS> > bsdlabel case? MM> > SS> > MM> > SS> > I found myself wanting to shrink swap to have an alternate root, but MM> > have no MM> > SS> > luck in my experiments. MM> > SS> > MM> > SS> > For the reference, I have MM> > SS> > MM> > SS> > da0p1 boot MM> > SS> > da0p2 bootdisk MM> > SS> > da0p3 swap MM> > SS> > da0p4 ZFS MM> > SS> > MM> > SS> > and want to place two partitions in place of da0p3... MM> > SS> MM> > SS> You can simpy remove the da0p3 partition and add two new instead of MM> > it. MM> > MM> > It does not seem gpart wants allow me to delete da0p3 while disk is MM> > active... MM> MM> You probably have swapon and/or dumpon to set to the partition. MM> You can't remove a partition that is in use. MM> MM> Run "swapoff /dev/da0p3" and/or "dumpon off" first. Of course I did run swapoff; I'm not sure I did dumpoff, and unfortunately I did not run it under script(1). gpt (I did test under RELENG_7) does the trick, but -- However, we clearly have at least one bug: not creating da* device (for da0p5 in my case) Thanks. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From stas at FreeBSD.org Mon Sep 22 21:49:41 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Mon Sep 22 21:49:43 2008 Subject: gpt in-place editing In-Reply-To: References: <20080921140932.adf51b5e.stas@FreeBSD.org> <10719B6B-1F3B-44C6-BAC0-D8C3F42F7F3F@mac.com> Message-ID: <20080923014927.b9e9dc37.stas@FreeBSD.org> On Tue, 23 Sep 2008 01:34:56 +0400 (MSD) Dmitry Morozovsky mentioned: > > However, we clearly have at least one bug: not creating da* device (for da0p5 > in my case) > I believe that's why it was replaced by gpart, which does all required geom tricks right. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080922/20308733/attachment.pgp From xcllnt at mac.com Mon Sep 22 22:04:46 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Sep 22 22:04:48 2008 Subject: gpt in-place editing In-Reply-To: References: <20080921140932.adf51b5e.stas@FreeBSD.org> <10719B6B-1F3B-44C6-BAC0-D8C3F42F7F3F@mac.com> Message-ID: <10218E29-D89D-40BB-BACF-9DFB131974E7@mac.com> On Sep 22, 2008, at 2:34 PM, Dmitry Morozovsky wrote: > MM> > It does not seem gpart wants allow me to delete da0p3 while > disk is > MM> > active... > MM> > MM> You probably have swapon and/or dumpon to set to the partition. > MM> You can't remove a partition that is in use. > MM> > MM> Run "swapoff /dev/da0p3" and/or "dumpon off" first. > > Of course I did run swapoff; I'm not sure I did dumpoff, and > unfortunately I > did not run it under script(1). gpt (I did test under RELENG_7) does > the trick, > but -- > > However, we clearly have at least one bug: not creating da* device > (for da0p5 > in my case) You can't make that claim. You've forced the issue by setting debugflags and bypassing gpart. As such, gpart is unaware of the new partition (it wasn't involved in the creation) and it isn't being made aware, because the underlying geom isn't spoiled (which would trigger a retaste). -- Marcel Moolenaar xcllnt@mac.com From ruben at verweg.com Tue Sep 23 09:40:05 2008 From: ruben at verweg.com (Ruben van Staveren) Date: Tue Sep 23 09:40:07 2008 Subject: kern/127420: [gjournal] [panic] Journal overflow on gmirrored gjournal Message-ID: <200809230940.m8N9e4P2012877@freefall.freebsd.org> The following reply was made to PR kern/127420; it has been noted by GNATS. From: Ruben van Staveren To: bug-followup@FreeBSD.org, ruben@verweg.com Cc: Subject: Re: kern/127420: [gjournal] [panic] Journal overflow on gmirrored gjournal Date: Tue, 23 Sep 2008 11:29:59 +0200 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-41--958136030 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I managed to trigger a new panic, still not able to get a proper dump but this is a capture from the serial console. I was running a couple of bonnie++'s before to "exercise" the system. At the time of the panic one bonnie and one nanobsd build was running. I had enabled geom mirror and journal debug sysctl's Some minutes before the actual panic there was a complaint made by fsync, and gjournal not being able to suspend a filesystem. http://ruben.is.verweg.com/stuff/gjournal-panic/gjournal-textdump-text-only.txt Regards, Ruben --Apple-Mail-41--958136030 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFI2LcXZ88+mcQxRw0RAkkyAJ9VD9cCfWfPusPWCM8sawG/WnVtHQCfXOV8 5Ipf+qF7c1I4JgOPRCHp8rs= =Mm/k -----END PGP SIGNATURE----- --Apple-Mail-41--958136030-- From dreamer.two at gmail.com Wed Sep 24 13:51:04 2008 From: dreamer.two at gmail.com (Vitaly Dodonov) Date: Wed Sep 24 13:51:07 2008 Subject: zfs and gpt partition Message-ID: <911337bf0809240630s1b8a3f15y3c224bd82c59306b@mail.gmail.com> I have problem with zfs on gpt partition in RELENG_7 when zfs use whole drive or classic slices, all work well in any ata port, but changing device name with created on it gpt -t zfs partition broke zfs volume state - FAULTED ad8 UNAVAIL 0 0 0 corrupted data restore possible only with returning drive to it original port, where volume was created From mcdouga9 at egr.msu.edu Wed Sep 24 14:39:13 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Wed Sep 24 14:39:16 2008 Subject: zfs and gpt partition In-Reply-To: <911337bf0809240630s1b8a3f15y3c224bd82c59306b@mail.gmail.com> References: <911337bf0809240630s1b8a3f15y3c224bd82c59306b@mail.gmail.com> Message-ID: <48DA4CB0.4020401@egr.msu.edu> Vitaly Dodonov wrote: > I have problem with zfs on gpt partition in RELENG_7 > > when zfs use whole drive or classic slices, all work well in any ata port, > but changing device name with created on it gpt -t zfs partition broke zfs > volume > state - FAULTED > ad8 UNAVAIL 0 0 0 corrupted data > > restore possible only with returning drive to it original port, where volume > was created > _______________________________________________ > 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" > > Please try looking at 'zpool export' and 'zpool import', it will probably correct the error if you export then import the pool. From dreamer.two at gmail.com Wed Sep 24 15:08:15 2008 From: dreamer.two at gmail.com (Vitaly Dodonov) Date: Wed Sep 24 15:08:17 2008 Subject: zfs and gpt partition In-Reply-To: <48DA4CB0.4020401@egr.msu.edu> References: <911337bf0809240630s1b8a3f15y3c224bd82c59306b@mail.gmail.com> <48DA4CB0.4020401@egr.msu.edu> Message-ID: <911337bf0809240808p69197a62qc5865634bc1a27dd@mail.gmail.com> On Wed, Sep 24, 2008 at 6:20 PM, Adam McDougall wrote: > Vitaly Dodonov wrote: > >> I have problem with zfs on gpt partition in RELENG_7 >> >> when zfs use whole drive or classic slices, all work well in any ata port, >> but changing device name with created on it gpt -t zfs partition broke zfs >> volume >> state - FAULTED >> ad8 UNAVAIL 0 0 0 corrupted data >> >> restore possible only with returning drive to it original port, where >> volume >> was created >> >> >> > Please try looking at 'zpool export' and 'zpool import', it will probably > correct the error if you export then import the pool. > yes, export/import working, but without gpt i don't need these operations, drives don't drop from pool on device name change From marck at rinet.ru Wed Sep 24 19:25:25 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Sep 24 19:25:28 2008 Subject: gpt in-place editing In-Reply-To: <10218E29-D89D-40BB-BACF-9DFB131974E7@mac.com> References: <20080921140932.adf51b5e.stas@FreeBSD.org> <10719B6B-1F3B-44C6-BAC0-D8C3F42F7F3F@mac.com> <10218E29-D89D-40BB-BACF-9DFB131974E7@mac.com> Message-ID: On Mon, 22 Sep 2008, Marcel Moolenaar wrote: MM> > MM> > It does not seem gpart wants allow me to delete da0p3 while disk is MM> > MM> > active... MM> > MM> MM> > MM> You probably have swapon and/or dumpon to set to the partition. MM> > MM> You can't remove a partition that is in use. MM> > MM> MM> > MM> Run "swapoff /dev/da0p3" and/or "dumpon off" first. MM> > MM> > Of course I did run swapoff; I'm not sure I did dumpoff, and unfortunately MM> > I MM> > did not run it under script(1). gpt (I did test under RELENG_7) does the MM> > trick, MM> > but -- MM> > MM> > However, we clearly have at least one bug: not creating da* device (for MM> > da0p5 MM> > in my case) MM> MM> You can't make that claim. You've forced the issue MM> by setting debugflags and bypassing gpart. As such, MM> gpart is unaware of the new partition (it wasn't MM> involved in the creation) and it isn't being made MM> aware, because the underlying geom isn't spoiled MM> (which would trigger a retaste). I made a retest tonight, and found that gpart is actually doing things quite right (my fault in previous experiment seems to be that I did not check for filt system types, and gpart does not understand short types like 'ufs'). Also, gpart does not allow default values in add phase, which is a bit annoying, especially when you create last partition; but we can live with this I hope ;) Thank you. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From xcllnt at mac.com Wed Sep 24 19:38:52 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Sep 24 19:38:55 2008 Subject: gpt in-place editing In-Reply-To: References: <20080921140932.adf51b5e.stas@FreeBSD.org> <10719B6B-1F3B-44C6-BAC0-D8C3F42F7F3F@mac.com> <10218E29-D89D-40BB-BACF-9DFB131974E7@mac.com> Message-ID: <8BB33576-5388-457A-9E5C-83442145EF7C@mac.com> On Sep 24, 2008, at 12:25 PM, Dmitry Morozovsky wrote: > I made a retest tonight, and found that gpart is actually doing > things quite > right (my fault in previous experiment seems to be that I did not > check for > filt system types, and gpart does not understand short types like > 'ufs'). gpart uses "freebsd-ufs" instead of "ufs", because there are incompatible UFS implementations. In particular, if you create a UFS file system on Mac OS X, FreeBSD will panic when you try to mount it. As such, I found it prudent to have more precise partition types so that you can have a "freebsd-ufs" partition alongside a "macosx-ufs" partition (the latter I just pulled out of the hat -- we don't actually support that type). > Also, gpart does not allow default values in add phase, which is a bit > annoying, especially when you create last partition; but we can live > with this > I hope ;) True. This is just a matter of enhancing the UI though and should not be difficult to do... FYI, -- Marcel Moolenaar xcllnt@mac.com From 000.fbsd at quip.cz Wed Sep 24 19:38:57 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Sep 24 19:39:00 2008 Subject: zfs and gpt partition In-Reply-To: <911337bf0809240808p69197a62qc5865634bc1a27dd@mail.gmail.com> References: <911337bf0809240630s1b8a3f15y3c224bd82c59306b@mail.gmail.com> <48DA4CB0.4020401@egr.msu.edu> <911337bf0809240808p69197a62qc5865634bc1a27dd@mail.gmail.com> Message-ID: <48DA94AE.3070700@quip.cz> Vitaly Dodonov wrote: > On Wed, Sep 24, 2008 at 6:20 PM, Adam McDougall wrote: > > >>Vitaly Dodonov wrote: >> >> >>> I have problem with zfs on gpt partition in RELENG_7 >>> >>>when zfs use whole drive or classic slices, all work well in any ata port, >>>but changing device name with created on it gpt -t zfs partition broke zfs >>>volume >>>state - FAULTED >>> ad8 UNAVAIL 0 0 0 corrupted data >>> >>>restore possible only with returning drive to it original port, where >>>volume >>>was created >>> >>> >>> >> >>Please try looking at 'zpool export' and 'zpool import', it will probably >>correct the error if you export then import the pool. >> > > > yes, export/import working, but without gpt i don't need these operations, > drives don't drop from pool on device name change glabel is next thing you can try - give a label to the device and create zpool on top of labels, not on adX etc. (I didn't try it, do it on your own risk) ;) Miroslav Lachman From peter.schuller at infidyne.com Wed Sep 24 21:50:37 2008 From: peter.schuller at infidyne.com (Peter Schuller) Date: Wed Sep 24 21:50:44 2008 Subject: zfs and gpt partition In-Reply-To: <48DA94AE.3070700@quip.cz> References: <911337bf0809240630s1b8a3f15y3c224bd82c59306b@mail.gmail.com> <48DA4CB0.4020401@egr.msu.edu> <911337bf0809240808p69197a62qc5865634bc1a27dd@mail.gmail.com> <48DA94AE.3070700@quip.cz> Message-ID: <20080924215033.GA35628@hyperion.scode.org> > glabel is next thing you can try - give a label to the device and create > zpool on top of labels, not on adX etc. (I didn't try it, do it on your > own risk) ;) Not that I see a reason to believe it would be a problem to begin with, but FWIW I never do anything but use glabel for the constituent drives. IMO, when in doubt, glabel (with ZFS or otherwise). It almost never hurts, but can often help in unexpected situations. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080924/e5d7dee2/attachment.pgp From david.cecil at nokia.com Fri Sep 26 11:45:08 2008 From: david.cecil at nokia.com (David Cecil) Date: Fri Sep 26 11:45:17 2008 Subject: panic in closef Message-ID: <48DCC581.80009@nokia.com> Hi, I'm debugging a panic with the call trace below. This is from a 6.1-based kernel, but as far as I can tell there are no fixes for this problem in current, based on where I think the problem lies. It falls over in the call to VFS_LOCK_GIANT in closef, trying to dereference a NULL mount point. To me, the check in VFS_NEEDSGIANT looks flawed; it checks that MP isn't NULL, then dereferences it, but I'd expect the vnode interlock to be held (or similar), but it isn't based on what I see of the code. I looks to me like vgonel was probably running around the same time. It calls delmntque and NULLs v_mount. I can't see how these two threads are synchronised to prevent the race condition I describe, but maybe I'm missing something. Any ideas? Thanks, Dave Unread portion of the kernel message buffer: 2 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(60794d20) at db_trace_self_wrapper+0x25 kdb_backtrace(f8d0eae8,100,67aeb640,28,f8d0eb64,...) at kdb_backtrace+0x29 panic(60774fbe,607bae69,0,fffff,681dc89b,...) at panic+0x230 trap_fatal(f8d0eb64,6f,67aeb640,0,c,...) at trap_fatal+0x2ce trap_pfault(f8d0eb64,0,6f) at trap_pfault+0x1ef trap(7ae70008,28,f8d00028,3,8236e104,...) at trap+0x36d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x60565e72, esp = 0xf8d0eba4, ebp = 0xf8d0ec00 --- closef(7d7f19cc,67aeb640) at closef+0x36 fdfree(67aeb640) at fdfree+0x5a7 exit1(67aeb640,100,f8d0ed30,6074c903,67aeb640,...) at exit1+0x4ee exit1(67aeb640,f8d0ed04) at exit1 syscall(5fbf003b,812003b,5fbf003b,0,0,...) at syscall+0x2b7 Xint0x80_syscall() at Xint0x80_syscall+0x1f From kostikbel at gmail.com Fri Sep 26 11:56:43 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Sep 26 11:56:50 2008 Subject: panic in closef In-Reply-To: <48DCC581.80009@nokia.com> References: <48DCC581.80009@nokia.com> Message-ID: <20080926115631.GT47828@deviant.kiev.zoral.com.ua> On Fri, Sep 26, 2008 at 09:20:33PM +1000, David Cecil wrote: > Hi, > > I'm debugging a panic with the call trace below. This is from a > 6.1-based kernel, but as far as I can tell there are no fixes for this > problem in current, based on where I think the problem lies. No, it should be fixed. See r168020 | kib | 2007-03-29 11:21:09 +0300 (Thu, 29 Mar 2007) | 7 lines Extend rev. 1.210 to avoid dereference NULL mp in VFS_NEEDSGIANT and VFS_ASSERT_GIANT. Stop using reserved namespace. and r158320 | tegge | 2006-05-05 22:32:35 +0300 (Fri, 05 May 2006) | 2 lines Avoid dereferencing NULL pointer. > > It falls over in the call to VFS_LOCK_GIANT in closef, trying to > dereference a NULL mount point. To me, the check in VFS_NEEDSGIANT > looks flawed; it checks that MP isn't NULL, then dereferences it, but > I'd expect the vnode interlock to be held (or similar), but it isn't > based on what I see of the code. > > I looks to me like vgonel was probably running around the same time. It > calls delmntque and NULLs v_mount. I can't see how these two threads > are synchronised to prevent the race condition I describe, but maybe I'm > missing something. > > Any ideas? > > Thanks, > Dave > > Unread portion of the kernel message buffer: > 2 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(60794d20) at db_trace_self_wrapper+0x25 > kdb_backtrace(f8d0eae8,100,67aeb640,28,f8d0eb64,...) at kdb_backtrace+0x29 > panic(60774fbe,607bae69,0,fffff,681dc89b,...) at panic+0x230 > trap_fatal(f8d0eb64,6f,67aeb640,0,c,...) at trap_fatal+0x2ce > trap_pfault(f8d0eb64,0,6f) at trap_pfault+0x1ef > trap(7ae70008,28,f8d00028,3,8236e104,...) at trap+0x36d > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0x60565e72, esp = 0xf8d0eba4, ebp = 0xf8d0ec00 --- > closef(7d7f19cc,67aeb640) at closef+0x36 > fdfree(67aeb640) at fdfree+0x5a7 > exit1(67aeb640,100,f8d0ed30,6074c903,67aeb640,...) at exit1+0x4ee > exit1(67aeb640,f8d0ed04) at exit1 > syscall(5fbf003b,812003b,5fbf003b,0,0,...) at syscall+0x2b7 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > _______________________________________________ > 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080926/14c8c384/attachment.pgp From david.cecil at nokia.com Fri Sep 26 12:48:14 2008 From: david.cecil at nokia.com (David Cecil) Date: Fri Sep 26 12:48:21 2008 Subject: panic in closef In-Reply-To: <20080926115631.GT47828@deviant.kiev.zoral.com.ua> References: <48DCC581.80009@nokia.com> <20080926115631.GT47828@deviant.kiev.zoral.com.ua> Message-ID: <48DCDA03.60702@nokia.com> Ah yes, thanks Kostik I looked at that change, it didn't immediately click. After you mentioned it the local variable made sense. Thanks for pointing it out. Dave ext Kostik Belousov wrote: > On Fri, Sep 26, 2008 at 09:20:33PM +1000, David Cecil wrote: > >> Hi, >> >> I'm debugging a panic with the call trace below. This is from a >> 6.1-based kernel, but as far as I can tell there are no fixes for this >> problem in current, based on where I think the problem lies. >> > No, it should be fixed. See > > r168020 | kib | 2007-03-29 11:21:09 +0300 (Thu, 29 Mar 2007) | 7 lines > Extend rev. 1.210 to avoid dereference NULL mp in VFS_NEEDSGIANT and > VFS_ASSERT_GIANT. Stop using reserved namespace. > > and > > r158320 | tegge | 2006-05-05 22:32:35 +0300 (Fri, 05 May 2006) | 2 lines > Avoid dereferencing NULL pointer. > > >> It falls over in the call to VFS_LOCK_GIANT in closef, trying to >> dereference a NULL mount point. To me, the check in VFS_NEEDSGIANT >> looks flawed; it checks that MP isn't NULL, then dereferences it, but >> I'd expect the vnode interlock to be held (or similar), but it isn't >> based on what I see of the code. >> >> I looks to me like vgonel was probably running around the same time. It >> calls delmntque and NULLs v_mount. I can't see how these two threads >> are synchronised to prevent the race condition I describe, but maybe I'm >> missing something. >> >> Any ideas? >> >> Thanks, >> Dave >> >> Unread portion of the kernel message buffer: >> 2 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(60794d20) at db_trace_self_wrapper+0x25 >> kdb_backtrace(f8d0eae8,100,67aeb640,28,f8d0eb64,...) at kdb_backtrace+0x29 >> panic(60774fbe,607bae69,0,fffff,681dc89b,...) at panic+0x230 >> trap_fatal(f8d0eb64,6f,67aeb640,0,c,...) at trap_fatal+0x2ce >> trap_pfault(f8d0eb64,0,6f) at trap_pfault+0x1ef >> trap(7ae70008,28,f8d00028,3,8236e104,...) at trap+0x36d >> calltrap() at calltrap+0x5 >> --- trap 0xc, eip = 0x60565e72, esp = 0xf8d0eba4, ebp = 0xf8d0ec00 --- >> closef(7d7f19cc,67aeb640) at closef+0x36 >> fdfree(67aeb640) at fdfree+0x5a7 >> exit1(67aeb640,100,f8d0ed30,6074c903,67aeb640,...) at exit1+0x4ee >> exit1(67aeb640,f8d0ed04) at exit1 >> syscall(5fbf003b,812003b,5fbf003b,0,0,...) at syscall+0x2b7 >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> >> >> _______________________________________________ >> 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 bugmaster at FreeBSD.org Mon Sep 29 11:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:07:34 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200809291106.m8TB6nSL040784@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption 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/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/124621 fs [ext3] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp 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 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D 19 problems total. From lhmwzy at gmail.com Tue Sep 30 02:56:46 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Tue Sep 30 02:56:53 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? Message-ID: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. Would anybody do this? I do not have the skill or I will do this.:) links: http://www.dragonflybsd.org/hammer/index.shtml