From nike_d at cytexbg.com Sun Jun 1 17:12:11 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Sun Jun 1 17:12:14 2008 Subject: ZFS panic when changing zfs dataset mountpoint In-Reply-To: <20080530065439.GB3596@garage.freebsd.pl> References: <2e77fc10802120304n32fd1c42m52e6bc617ba07c35@mail.gmail.com> <20080530065439.GB3596@garage.freebsd.pl> Message-ID: <2e77fc10806010944p5fde4782nffa437230ff36362@mail.gmail.com> On Fri, May 30, 2008 at 2:54 AM, Pawel Jakub Dawidek wrote: > On Tue, Feb 12, 2008 at 01:04:38PM +0200, Niki Denev wrote: >> Hi, >> >> I got the following panic when trying to set/change the mountpoint >> property of a dataset. >> >> I did : >> # zfs set mountpoint=/usr/ports zfs2/ports >> and the machine crashed. >> >> The datased had one snapshot taken. >> >> Here is what i was able to extract from the dump : > [...] >> #8 0xffffffff804800d5 in _sx_xlock (sx=0xa0, opts=0, >> file=0xffffffff80c697f0 >> "/usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c", >> line=1069) at atomic.h:142 >> #9 0xffffffff80c50b2a in zfsctl_umount_snapshots (vfsp=Variable >> "vfsp" is not available. >> ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:1069 >> #10 0xffffffff80c57978 in zfs_umount (vfsp=0xffffff00014f5650, >> fflag=0, td=0xffffff001483b6a0) >> at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:692 > [...] > > I tried to reproduce your problem, but I can't. This is clearly related > to unmounting snapshots. Was your snapshot mounted at the time of > calling 'zfs set mountpoint='? I tried both scenarious (having mounted > and unmounted snapshot) and no panic. Is there anything else you did? > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > Hi Pawel, Sorry for my late reply. I cannot test right now because the machine suffered multiple disk failures, and is currently offline, but as far as I remember the machine had several snapshots mounted at the time of the panic. Regards, Niki From ighighi at gmail.com Mon Jun 2 05:35:44 2008 From: ighighi at gmail.com (Ighighi) Date: Mon Jun 2 05:35:48 2008 Subject: kern/122047: [ext2fs] incorrect handling of UF_IMMUTABLE / UF_APPEND, flag on EXT2FS (maybe others) Message-ID: <48438687.1080606@gmail.com> On Linux, only the root user may set/clear the immutable/append flags on ext2 filesystems... Shouldn't FreeBSD do this too, as a POLA? Anyway the attached patch extends the previous one by making it possible to follow the current Linux convention by setting the sysctl to 0. Setting it to 1, allows normal users to set them as well, and setting it to -1 preserves current (though erroneous) FreeBSD behavior. -------------- next part -------------- # # (!c) 2008 by Ighighi # # See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122047 # # This patch adds a vfs.e2fs.userflags sysctl to allow/prevent normal users # to set/clear the append/immutable filesystem flags on EXT2 filesystems. # If set to 0, only the superuser may set/clear these flags. This is the # default behavior on Linux, which FreeBSD should mimick (POLA). # If set to 1, users are also permitted to set/clear them on files they own. # If set to -1 (default), maintain the current (erroneus) behavior. # # As a bonus, this patch sets st_birthtime to zero. # # Built and tested on FreeBSD 6.3-STABLE (RELENG_6). # Known to patch on -CURRENT # # To install, run as root: # /sbin/umount -v -t ext2fs -a # /sbin/kldunload -v ext2fs # /usr/bin/patch -d /usr < /path/to/ext2fs.patch # cd /sys/modules/ext2fs/ # make clean obj depend && make && make install # /sbin/kldload -v ext2fs # /sbin/sysctl vfs.e2fs.userflags=1 # /sbin/mount -v -t ext2fs -a # --- src/sys/gnu/fs/ext2fs/ext2_inode_cnv.c.orig 2005-06-14 22:36:10.000000000 -0400 +++ src/sys/gnu/fs/ext2fs/ext2_inode_cnv.c 2008-06-02 00:35:34.658524358 -0430 @@ -30,11 +30,19 @@ #include #include #include +#include +#include #include #include #include +SYSCTL_DECL(_vfs_e2fs); + +static int userflags = -1; +SYSCTL_INT(_vfs_e2fs, OID_AUTO, userflags, CTLFLAG_RW, + &userflags, 0, "Users may set/clear filesystem flags"); + void ext2_print_inode( in ) struct inode *in; @@ -83,8 +91,37 @@ ext2_ei2i(ei, ip) ip->i_mtime = ei->i_mtime; ip->i_ctime = ei->i_ctime; ip->i_flags = 0; - ip->i_flags |= (ei->i_flags & EXT2_APPEND_FL) ? APPEND : 0; - ip->i_flags |= (ei->i_flags & EXT2_IMMUTABLE_FL) ? IMMUTABLE : 0; + switch (userflags) { + case 0: + /* + * Only the superuser may set/clear these flags. + * This is the current behavior on Linux. + */ + if (ei->i_flags & EXT2_APPEND_FL) + ip->i_flags |= SF_APPEND; + if (ei->i_flags & EXT2_IMMUTABLE_FL) + ip->i_flags |= SF_IMMUTABLE; + break; + case 1: + /* + * Users may set/clear these flags on files they own. + */ + if (ei->i_flags & EXT2_APPEND_FL) + ip->i_flags |= UF_APPEND; + if (ei->i_flags & EXT2_IMMUTABLE_FL) + ip->i_flags |= UF_IMMUTABLE; + break; + case -1: + default: + /* + * Default behavior on FreeBSD + */ + if (ei->i_flags & EXT2_APPEND_FL) + ip->i_flags |= APPEND; + if (ei->i_flags & EXT2_IMMUTABLE_FL) + ip->i_flags |= IMMUTABLE; + break; + } ip->i_blocks = ei->i_blocks; ip->i_gen = ei->i_generation; ip->i_uid = ei->i_uid; @@ -121,8 +158,37 @@ ext2_i2ei(ip, ei) ei->i_ctime = ip->i_ctime; ei->i_flags = ip->i_flags; ei->i_flags = 0; - ei->i_flags |= (ip->i_flags & APPEND) ? EXT2_APPEND_FL: 0; - ei->i_flags |= (ip->i_flags & IMMUTABLE) ? EXT2_IMMUTABLE_FL: 0; + switch (userflags) { + case 0: + /* + * Only the superuser may set/clear these flags. + * This is the current behavior on Linux. + */ + if (ip->i_flags & SF_APPEND) + ei->i_flags |= EXT2_APPEND_FL; + if (ip->i_flags & SF_IMMUTABLE) + ei->i_flags |= EXT2_IMMUTABLE_FL; + break; + case 1: + /* + * Users may set/clear these flags on files they own. + */ + if (ip->i_flags & UF_APPEND) + ei->i_flags |= EXT2_APPEND_FL; + if (ip->i_flags & UF_IMMUTABLE) + ei->i_flags |= EXT2_IMMUTABLE_FL; + break; + case -1: + default: + /* + * Default behavior on FreeBSD + */ + if (ip->i_flags & APPEND) + ei->i_flags |= EXT2_APPEND_FL; + if (ip->i_flags & IMMUTABLE) + ei->i_flags |= EXT2_IMMUTABLE_FL; + break; + } ei->i_blocks = ip->i_blocks; ei->i_generation = ip->i_gen; ei->i_uid = ip->i_uid; --- src/sys/gnu/fs/ext2fs/ext2_lookup.c.orig 2006-01-04 15:32:00.000000000 -0400 +++ src/sys/gnu/fs/ext2fs/ext2_lookup.c 2008-06-01 05:38:42.363332933 -0430 @@ -66,7 +66,7 @@ static int dirchk = 1; static int dirchk = 0; #endif -static SYSCTL_NODE(_vfs, OID_AUTO, e2fs, CTLFLAG_RD, 0, "EXT2FS filesystem"); +SYSCTL_NODE(_vfs, OID_AUTO, e2fs, CTLFLAG_RD, 0, "EXT2FS filesystem"); SYSCTL_INT(_vfs_e2fs, OID_AUTO, dircheck, CTLFLAG_RW, &dirchk, 0, ""); /* --- src/sys/gnu/fs/ext2fs/ext2_vnops.c.orig 2006-02-19 20:53:14.000000000 -0400 +++ src/sys/gnu/fs/ext2fs/ext2_vnops.c 2008-05-28 07:58:02.189157441 -0430 @@ -358,6 +358,8 @@ ext2_getattr(ap) vap->va_mtime.tv_nsec = ip->i_mtimensec; vap->va_ctime.tv_sec = ip->i_ctime; vap->va_ctime.tv_nsec = ip->i_ctimensec; + vap->va_birthtime.tv_sec = 0; + vap->va_birthtime.tv_nsec = 0; vap->va_flags = ip->i_flags; vap->va_gen = ip->i_gen; vap->va_blocksize = vp->v_mount->mnt_stat.f_iosize; From lists at thefrog.net Mon Jun 2 06:04:14 2008 From: lists at thefrog.net (Andrew Hill) Date: Mon Jun 2 06:04:17 2008 Subject: ZFS lockup in "zfs" state In-Reply-To: <93F07874-8D5F-44AE-945F-803FFC3B9279@thefrog.net> References: <683A6ED2-0E54-42D7-8212-898221C05150@thefrog.net> <20080518124217.GA16222@eos.sc1.parodius.com> <93F07874-8D5F-44AE-945F-803FFC3B9279@thefrog.net> Message-ID: <16a6ef710806012304m48b63161oee1bc6d11e54436a@mail.gmail.com> some more info... On Mon, May 19, 2008 at 1:11 AM, Andrew Hill wrote: > i tend to find that the timeouts occur on one or two disks at once - e.g. > ad0 and 2 will complain of timeouts, and the system locks up shortly > thereafter... after spitting out the usual errors from ad0 and ad2 (in this case) with TIMEOUTs and subsequent FAILUREs on READ_DMA[48] and WRITE_DMA[48]... i got the following panic vm_fault: pager read error, pid 1552 (tlsmgr) ad0: FAILURE - READ_DMA48 timed out LBA=352903900 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 437, size: 4096 ad2: FAILURE - WRITE_DMA timed out LBA=239717693 panic: ZFS: I/O failure (write on off 0: zio 0xffffff001d47c810 [L0 ZIL intent log] b000L/b000P DVA[0]=<0:c807795000:d000> zilog uncompressed LE contiguous birth=750230 fill=0 cksum=69f76525a84e1816:f6d86fe1d94cd68c:39:8af): error 5 KDB: enter: panic [thread pid 72 tid 100071 ] Stopped at kdb_enter_why+0x3d: movq $0,0x39b248(%rip) db> generally the lockups don't result in a panic (at least not in the short term of 5-10 minutes), so i can't be sure that this panic is necessarily caused by the same problem, but thought it might be worth posting in case it gives an indication of the location/cause of the deadlock unfortunately i couldn't get a backtrace or core dump for 'political' reasons (the system was required for use by others) but i'll see if i can get a panic happening after-hours to get some more info... From koitsu at FreeBSD.org Mon Jun 2 06:40:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Jun 2 06:40:27 2008 Subject: ZFS lockup in "zfs" state In-Reply-To: <16a6ef710806012304m48b63161oee1bc6d11e54436a@mail.gmail.com> References: <683A6ED2-0E54-42D7-8212-898221C05150@thefrog.net> <20080518124217.GA16222@eos.sc1.parodius.com> <93F07874-8D5F-44AE-945F-803FFC3B9279@thefrog.net> <16a6ef710806012304m48b63161oee1bc6d11e54436a@mail.gmail.com> Message-ID: <20080602064023.GA95247@eos.sc1.parodius.com> On Mon, Jun 02, 2008 at 04:04:12PM +1000, Andrew Hill wrote: > On Mon, May 19, 2008 at 1:11 AM, Andrew Hill wrote: > > > i tend to find that the timeouts occur on one or two disks at once - e.g. > > ad0 and 2 will complain of timeouts, and the system locks up shortly > > thereafter... > > after spitting out the usual errors from ad0 and ad2 (in this case) with > TIMEOUTs and subsequent FAILUREs on READ_DMA[48] and WRITE_DMA[48]... > > i got the following panic > > vm_fault: pager read error, pid 1552 (tlsmgr) > ad0: FAILURE - READ_DMA48 timed out LBA=352903900 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 437, size: 4096 > ad2: FAILURE - WRITE_DMA timed out LBA=239717693 > panic: ZFS: I/O failure (write on off 0: zio 0xffffff001d47c810 > [L0 ZIL intent log] b000L/b000P DVA[0]=<0:c807795000:d000> zilog > uncompressed LE contiguous birth=750230 fill=0 > cksum=69f76525a84e1816:f6d86fe1d94cd68c:39:8af): error 5 > KDB: enter: panic > [thread pid 72 tid 100071 ] > Stopped at kdb_enter_why+0x3d: movq $0,0x39b248(%rip) > db> I would say the ZFS crash is a result of the ad0/ad2 timeouts. The ZIL log shows a hard checksum failure in the ZIL, which indicates a serious problem -- very likely hardware-related (or rather, at a lower level than ZFS). You've read this already, but maybe you missed the DMA error part: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues The DMA errors can actually be legitimate too -- it's very hard to troubleshoot if they're superfluous (e.g. a FreeBSD bug) or if they're real. If the problem is reproducable, then this is convenient with regards to providing you additional help. I really need to sit down and write a huge HOWTO doc for people on how to diagnose whether or not their disks or cables are bad, etc... It's a very hard thing to document, because everyone's situation is different. The first piece to start with is simplest, though: install ports/sysutils/smartmontools and provide the output of "smartctl -a /dev/ad0" and /dev/ad2. Actual disk errors will very likely show up there in one of the counters, or in the SMART log. I'd personally like to see the output from smartctl, because it's something you can do while the system is up/working. The next step would involve replacing your cables. If the problem continues, you've at least removed one piece of the puzzle. Next, replace the disks -- especially if they were bought at the same time, and are from the same vendor. Hard disk vendors are known to have bad batches of disks. For sake of example, I just had two Western Digital disks (which I bought at the same time) fail a short I/O test, returning errors at different LBAs (blocks). The 2nd one only started showing problems a few weeks after the first. I obviously got both of them RMA'd. Finally, replace the controller or motherboard. Some people have reported success with this. > generally the lockups don't result in a panic (at least not in the short > term of 5-10 minutes), so i can't be sure that this panic is necessarily > caused by the same problem, but thought it might be worth posting in case it > gives an indication of the location/cause of the deadlock The DMA timeout errors you've seen, others have seen as well -- including me -- even when the hardware, disks, cabling, and controllers are in a 100% working state. (Even switching OSes results in no errors, indicating there is a problem with FreeBSD in some way.) If the problem is reproducable, you should get in contact with Scott Long and let him poke at things. (I mentioned this last time. :-) ) I myself am not familiar with the FreeBSD kernel, the device drivers, or working with the kernel at such a low level to debug things of this nature. > unfortunately i couldn't get a backtrace or core dump for 'political' > reasons (the system was required for use by others) but i'll see if i can > get a panic happening after-hours to get some more info... I can't tell you what to do or how to do your job, but honestly you should be pulling this system out of production and replacing it with a different one, or a different implementation, or a different OS. Your users/employees are probably getting ticked off at the crashes, and it probably irritates you too. The added benefit is that you could get Scott access to the box. -- | 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 julian at elischer.org Mon Jun 2 07:27:45 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Jun 2 07:27:49 2008 Subject: kern/122047: [ext2fs] incorrect handling of UF_IMMUTABLE / UF_APPEND, flag on EXT2FS (maybe others) In-Reply-To: <48438687.1080606@gmail.com> References: <48438687.1080606@gmail.com> Message-ID: <48439DE6.50505@elischer.org> Ighighi wrote: > On Linux, only the root user may set/clear the immutable/append flags > on ext2 filesystems... Shouldn't FreeBSD do this too, as a POLA? No I think it should preserver the BSD scheme where being able to change the immutable bits is controlled by the system secure level. (and your UID of course). At least I think that is what I would expect. (All file systems to behave about the same for a particular OS. > > Anyway the attached patch extends the previous one by making it possible > to follow the current Linux convention by setting the sysctl to 0. > Setting it to 1, allows normal users to set them as well, and setting it > to -1 preserves current (though erroneous) FreeBSD behavior. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 brde at optusnet.com.au Mon Jun 2 10:30:11 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Mon Jun 2 10:30:15 2008 Subject: kern/122047: [ext2fs] incorrect handling of UF_IMMUTABLE / UF_APPEND, flag on EXT2FS (maybe others) In-Reply-To: <48439DE6.50505@elischer.org> References: <48438687.1080606@gmail.com> <48439DE6.50505@elischer.org> Message-ID: <20080602202420.N3083@delplex.bde.org> On Mon, 2 Jun 2008, Julian Elischer wrote: > Ighighi wrote: >> On Linux, only the root user may set/clear the immutable/append flags >> on ext2 filesystems... Shouldn't FreeBSD do this too, as a POLA? > > No I think it should preserver the BSD scheme where being able to > change the immutable bits is controlled by the system secure level. > (and your UID of course). At least I think that is what I would > expect. (All file systems to behave about the same for a > particular OS. No, the securelevel already controls things, and the BSD scheme reduces to only allowing root (strictly, processes with appropriate privilege, as restricted by securelevel and jails etc, but never mere users), to change immutable bits, because ext2fs doesn't have any user immutable bits to change (except phantom bits due to bugs in the current FreeBSD implementation). Bruce From bugmaster at FreeBSD.org Mon Jun 2 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 2 11:06:58 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200806021106.m52B6lwF093143@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- 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 6 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 6 problems total. From brde at optusnet.com.au Mon Jun 2 14:56:04 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Mon Jun 2 14:56:11 2008 Subject: kern/122047: [ext2fs] incorrect handling of UF_IMMUTABLE / UF_APPEND, flag on EXT2FS (maybe others) In-Reply-To: <48438687.1080606@gmail.com> References: <48438687.1080606@gmail.com> Message-ID: <20080602163212.G2551@delplex.bde.org> On Mon, 2 Jun 2008, Ighighi wrote: > On Linux, only the root user may set/clear the immutable/append flags > on ext2 filesystems... Shouldn't FreeBSD do this too, as a POLA? I think it should do just that... > Anyway the attached patch extends the previous one by making it possible > to follow the current Linux convention by setting the sysctl to 0. > Setting it to 1, allows normal users to set them as well, and setting it > to -1 preserves current (though erroneous) FreeBSD behavior. ... but nothing more. Why have complications provide more control over Linux file systems than Linux does? The current behaviour seems to be just a bug from not understanding that Linux has no user immutable/append flags. % --- src/sys/gnu/fs/ext2fs/ext2_inode_cnv.c.orig 2005-06-14 22:36:10.000000000 -0400 % +++ src/sys/gnu/fs/ext2fs/ext2_inode_cnv.c 2008-06-02 00:35:34.658524358 -0430 % @@ -30,11 +30,19 @@ % #include % #include % #include % +#include % +#include % % #include % #include % #include % % +SYSCTL_DECL(_vfs_e2fs); % + % +static int userflags = -1; % +SYSCTL_INT(_vfs_e2fs, OID_AUTO, userflags, CTLFLAG_RW, % + &userflags, 0, "Users may set/clear filesystem flags"); % + % void % ext2_print_inode( in ) % struct inode *in; The existence of vfs sysctls is another bug. They should be mount options, or perhaps system-wide, or not exist at all. ext2fs has only one vfs sysctl now: - vfs.e2fs.dircheck. This sysctl is less broken than in ffs, where the corresponding sysctl is spelled debug.dircheck and a comment still says that the corresponding static kernel variable `dirchk' is changed by "patching". The kernel variable is spelled differently to the sysctl to confuse me when grepping for dircheck. - the debug.doasyncfree sysctl is in dead code (under the non-option FANCY_REALLOC. Block reallocation is also dead in ext2fs). This sysctl is less broken in ffs. There it is named vfs.ffs.doasyncfree. OTOH, perhaps these sysctls really did belong under debug or vfs.debug. It is not very useful to restrict them to just ffs or ext2fs when have many mounted file systems. This bug should not be extended. % @@ -83,8 +91,37 @@ ext2_ei2i(ei, ip) % ip->i_mtime = ei->i_mtime; % ip->i_ctime = ei->i_ctime; % ip->i_flags = 0; % - ip->i_flags |= (ei->i_flags & EXT2_APPEND_FL) ? APPEND : 0; % - ip->i_flags |= (ei->i_flags & EXT2_IMMUTABLE_FL) ? IMMUTABLE : 0; I think it would work to just map EXT2*_FL to SF_*. % + switch (userflags) { % + case 0: % + /* % + * Only the superuser may set/clear these flags. % + * This is the current behavior on Linux. % + */ % + if (ei->i_flags & EXT2_APPEND_FL) % + ip->i_flags |= SF_APPEND; % + if (ei->i_flags & EXT2_IMMUTABLE_FL) % + ip->i_flags |= SF_IMMUTABLE; % + break; % + case 1: % + /* % + * Users may set/clear these flags on files they own. % + */ % + if (ei->i_flags & EXT2_APPEND_FL) % + ip->i_flags |= UF_APPEND; % + if (ei->i_flags & EXT2_IMMUTABLE_FL) % + ip->i_flags |= UF_IMMUTABLE; % + break; For administration it can be convenient for the file system to behave a little differently to native mode, but I letting root change the (system) immutable flags is enough. % + case -1: % + default: % + /* % + * Default behavior on FreeBSD % + */ % + if (ei->i_flags & EXT2_APPEND_FL) % + ip->i_flags |= APPEND; % + if (ei->i_flags & EXT2_IMMUTABLE_FL) % + ip->i_flags |= IMMUTABLE; % + break; % + } I think the current behaviour is too buggy to keep. (Your original PR describes the bugs -- FreeBSD makes a mess by setting 2 flags in the in-core inode and allowing these flags to be changed independently, then cannot merge the flags properly when writing to the on-disk inode.) [conversion to the on-disk inode] Similarly. There is a problem in ext2_vnops.c that is not touched by these patches. Even in the simple version that only support SF_*, ext2_setattr() needs changes to disallow setting of UF_* -- otherwise FreeBSD still makes a mess, with stat() showing changes to UF_* succeeding while the inode is in-core but going away when the inode is flushed from the inode/vnode cache. The fix is simply to remove the code that supports UF_*. (We could also globably replace IMMUTABLE and APPEND by SF_IMMUTABLE and SF_APPEND. This would be clearer but would increase divergence from ffs.) The fix to support all 3 sysctl modes is not so simple: - case 0: dynamically disallow attempts to set UF_*. - case 1: dynamically disallow attempts to set SF_*. - case -1: dynamically convert attempts to set SF_* or UF*_ into attempts to set both, and somehow relax the checks for setting SF_* so that this has a chance of succeeding for non-root. I don't want these complications. Note that the corresponding code in ffs is poorly organized and buggy (it doesn't allow preservation of flags in the right way). ext2_setattr() was once almost identical to ufs_settatr() but now has the following bitrot: - missing support for setting atimes on exec. - different comments about privilege though the code is the same. - different comments about truncate() on r/o file systems. Missing a critical fix for truncate(). - missing the comment expansion and cleanup for utimes(). I think there was a minor security-related fix in there too, but this is now null. % --- src/sys/gnu/fs/ext2fs/ext2_vnops.c.orig 2006-02-19 20:53:14.000000000 -0400 % +++ src/sys/gnu/fs/ext2fs/ext2_vnops.c 2008-05-28 07:58:02.189157441 -0430 % @@ -358,6 +358,8 @@ ext2_getattr(ap) % vap->va_mtime.tv_nsec = ip->i_mtimensec; % vap->va_ctime.tv_sec = ip->i_ctime; % vap->va_ctime.tv_nsec = ip->i_ctimensec; % + vap->va_birthtime.tv_sec = 0; % + vap->va_birthtime.tv_nsec = 0; % vap->va_flags = ip->i_flags; % vap->va_gen = ip->i_gen; % vap->va_blocksize = vp->v_mount->mnt_stat.f_iosize; This is unrelated and should be handled centrally. Almost all file systems get this wrong. Most fail to set va_birthtime, so stat() returns kernel stack garbage for st_birthtime. ffs1 does the same as the above. msdosfs does the above correctly, by setting tv_sec to (time_t)-1 in unsupported cases. Bruce From yalur at mail.ru Mon Jun 2 19:31:54 2008 From: yalur at mail.ru (Ruslan Kovtun) Date: Mon Jun 2 19:31:59 2008 Subject: ZFS lockup in "zfs" state In-Reply-To: <20080602064023.GA95247@eos.sc1.parodius.com> References: <683A6ED2-0E54-42D7-8212-898221C05150@thefrog.net> <16a6ef710806012304m48b63161oee1bc6d11e54436a@mail.gmail.com> <20080602064023.GA95247@eos.sc1.parodius.com> Message-ID: <200806022231.46079.yalur@mail.ru> Hi. I have the same problem very often with HDD (READ_DMA UDMA ICRC error) which is in zfs pool. Before, this HDD was in mirror ar0 but not in ZFS pool and this hard disk sometimes have failed but with no any panic only detached from mirror. After I included this HDD to ZFS pool problem have apeared. I am sure that this is problem with hard disk. Smartmontools notified me by mail that UDMA_CRC_Error_Count have increased after HDD failure and acording smartctl I can see that HDD have hardware problem. I replased cable, tried to connect this HDD to another port - but no result: 100% hard disk problem. I can not create kernel coredump during panic: savecore: no dumps found :( Only logs are available: In log file: Jun 1 10:43:11 yalur kernel: ad16: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=233909187 Jun 1 10:43:20 yalur kernel: ad16: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Jun 1 10:43:36 yalur kernel: ad16: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Jun 1 10:43:36 yalur kernel: ad16: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Jun 1 10:43:36 yalur kernel: ad16: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Jun 1 10:43:36 yalur kernel: ad16: WARNING - SET_MULTI taskqueue timeout - completing request directly Jun 1 10:43:36 yalur kernel: ad16: TIMEOUT - READ_DMA retrying (0 retries left) LBA=233909187 Jun 1 11:07:50 yalur syslogd: restart Jun 1 11:07:50 yalur syslogd: kernel boot file is /boot/kernel/kernel Jun 1 11:07:50 yalur kernel: ad16: FAILURE - device detached Jun 1 11:07:50 yalur kernel: subdisk16: detached Jun 1 11:07:50 yalur kernel: ad16: detached Jun 1 11:07:50 yalur kernel: Jun 1 11:07:50 yalur kernel: Jun 1 11:07:50 yalur kernel: Fatal trap 12: page fault while in kernel mode Jun 1 11:07:50 yalur kernel: cpuid = 0; apic id = 00 Jun 1 11:07:50 yalur kernel: fault virtual address = 0x2c Jun 1 11:07:50 yalur kernel: fault code = supervisor write, page not present Jun 1 11:07:50 yalur kernel: instruction pointer = 0x20:0x805aab85 Jun 1 11:07:50 yalur kernel: stack pointer = 0x28:0xed71ac5c Jun 1 11:07:50 yalur kernel: frame pointer = 0x28:0xed71ac70 Jun 1 11:07:50 yalur kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Jun 1 11:07:50 yalur kernel: = DPL 0, pres 1, def32 1, gran 1 Jun 1 11:07:50 yalur kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Jun 1 11:07:50 yalur kernel: current process = 3 (g_up) Jun 1 11:07:50 yalur kernel: trap number = 12 Jun 1 11:07:50 yalur kernel: panic: page fault Jun 1 11:07:50 yalur kernel: cpuid = 0 [root@yalur /home/ruslan]# zpool status pool: data state: ONLINE scrub: scrub completed with 0 errors on Mon Jun 2 12:05:52 2008 config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad4 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad16 ONLINE 0 0 0 ad20 ONLINE 0 0 0 spares ad26 AVAIL errors: No known data errors ? ????????? ?? ??????????? 02 ???? 2008 Jeremy Chadwick ???????(a): > On Mon, Jun 02, 2008 at 04:04:12PM +1000, Andrew Hill wrote: > > On Mon, May 19, 2008 at 1:11 AM, Andrew Hill wrote: > > > i tend to find that the timeouts occur on one or two disks at once - > > > e.g. ad0 and 2 will complain of timeouts, and the system locks up > > > shortly thereafter... > > > > after spitting out the usual errors from ad0 and ad2 (in this case) with > > TIMEOUTs and subsequent FAILUREs on READ_DMA[48] and WRITE_DMA[48]... > > > > i got the following panic > > > > vm_fault: pager read error, pid 1552 (tlsmgr) > > ad0: FAILURE - READ_DMA48 timed out LBA=352903900 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 437, size: 4096 > > ad2: FAILURE - WRITE_DMA timed out LBA=239717693 > > panic: ZFS: I/O failure (write on off 0: zio 0xffffff001d47c810 > > [L0 ZIL intent log] b000L/b000P DVA[0]=<0:c807795000:d000> zilog > > uncompressed LE contiguous birth=750230 fill=0 > > cksum=69f76525a84e1816:f6d86fe1d94cd68c:39:8af): error 5 > > KDB: enter: panic > > [thread pid 72 tid 100071 ] > > Stopped at kdb_enter_why+0x3d: movq $0,0x39b248(%rip) > > db> > > I would say the ZFS crash is a result of the ad0/ad2 timeouts. The ZIL > log shows a hard checksum failure in the ZIL, which indicates a serious > problem -- very likely hardware-related (or rather, at a lower level > than ZFS). > > You've read this already, but maybe you missed the DMA error part: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > The DMA errors can actually be legitimate too -- it's very hard to > troubleshoot if they're superfluous (e.g. a FreeBSD bug) or if they're > real. If the problem is reproducable, then this is convenient with > regards to providing you additional help. > > I really need to sit down and write a huge HOWTO doc for people on how > to diagnose whether or not their disks or cables are bad, etc... It's a > very hard thing to document, because everyone's situation is different. > > The first piece to start with is simplest, though: install > ports/sysutils/smartmontools and provide the output of "smartctl -a > /dev/ad0" and /dev/ad2. Actual disk errors will very likely show up > there in one of the counters, or in the SMART log. I'd personally like > to see the output from smartctl, because it's something you can do while > the system is up/working. > > The next step would involve replacing your cables. If the problem > continues, you've at least removed one piece of the puzzle. > > Next, replace the disks -- especially if they were bought at the same > time, and are from the same vendor. Hard disk vendors are known to have > bad batches of disks. For sake of example, I just had two Western > Digital disks (which I bought at the same time) fail a short I/O test, > returning errors at different LBAs (blocks). The 2nd one only started > showing problems a few weeks after the first. I obviously got both of > them RMA'd. > > Finally, replace the controller or motherboard. Some people have > reported success with this. > > > generally the lockups don't result in a panic (at least not in the short > > term of 5-10 minutes), so i can't be sure that this panic is necessarily > > caused by the same problem, but thought it might be worth posting in case > > it gives an indication of the location/cause of the deadlock > > The DMA timeout errors you've seen, others have seen as well -- > including me -- even when the hardware, disks, cabling, and controllers > are in a 100% working state. (Even switching OSes results in no errors, > indicating there is a problem with FreeBSD in some way.) > > If the problem is reproducable, you should get in contact with Scott > Long and let him poke at things. (I mentioned this last time. :-) ) > I myself am not familiar with the FreeBSD kernel, the device drivers, or > working with the kernel at such a low level to debug things of this > nature. > > > unfortunately i couldn't get a backtrace or core dump for 'political' > > reasons (the system was required for use by others) but i'll see if i can > > get a panic happening after-hours to get some more info... > > I can't tell you what to do or how to do your job, but honestly you > should be pulling this system out of production and replacing it with a > different one, or a different implementation, or a different OS. Your > users/employees are probably getting ticked off at the crashes, and it > probably irritates you too. The added benefit is that you could get > Scott access to the box. -- ________________ ? ????????? ?????? ?????? mailto From fbsd-fs at mawer.org Mon Jun 2 22:26:17 2008 From: fbsd-fs at mawer.org (Antony Mawer) Date: Mon Jun 2 22:26:20 2008 Subject: ZFS lockup in "zfs" state In-Reply-To: <20080602064023.GA95247@eos.sc1.parodius.com> References: <683A6ED2-0E54-42D7-8212-898221C05150@thefrog.net> <20080518124217.GA16222@eos.sc1.parodius.com> <93F07874-8D5F-44AE-945F-803FFC3B9279@thefrog.net> <16a6ef710806012304m48b63161oee1bc6d11e54436a@mail.gmail.com> <20080602064023.GA95247@eos.sc1.parodius.com> Message-ID: <48446C42.4070208@mawer.org> Jeremy Chadwick wrote: > On Mon, Jun 02, 2008 at 04:04:12PM +1000, Andrew Hill wrote: ... >> unfortunately i couldn't get a backtrace or core dump for 'political' >> reasons (the system was required for use by others) but i'll see if i can >> get a panic happening after-hours to get some more info... > > I can't tell you what to do or how to do your job, but honestly you > should be pulling this system out of production and replacing it with a > different one, or a different implementation, or a different OS. Your > users/employees are probably getting ticked off at the crashes, and it > probably irritates you too. The added benefit is that you could get > Scott access to the box. It's a home fileserver rather than a production "work" system, so the challenge is finding another system with an equivalent amount of storage.. :-) As one knows these things are often hard enough to procure out of a company budget, let alone out of ones own pocket! --Antony From freebsd-fs at mindstep.com Tue Jun 3 07:46:52 2008 From: freebsd-fs at mindstep.com (Patrick Bihan-Faou) Date: Tue Jun 3 07:46:56 2008 Subject: Booting a disk with gmirror and gjournal Message-ID: <4844F171.3000801@mindstep.com> Hi, I am trying to setup a system with one gjournal'ed partition mirrored on two disks using FreeBSD 6.3, and it does not work... Here is what I have routinely done so far: one partition, no journal, mirrored disks => I can have a working system. one partition, no mirror, journal => everything is ok but as soon as I try combine both gjournal and gmirror, I get stuck: once the system boots I get stuck at the F1 prompt and things do go any further. Could anybody help me with this ? Patrick. From koitsu at FreeBSD.org Tue Jun 3 08:11:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jun 3 08:11:43 2008 Subject: Booting a disk with gmirror and gjournal In-Reply-To: <4844F171.3000801@mindstep.com> References: <4844F171.3000801@mindstep.com> Message-ID: <20080603081140.GA62607@eos.sc1.parodius.com> On Tue, Jun 03, 2008 at 09:23:29AM +0200, Patrick Bihan-Faou wrote: > Hi, > > I am trying to setup a system with one gjournal'ed partition mirrored on > two disks using FreeBSD 6.3, and it does not work... > > Here is what I have routinely done so far: > > one partition, no journal, mirrored disks => I can have a working system. > one partition, no mirror, journal => everything is ok > > but as soon as I try combine both gjournal and gmirror, I get stuck: once > the system boots I get stuck at the F1 prompt and things do go any further. > > > Could anybody help me with this ? > > Patrick. As far as I know, FreeBSD's bootloader doesn't understand how to handle such things. -- | 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 freebsd-fs at mindstep.com Tue Jun 3 09:13:09 2008 From: freebsd-fs at mindstep.com (Patrick Bihan-Faou) Date: Tue Jun 3 09:13:13 2008 Subject: Booting a disk with gmirror and gjournal In-Reply-To: <20080603081140.GA62607@eos.sc1.parodius.com> References: <4844F171.3000801@mindstep.com> <20080603081140.GA62607@eos.sc1.parodius.com> Message-ID: <48450B21.3080700@mindstep.com> Jeremy Chadwick a ?crit : > On Tue, Jun 03, 2008 at 09:23:29AM +0200, Patrick Bihan-Faou wrote: > >> Hi, >> >> I am trying to setup a system with one gjournal'ed partition mirrored on >> two disks using FreeBSD 6.3, and it does not work... >> >> Here is what I have routinely done so far: >> >> one partition, no journal, mirrored disks => I can have a working system. >> one partition, no mirror, journal => everything is ok >> >> but as soon as I try combine both gjournal and gmirror, I get stuck: once >> the system boots I get stuck at the F1 prompt and things do go any further. >> >> >> Could anybody help me with this ? >> >> Patrick. >> > > As far as I know, FreeBSD's bootloader doesn't understand how to handle > such things. > > Actually, the bootloader copes just fine with such a setup. I just didn't do things in the right order. Here is how I managed to get it going: # gmirror label -h gm0 ad0 # fdisk -I -B -v /dev/mirror/gm0 # bsdlabel -r -w /dev/mirror/gm0s1 auto # bsdlabel /dev/mirror/gm0s1 > bsdlabel.file ... edit the label to create one single a partition (and/or whatever ones need) # bsdlabel -R -B /dev/mirror/gm0s1 bsdlabel.file # gjournal label -f /dev/mirror/gm0s1a # newfs -L 'boothd' -J /dev/mirror/gm0s1a.journal ... on now install freebsd on /dev/mirror/gm0s1a.journal or /dev/ufs/boothd Sorry for the noise, my problem was due to not doing things in the right order. Patrick. From 000.fbsd at quip.cz Tue Jun 3 09:33:28 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Jun 3 09:33:33 2008 Subject: Booting a disk with gmirror and gjournal In-Reply-To: <4844F171.3000801@mindstep.com> References: <4844F171.3000801@mindstep.com> Message-ID: <48450C67.7080907@quip.cz> Patrick Bihan-Faou wrote: > Hi, > > I am trying to setup a system with one gjournal'ed partition mirrored on > two disks using FreeBSD 6.3, and it does not work... > > Here is what I have routinely done so far: > > one partition, no journal, mirrored disks => I can have a working system. > one partition, no mirror, journal => everything is ok > > but as soon as I try combine both gjournal and gmirror, I get stuck: > once the system boots I get stuck at the F1 prompt and things do go any > further. > > > Could anybody help me with this ? Can you discribe it more closely? Do you want to have 2 physical disks in gmirror with only 1 slice covering whole disk with only 1 partition (gjournaled) used as root (/) of your system? Miroslav Lachman From lopez.on.the.lists at yellowspace.net Tue Jun 3 12:55:32 2008 From: lopez.on.the.lists at yellowspace.net (Lorenzo Perone) Date: Tue Jun 3 12:58:49 2008 Subject: ZFS lockup in "zfs" state In-Reply-To: <48446C42.4070208@mawer.org> References: <683A6ED2-0E54-42D7-8212-898221C05150@thefrog.net> <20080518124217.GA16222@eos.sc1.parodius.com> <93F07874-8D5F-44AE-945F-803FFC3B9279@thefrog.net> <16a6ef710806012304m48b63161oee1bc6d11e54436a@mail.gmail.com> <20080602064023.GA95247@eos.sc1.parodius.com> <48446C42.4070208@mawer.org> Message-ID: <38DAE942-319A-4A44-A8F6-491D4269A8E7@yellowspace.net> Hello, just to add one more voice to the issue: I'm experiencing the lockups with zfs too. Environment: development test machine, amd64, 3GHz AMD, 2GB ram, running FreeBSD/amd64 7.0-STABLE #8, Sat Apr 26 10:10:53 CEST 2008, with one 400GB SATA disk devoted completely to a zpool (no raid of any kind). This disk has 5 filesystems which get rsynced on a daily basis from different other development hosts. Some of the filesystems are nfs-exported. /boot/loader.conf contains: vm.kmem_size=900M vm.kmem_size_max=900M vfs.zfs.arc_max=300M vfs.zfs.prefetch_disable=1 The disk itself has no known hw problems. A script controlled by cron makes a daily or weekly snapshot of the filesystems (at 2:30 AM). Before that, a "housekeeping" script checks for available space, and if the space is getting below a certain threshold, it destroys older snapshots (at 1:30 am). The rsyncs to the pool all happen a few hours later (4:30 am). I've seen lockups periodically, where I could not do anything else but hard-reboot the machine to unstuck it. It was possible to use other filesystems, but any process trying to access the zpool would hang. Now the very first hang was about 3 months after 7.0-BETA4, which was when I first setup the pools. I then csupped and rebuilt world and kernel periodically, the last time being end of april. After that I got those lockups more often, that is, after a maximum of 2 weeks. I noticed that now that I lowered the threshold of the "housekeeping" script, it hasn't locked up for about 3 weeks. That seems to point at a problem with zfs destroy fs@snapshot - or to anything my script does, so here's a link to it: http://lorenzo.yellowspace.net/zfs_housekeeping.sh.txt haven't seen any adX- timeouts or any other suspicious console messages so far. If there is anything I can provide to help nail down zfs problems please refer to it and I'll do my best... Thanx to everyone working on this great OS and on this cute file/volsystem :) Regards, Lorenzo On 02.06.2008, at 23:55, Antony Mawer wrote: > Jeremy Chadwick wrote: >> On Mon, Jun 02, 2008 at 04:04:12PM +1000, Andrew Hill wrote: > ... >>> unfortunately i couldn't get a backtrace or core dump for >>> 'political' >>> reasons (the system was required for use by others) but i'll see >>> if i can >>> get a panic happening after-hours to get some more info... >> I can't tell you what to do or how to do your job, but honestly you >> should be pulling this system out of production and replacing it >> with a >> different one, or a different implementation, or a different OS. >> Your >> users/employees are probably getting ticked off at the crashes, and >> it >> probably irritates you too. The added benefit is that you could get >> Scott access to the box. > > It's a home fileserver rather than a production "work" system, so > the challenge is finding another system with an equivalent amount of > storage.. :-) As one knows these things are often hard enough to > procure out of a company budget, let alone out of ones own pocket! > > --Antony > _______________________________________________ > 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 avg at icyb.net.ua Thu Jun 5 07:45:10 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jun 5 07:45:15 2008 Subject: mystery: lock up after fs dump In-Reply-To: <20080604161001.GF63348@deviant.kiev.zoral.com.ua> References: <4846AFC3.3050101@icyb.net.ua> <20080604152332.GE63348@deviant.kiev.zoral.com.ua> <4846B5D9.1050903@icyb.net.ua> <20080604161001.GF63348@deviant.kiev.zoral.com.ua> Message-ID: <4847997D.4060404@icyb.net.ua> on 04/06/2008 19:10 Kostik Belousov said the following: > SU are irrelevant to the problem I am thinking of. > > vfs_write_suspend() returns 0 when the filesystem being suspended is already > in suspend state. vfs_write_resume() clears the suspend state. > > vfs_write_suspend/vfs_write_resume are used both by snapshot code and > the gjournal. If two users of these interfaces interleave, then you could > get: > > thread1 thread2 > > vfs_write_suspend() > <- fs is suspended there > vfs_write_suspend() <- returns 0 > vfs_write_resume() > <- fs is no more suspended > thread2 is burned in flame > > Snapshots are protected against this because they are created through > the mount(2). The mount(2) locks the covered vnode and thus serializes > snapshot creation (I think there are further serialization points that > prevent simultaneous snapshotting of the same fs). > > There is nothing I can see that protects snapshots/gjournal interaction. Looks like something to be quite concerned about. Thank you for the analysis. -- Andriy Gapon From jh at saunalahti.fi Thu Jun 5 10:48:40 2008 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Thu Jun 5 10:48:46 2008 Subject: =?utf-8?b?W3BhdGNoXcKgYnVn?= in cd9660 readdir code Message-ID: <20080605102900.GA1971@a91-153-120-204.elisa-laajakaista.fi> Hi, There's a bug in cd9660_readdir() (src/sys/fs/cd9660/cd9660_vnops.c) which may change the directory position (offset) to an invalid value. The problem is that if all directory entries has been read and idp->curroff >= endsearch the code doesn't enter to while (idp->curroff < endsearch) { loop which initializes idp->uio_off. Later in code uio->uio_offset is changed to idp->uio_off (which may be uninitialized). The PR 122925 (http://www.freebsd.org/cgi/query-pr.cgi?pr=122925) has a real life example of a problem caused by this bug. There's also a stripped down test program attached to the PR. Problems include readdir(3) restarting from random position and geom errors caused by read attempts from bogus offsets. Does following patch look good? Few people have tested the patch and it has fixed problems for them. If the patch looks good could someone consider committing it? Index: cd9660_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/cd9660/cd9660_vnops.c,v retrieving revision 1.113 diff -p -u -r1.113 cd9660_vnops.c --- cd9660_vnops.c 15 Feb 2007 22:08:34 -0000 1.113 +++ cd9660_vnops.c 20 May 2008 06:45:20 -0000 @@ -495,6 +495,7 @@ cd9660_readdir(ap) } idp->eofflag = 1; idp->curroff = uio->uio_offset; + idp->uio_off = uio->uio_offset; if ((entryoffsetinblock = idp->curroff & bmask) && (error = cd9660_blkatoff(vdp, (off_t)idp->curroff, NULL, &bp))) { -- Jaakko From pjd at FreeBSD.org Sat Jun 7 14:39:51 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sat Jun 7 14:39:55 2008 Subject: raidtest: Cannot open 'raidtest.data' device: Operation not permitted In-Reply-To: <200712071131.31773.antik@bsd.ee> References: <200712071131.31773.antik@bsd.ee> Message-ID: <20080607143944.GC1344@garage.freebsd.pl> On Fri, Dec 07, 2007 at 11:31:31AM +0200, Andrei Kolu wrote: > # uname -a > FreeBSD test.demo 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Sun Dec 2 16:34:41 UTC 2007 > root@myers.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > 3ware device driver for 9000 series storage controllers, version: 3.70.05.001 > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem > 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci7 > twa0: [ITHREAD] > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, > Firmware FE9X 3.08.02.007, BIOS BE9X 3.08.00.002 > > raidtest-1.1 = up-to-date with port > > # set mediasize=`diskinfo /dev/da0 | awk '{print $3}'` > # set sectorsize=`diskinfo /dev/da0 | awk '{print $2}'` > # raidtest genfile -s $mediasize -S $sectorsize -n 50000 > # raidtest test -d /dev/da0 -n 10 > raidtest: Cannot open 'raidtest.data' device: Operation not permitted > > # echo $mediasize > 1919932170240 > # echo $sectorsize > 512 > > > Or anyone can recommend other raid performance testing utility? A bit late, but... There was a bug in raidtest that it printed wrong file name. What it wanted to say was: raidtest: Cannot open '/dev/da0' device: Operation not permitted Which means it cannot open /dev/da0 for reading and writing, because it is already open for writting. If you only want to test reading performance try 'raidtest test -r'. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080607/134488c4/attachment.pgp From mckusick at chez.mckusick.com Sun Jun 8 19:29:10 2008 From: mckusick at chez.mckusick.com (Kirk McKusick) Date: Sun Jun 8 19:29:13 2008 Subject: kern/122047: [ext2fs] incorrect handling of UF_IMMUTABLE / UF_APPEND, flag on EXT2FS (maybe others) Message-ID: <200806081904.m58J4Qg7033415@chez.mckusick.com> Bruce, I concur with your analysis of what should be done here. Disallow manipulation of UF_ flags in ext2 and restrict SF_ flags to appropriate priviledge as is done in both FreeBSD and Linux. The only debate is whether to enforce FreeBSD securelevel for ext2 which I would be inclined to do. Kirk McKusick From bugmaster at FreeBSD.org Mon Jun 9 11:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 9 11:07:11 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200806091106.m59B6wkV070727@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- 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 6 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 6 problems total. From jhs at berklix.org Tue Jun 10 08:15:36 2008 From: jhs at berklix.org (Julian Stacey) Date: Tue Jun 10 08:15:41 2008 Subject: CFS Cryptographic file system. Message-ID: <200806100753.m5A7rFIY079040@fire.js.berklix.net> fs@freebsd, I asked on ports@ > Is there some replacement of /usr/ports/security/cfs > (encryped file system) for 7.0 ? But maybe wrong list to ask on ? Is a crypting file system being worked on for src/ somewhere ? Or is fixing ports/security/cfs the way to go ? Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail just Ascii plain text. HTML & Base64 text are spam. From jhs at berklix.org Tue Jun 10 11:21:24 2008 From: jhs at berklix.org (Julian Stacey) Date: Tue Jun 10 11:21:29 2008 Subject: CFS Cryptographic file system. In-Reply-To: Your message "Tue, 10 Jun 2008 13:11:50 +0200." Message-ID: <200806101120.m5ABKWtY005301@fire.js.berklix.net> Reference: > From: Lorenzo Perone > Date: Tue, 10 Jun 2008 13:11:50 +0200 > Message-id: Lorenzo Perone wrote: > On 10.06.2008, at 09:53, Julian Stacey wrote: > > > Is a crypting file system being worked on for src/ somewhere ? > > Did you have a look at gbde / geli? > > http://www.freebsd.org/doc/en/books/handbook/disks-encrypting.html No, (I did have a look at doc index before I posted, but I missed this). Looks like what I need. Thanks Lorenzo Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail just Ascii plain text. HTML & Base64 text are spam. From lopez.on.the.lists at yellowspace.net Tue Jun 10 11:22:07 2008 From: lopez.on.the.lists at yellowspace.net (Lorenzo Perone) Date: Tue Jun 10 11:22:12 2008 Subject: CFS Cryptographic file system. In-Reply-To: <200806100753.m5A7rFIY079040@fire.js.berklix.net> References: <200806100753.m5A7rFIY079040@fire.js.berklix.net> Message-ID: On 10.06.2008, at 09:53, Julian Stacey wrote: > Is a crypting file system being worked on for src/ somewhere ? Did you have a look at gbde / geli? http://www.freebsd.org/doc/en/books/handbook/disks-encrypting.html Regards, Lorenzo From amdmi3 at amdmi3.ru Wed Jun 11 01:31:27 2008 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed Jun 11 01:31:31 2008 Subject: ZFS, async-like per-filesystem option Message-ID: <20080611004019.GA1119@hades.panopticon> Hi! There are cases when you don't care about safeness and integrity of your files at all, but still you need to store them on hdd. The example is massive ports building: I use WRKDIRPREFIX=/usr/work so all workdirs reside in the same place, and I absolutely don't care if I lose the whole directory on blackout. Still I can't use md(4) or tmpfs for it, as those are limited by memory+swap sizes, and, having 2Gb mem + 2Gb swap I'm likely to run out of space. Using ZFS for /usr/work makes my disks make horrible noise during build, and I can also guess that performance drops significantly because processes are likely to wait more time to read from disk, thus 2 CPU cures are not 100% loaded most time with 3 parallel builds. As ZFS heavily uses caching, I thought that it may be ideal solution if it had something like `async' (or more corretly, `nosync') property for filesysems. Turning it on will make specific filesystem completely ignore fsync() calls, so files will stay in memory until they are pushed out of cache by newer/more recently used/more frequently used data. That should reduce disk load, increase performance and free me from thinking how much size I need for md(4). So, my questions are: - Is something like that planned or already implemented upstream? - How hard would it be to implement it? The easy way seems to make zfs_freebsd_fsync() no-op, but I'm not sure of side-effects. The correct way I guess is to bypass ZIL conditionally. -- Dmitry A. Marakasov | jabber: amdmi3@jabber.ru amdmi3@amdmi3.ru | http://www.amdmi3.ru From nike_d at cytexbg.com Wed Jun 11 08:19:49 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Wed Jun 11 08:19:53 2008 Subject: ZFS, async-like per-filesystem option In-Reply-To: <20080611004019.GA1119@hades.panopticon> References: <20080611004019.GA1119@hades.panopticon> Message-ID: <2e77fc10806110119r39cf3725u610887954326955b@mail.gmail.com> On Wed, Jun 11, 2008 at 3:40 AM, Dmitry Marakasov wrote: > Hi! > > There are cases when you don't care about safeness and integrity > of your files at all, but still you need to store them on hdd. The > example is massive ports building: I use WRKDIRPREFIX=/usr/work so > all workdirs reside in the same place, and I absolutely don't care > if I lose the whole directory on blackout. Still I can't use md(4) > or tmpfs for it, as those are limited by memory+swap sizes, and, > having 2Gb mem + 2Gb swap I'm likely to run out of space. Using > ZFS for /usr/work makes my disks make horrible noise during build, > and I can also guess that performance drops significantly because > processes are likely to wait more time to read from disk, thus 2 CPU > cures are not 100% loaded most time with 3 parallel builds. > > As ZFS heavily uses caching, I thought that it may be ideal solution > if it had something like `async' (or more corretly, `nosync') property > for filesysems. Turning it on will make specific filesystem completely > ignore fsync() calls, so files will stay in memory until they are pushed > out of cache by newer/more recently used/more frequently used data. > That should reduce disk load, increase performance and free me from > thinking how much size I need for md(4). > > So, my questions are: > - Is something like that planned or already implemented upstream? > > - How hard would it be to implement it? The easy way seems to make > zfs_freebsd_fsync() no-op, but I'm not sure of side-effects. The > correct way I guess is to bypass ZIL conditionally. > > -- > Dmitry A. Marakasov | jabber: amdmi3@jabber.ru > amdmi3@amdmi3.ru | http://www.amdmi3.ru Hi, You can try to disable ZIL with the following sysctl : vfs.zfs.zil_disable But this will disable it completely, not only for given pool/dataset Regards, Niki From jhs at berklix.org Wed Jun 11 21:52:06 2008 From: jhs at berklix.org (Julian Stacey) Date: Wed Jun 11 21:52:11 2008 Subject: CFS Cryptographic file system. In-Reply-To: Your message "Wed, 11 Jun 2008 14:00:55 EDT." <485012D7.6060107@queue.to> Message-ID: <200806112151.m5BLpFKK055158@fire.js.berklix.net> To: Howard Goldstein , Lorenzo Perone cc: fs@freebsd.org bcc: freebsd-ports@freebsd.org (bcc to avoid list dups, any follow up to fs@ I suggest) Howard Goldstein wrote: > Date: Wed, 11 Jun 2008 14:00:55 -0400 (20:00 CEST) > Cc: freebsd-ports@freebsd.org > Julian Stacey wrote: > > Is there some replacement of /usr/ports/security/cfs > > (encryped file system) for 7.0 ? > > It's not fully responsive to your question, and it's a little clunky, > but the technique at this blog entry > https://www.endries.org/josh/blog/posts/5 seems to show a way to run > geli on a file-based backingstore using the the md driver as a geom > provider. I haven't tried it. Thanks Howard, As I was in a rush & no quick reply to ports@, I posted a similar question to fs@freebsd 12 hours or so later & later replied: > > From: Lorenzo Perone > > Date: Tue, 10 Jun 2008 13:11:50 +0200 > > To: Julian Stacey > > Cc: fs@freebsd.org > > > Is a crypting file system being worked on for src/ somewhere ? > > > > Did you have a look at gbde / geli? > > > > http://www.freebsd.org/doc/en/books/handbook/disks-encrypting.html > > No, (I did have a look at doc index before I posted, but I missed this). > Looks like what I need. > Thanks Lorenzo So I did this, which worked: dd if=/dev/zero of=CRYPT_FS_IMAGE bs=10k count=50k mdconfig -a -t vnode -f CRYPT_FS_IMAGE mkdir /etc/gbde gbde init /dev/md0 -i -L /etc/gbde/md0.lock 2048 random_flush uncommented # long wait gbde attach /dev/md0 -l /etc/gbde/md0.lock newfs -U -O2 /dev/md0.bde mount /dev/md0.bde /mnt .... umount /mnt gbde detach md0 mdconfig -d -u 0 I havent tried geli yet, though it has interesting extras for later. Thanks Lorenzo & Howard. Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail just Ascii plain text. HTML & Base64 text are spam. From patpro at patpro.net Fri Jun 13 13:31:27 2008 From: patpro at patpro.net (Patrick Proniewski) Date: Fri Jun 13 13:31:31 2008 Subject: freebsd boot manager Message-ID: <396AA358-5DB7-4182-8FCC-D6AA80B542A7@patpro.net> Hello, I'm running FreeBSD 6.3 on intel. My box has 2 HDs (SATA). FreeBSD is installed on the first SATA HD. At boot time, I'm prompted with the FreeBSD bootmanager interface (F1 : FreeBSD, F5 : Drive 1) I have plugged a CF card on a dedicated slot of the motherboard (Tyan i7520SD), and installed a nanoBSD on this compact flash card. Now I want many things: - being able to choose between my SATA bootable HD and the CF, at boot time, whatever system was previously booted (SATA or CF) - the box must always boot by default on the SATA HD - in case SATA is not available (HD failure, ...), the box must boot on the CF card. So my first question is: is it possible? My second question is: how do I make this happen? I can't find any relevant explanation about manipulations/settings of the FreeBSD bootmanager, and I've asked my questions on french usenet group with no luck, so I'm quite lost. Any help greatly appreciated. patpro From lists.freebsd.org at sbeh.de Fri Jun 13 16:04:01 2008 From: lists.freebsd.org at sbeh.de (Stan Behrens) Date: Fri Jun 13 16:04:04 2008 Subject: freebsd boot manager In-Reply-To: <396AA358-5DB7-4182-8FCC-D6AA80B542A7@patpro.net> References: <396AA358-5DB7-4182-8FCC-D6AA80B542A7@patpro.net> Message-ID: <4852942E.6050309@sbeh.de> Hello Mr. Proniewski, enabling Legacy-USB-Mode in BIOS should give you an additional 'HDD' (CF) to boot from. I'm sorry, I don't know how to specify fallback-devices in FBSD's Bootloader, you can use grub from ports instead, which has the ability to fallback on another device. Regards, Stan Behrens. From patpro at patpro.net Fri Jun 13 17:01:47 2008 From: patpro at patpro.net (Patrick Proniewski) Date: Fri Jun 13 17:01:54 2008 Subject: freebsd boot manager In-Reply-To: <4852942E.6050309@sbeh.de> References: <396AA358-5DB7-4182-8FCC-D6AA80B542A7@patpro.net> <4852942E.6050309@sbeh.de> Message-ID: Stan, thank you for your reply On 13 juin 2008, at 17:37, Stan Behrens wrote: > enabling Legacy-USB-Mode in BIOS should give you an additional > 'HDD' (CF) to boot from. May be I'm missing something here, because I don't see any relation between USB and the CF card. I should have mentioned that my CF card is plugged in a dedicated CF slot on the motherboard. It's on a UDMA bus: CF card: ad0: 1953MB at ata0-master UDMA66 SATA #1 (boot): ad4: 239372MB at ata2-master SATA150 SATA #2: ad6: 239372MB at ata3-master SATA150 > I'm sorry, I don't know how to specify fallback-devices in FBSD's > Bootloader, you can use grub from ports instead, which has the > ability to fallback on another device. If I want to go with grub, should I install it on both systems ? (FreeBSD on ad4 and nanoBSD on ad0) thanks, patpro From randy at psg.com Sat Jun 14 01:40:22 2008 From: randy at psg.com (Randy Bush) Date: Sat Jun 14 01:40:24 2008 Subject: zfs dump to non-zfs host Message-ID: <48532183.2040306@psg.com> currently, my dump server is a large non-zfs raid to which i use dump over ssh to a remote host, as in /sbin/dump 0Luaf - /dev/twed0s1a | $SSH $BSYS "/bin/cat > $DDIR/base" now i have a zfs host that i want to dump to this server. yes, i know i can snapshot on the zfs system itself. but what if it goes completely dead? it is in an earthquake zone, ... /sbin/dump does not work, of course. files created with zsend might not be decodable in a future version, so i can not zsend | to it. clue bat, please. randy From lists at thefrog.net Sun Jun 15 17:23:42 2008 From: lists at thefrog.net (Andrew Hill) Date: Sun Jun 15 17:23:46 2008 Subject: raidz vdev marked faulted with only one faulted disk Message-ID: <16a6ef710806151023y58bd905dr3671e76c71aa1f4d@mail.gmail.com> i'm a bit lost here as to exactly what's gone wrong - it seems like it may be a bug in zfs but also entirely likely i'm assuming something i shoudln't or am just not using the zfs tools properly (i rather hope its the latter...) background: i had a system running with 4 zpools. the two that are relevant to this issue are the raidz volumes: - 1x zpool (tank) consisting of a raidz vdev consisting of 7x250 GB slices (each slice on a separate disk) - 1x zpool (tank2) consisting of a raidz vdev consisting of 3x70 GB slices (again, separate disks from each other, but these are slices on the same disks as the other raidz vdev) (this is a cheap home system built out of parts lying around, basically intended to get a lot of storage space out of a bunch of disks with little concern for performance, so no need to point out these problems) the system was originally installed on a ufs partition then migrated onto a raidz zpool (so i was using the kernel and /boot from the ufs drive still, but the system root was on raidz), apart from well-known deadlocks and panics here and there, it generally worked well enough (uptimes of a week or so if i wasn't actively trying to trigger a deadlock/panic) problem: a couple of weeks ago, it completely stopped being able to mount root from zfs, so i booted back into the old ufs partition (which still had whatever world was originally installed on there from my 7.0-release amd64 CD but with an up-to-date -stable kernel) and i discovered that one of my disks (ad12) was now FAULTED. this is one of the disks that affects both raidz vdevs mentioned above (i.e. it has a 250gb slice in tank and a 70gb slice in tank2) so both raidz vdevs were effectively missing one disk device, but both should be able to handle this type of failure... right? i've not yet looked too far into the cause of the failure, though my guess is it relates to the silicon image sil3114 controller that disk was attached to (mainly due to the repuatation those controllers have) though for now i'm trying to figure out the other major issue... from 'zpool import' i can see that this disk (ad12) is marked "FAULTED corrupted data" in the list of 7 drives in tank (i.e. ad12s1d), and the list of 3 drives in tank2 (ad12s1e). in both zpools, the raidz vdev and the whole zpool is then marked "FAULTED corrupted data", despite only one disk in the raidz being FAULTED - my understanding is that it should be DEGRADED... right? example output showing tank2: gutter# zpool import pool: tank2 id: 8036862119610852708 state: FAULTED status: The pool was last accessed by another system. action: The pool cannot be imported due to damaged devices or data. The pool may be active on on another system, but can be imported using the '-f' flag. see: http://www.sun.com/msg/ZFS-8000-EY config: tank2 FAULTED corrupted data raidz1 FAULTED corrupted data ad8s1e ONLINE ad10s1e ONLINE ad12s1e FAULTED corrupted data tank2 is/was a zpool created as a single raidz vdev of 3 slices as shown above, so it seems like the failure/loss of one disk shouldn't be causing it to get marked FAULTED. tank is the same but with 7 drives (6 ONLINE, 1 FAULTED)... since the zpools were never exported (i'm unable to mount the root file system on the zpool to export either of them...) they obviously show up the errors above about being last accessed by another system, so attempting to override that (zpool import -f tank or tank2) gives the following messages on the console: ZFS: vdev failure, zpool=tank2 type=vdev.no_replicas ZFS: failed to load zpool tank2 cannot import 'tank2': permission denied when i first booted into the old ufs drive that the zpools were created from, they showed up on that system in zpool list (since they'd not been exported after i set it up to use one as the root fs), and zpool status told me to see: http://www.sun.com/msg/ZFS-8000-5E, which is about zpools that have a faulted device and no redundancy - *very* odd to see on a raidz vdev i've also tried completely removing the faulted disk with no better result, and removing two drives causes it to show up as UNAVAIL (as expected) or a "panic: dangling dbufs" when i try to 'zpool import', though i suspect this might be memory related (i've also been trying all of this on a second motherboard, which i can only supply with 512 MB RAM) i've tried various different combinations - hardware - two different motherboards (with different cpu and ram, the only thing common to all systems is a new sata controller - promise chip PDC20376 - to replace the silicon image sata controller so that i can put all 7 drives into the system) - software - a fresh FreeBSD install on a new hard drive (from a 7.0 i386 CD i downloaded about 3 months ago, and then again after updating to the latest -stable source), as well as the system i mentioned earlier on my boot/kernel drive, which had the latest amd64 kernel built on my zfs system but hadn't had the userland updated since 7.0 amd64 install) when i first set up the system, i tested out the behaviour of removing a drive from a raidz vdev, and definitely saw it enter the DEGRADED state, though i did not try exporting and re-importing in this state, but according to the sun zfs documentation this should be possible (i realise this doesn't mean its in the bsd port, but i've not found anything to confirm this specifically is/isn't possible) so my question is - is this a bug in zfs that is causing the raidz to be faulted when one device is faulted/corrupted (would have to be under specific conditions, since raidz vdevs can definitely go between DEGRADED and ONLINE states just fine in general), or am i misusing the zfs utilities or making invalid assumptions, e.g. is there some other method of importing or perhaps scrubbing/resilvering prior to importing that i'm missing? Andrew From kris at FreeBSD.org Sun Jun 15 17:59:21 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jun 15 17:59:24 2008 Subject: zfs dump to non-zfs host In-Reply-To: <48532183.2040306@psg.com> References: <48532183.2040306@psg.com> Message-ID: <48555878.9070301@FreeBSD.org> Randy Bush wrote: > currently, my dump server is a large non-zfs raid to which i use dump > over ssh to a remote host, as in > > /sbin/dump 0Luaf - /dev/twed0s1a | $SSH $BSYS "/bin/cat > $DDIR/base" > > now i have a zfs host that i want to dump to this server. yes, i know i > can snapshot on the zfs system itself. but what if it goes completely > dead? it is in an earthquake zone, ... > > /sbin/dump does not work, of course. > > files created with zsend might not be decodable in a future version, so > i can not zsend | to it. If this is the case then presumably there will be a migration tool. zfs sending to a file is the officially recommended method. Kris From randy at psg.com Sun Jun 15 18:37:21 2008 From: randy at psg.com (Randy Bush) Date: Sun Jun 15 18:37:22 2008 Subject: zfs dump to non-zfs host In-Reply-To: <48555878.9070301@FreeBSD.org> References: <48532183.2040306@psg.com> <48555878.9070301@FreeBSD.org> Message-ID: <4855615E.6070603@psg.com> >> files created with zsend might not be decodable in a future version, so >> i can not zsend | to it. > If this is the case then presumably there will be a migration tool. zfs > sending to a file is the officially recommended method. that would be alright. but the man page is pretty direct, brutal, and negative; > The format of the stream is evolving. No backwards compatibility is > guaranteed. You may not be able to receive your streams on future ver- > sions of ZFS. this is not very reassuring. randy From koitsu at FreeBSD.org Sun Jun 15 19:27:50 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 15 19:27:54 2008 Subject: zfs dump to non-zfs host In-Reply-To: <48532183.2040306@psg.com> References: <48532183.2040306@psg.com> Message-ID: <20080615192750.GA14559@eos.sc1.parodius.com> On Sat, Jun 14, 2008 at 10:40:19AM +0900, Randy Bush wrote: > currently, my dump server is a large non-zfs raid to which i use dump > over ssh to a remote host, as in > > /sbin/dump 0Luaf - /dev/twed0s1a | $SSH $BSYS "/bin/cat > $DDIR/base" > > now i have a zfs host that i want to dump to this server. yes, i know i > can snapshot on the zfs system itself. but what if it goes completely > dead? it is in an earthquake zone, ... > > /sbin/dump does not work, of course. > > files created with zsend might not be decodable in a future version, so > i can not zsend | to it. The only two options I see are "zfs send" (which you've covered), and using rsync for that host. We switched to rsync exclusively (regardless of fuilesystem) due to dump -L becoming slower and slower over time on UFS2 filesystems (a known problem), plus more or less deadlocking the system while it makes the snapshot. -- | 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 kris at FreeBSD.org Sun Jun 15 20:02:36 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jun 15 20:02:39 2008 Subject: zfs dump to non-zfs host In-Reply-To: <4855615E.6070603@psg.com> References: <48532183.2040306@psg.com> <48555878.9070301@FreeBSD.org> <4855615E.6070603@psg.com> Message-ID: <4855755C.6010201@FreeBSD.org> Randy Bush wrote: >>> files created with zsend might not be decodable in a future version, so >>> i can not zsend | to it. >> If this is the case then presumably there will be a migration tool. zfs >> sending to a file is the officially recommended method. > > that would be alright. but the man page is pretty direct, brutal, and > negative; > >> The format of the stream is evolving. No backwards compatibility is >> guaranteed. You may not be able to receive your streams on future ver- >> sions of ZFS. > > this is not very reassuring. You'll have to take this up with the ZFS developers. Kris From gavin at FreeBSD.org Mon Jun 16 00:04:33 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Jun 16 00:04:35 2008 Subject: kern/124621: [ext3] Cannot mount ext2fs partition Message-ID: <200806160004.m5G04Xq1091245@freefall.freebsd.org> Old Synopsis: Cannot mount ext2fs partition New Synopsis: [ext3] Cannot mount ext2fs partition Responsible-Changed-From-To: freebsd-i386->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Mon Jun 16 00:03:20 UTC 2008 Responsible-Changed-Why: This doesn't sound -i386 specific http://www.freebsd.org/cgi/query-pr.cgi?pr=124621 From cracauer at cons.org Mon Jun 16 04:00:29 2008 From: cracauer at cons.org (Martin Cracauer) Date: Mon Jun 16 04:00:33 2008 Subject: infinite loop when copying to ext2fs In-Reply-To: <47C9C912.1020700@FreeBSD.org> References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> Message-ID: <20080616034258.GA94873@cons.org> Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: > Jakub Siroky wrote: > >I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I > >did not noticed it before because I started using ext2fs extensively > >some months ago. > > > >Regards, > >Jakub > > > >On Sat, 19 Jan 2008 16:44:34 +0100 > >Kris Kennaway wrote: > > > >>Kris Kennaway wrote: > >>>Jakub Siroky wrote: > >>>>I have two large ext2fs partitions (368 and 313GB) to hold data > >>>>shared between several OSes. While there were no problems on > >>>>6-STABLE branch I was quite disappointed after upgrade to > >>>>7-STABLE. Whenever I copy/write to ext2fs partition the system > >>>>freezes totally without crashdump. So I set debugging settings to > >>>>kernel config (DEBUG,WITNESS,..) and in console I reproduced error > >>>>situation ending with full screen of unstoppable running text with > >>>>lot of memory addresses and a few recognisable words: 'new block > >>>>bit set for ext already' - again with no crashdump. Then I have > >>>>formatted 1GB partition with ext2fs and the problem on this small > >>>>partition appears only sometimes. > >>>OK, I am able to reproduce this. > >>> > >>>Kris > >>> > >>Is anyone able to look at this? I could not spot a candidate change > >>that has not been merged to 6.x. > >> > >>Kris > > > > > > Sounds like it may have been broken by the change to ext2_bitops.h by > cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? I don't think my change can cause a new endless loop. I only reversed the order of tests to ensure we don't overrun a page bounddary (into possibly unmapped space). - while(*p == ~0U && ofs < sz) { + while(ofs < sz && *p == ~0U) { It is, however, likely that the code was buggy in the first place. Linux has replaced all this (the allocation code). Also note that the code I fixed is amd64 only. If the endless loop appears on i386 it's something else. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From kris at FreeBSD.org Mon Jun 16 09:27:57 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Jun 16 09:28:00 2008 Subject: infinite loop when copying to ext2fs In-Reply-To: <20080616034258.GA94873@cons.org> References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> <20080616034258.GA94873@cons.org> Message-ID: <48563219.9070306@FreeBSD.org> Martin Cracauer wrote: > Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: >> Jakub Siroky wrote: >>> I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I >>> did not noticed it before because I started using ext2fs extensively >>> some months ago. >>> >>> Regards, >>> Jakub >>> >>> On Sat, 19 Jan 2008 16:44:34 +0100 >>> Kris Kennaway wrote: >>> >>>> Kris Kennaway wrote: >>>>> Jakub Siroky wrote: >>>>>> I have two large ext2fs partitions (368 and 313GB) to hold data >>>>>> shared between several OSes. While there were no problems on >>>>>> 6-STABLE branch I was quite disappointed after upgrade to >>>>>> 7-STABLE. Whenever I copy/write to ext2fs partition the system >>>>>> freezes totally without crashdump. So I set debugging settings to >>>>>> kernel config (DEBUG,WITNESS,..) and in console I reproduced error >>>>>> situation ending with full screen of unstoppable running text with >>>>>> lot of memory addresses and a few recognisable words: 'new block >>>>>> bit set for ext already' - again with no crashdump. Then I have >>>>>> formatted 1GB partition with ext2fs and the problem on this small >>>>>> partition appears only sometimes. >>>>> OK, I am able to reproduce this. >>>>> >>>>> Kris >>>>> >>>> Is anyone able to look at this? I could not spot a candidate change >>>> that has not been merged to 6.x. >>>> >>>> Kris >>> >> Sounds like it may have been broken by the change to ext2_bitops.h by >> cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? > > I don't think my change can cause a new endless loop. > > I only reversed the order of tests to ensure we don't overrun a page > bounddary (into possibly unmapped space). > > - while(*p == ~0U && ofs < sz) { > + while(ofs < sz && *p == ~0U) { > > It is, however, likely that the code was buggy in the first place. > Linux has replaced all this (the allocation code). > > Also note that the code I fixed is amd64 only. If the endless loop > appears on i386 it's something else. > > Martin It is amd64 only. I am able to reproduce using the method in the original mails, can you? Kris From bugmaster at FreeBSD.org Mon Jun 16 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 16 11:07:21 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200806161106.m5GB6rjQ036696@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- 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 6 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 7 problems total. From cracauer at cons.org Mon Jun 16 12:16:11 2008 From: cracauer at cons.org (Martin Cracauer) Date: Mon Jun 16 12:16:17 2008 Subject: infinite loop when copying to ext2fs In-Reply-To: <48563219.9070306@FreeBSD.org> References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> <20080616034258.GA94873@cons.org> <48563219.9070306@FreeBSD.org> Message-ID: <20080616121609.GA26978@cons.org> Kris Kennaway wrote on Mon, Jun 16, 2008 at 11:27:53AM +0200: > Martin Cracauer wrote: > >Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: > >>Jakub Siroky wrote: > >>>I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I > >>>did not noticed it before because I started using ext2fs extensively > >>>some months ago. > >>> > >>>Regards, > >>>Jakub > >>> > >>>On Sat, 19 Jan 2008 16:44:34 +0100 > >>>Kris Kennaway wrote: > >>> > >>>>Kris Kennaway wrote: > >>>>>Jakub Siroky wrote: > >>>>>>I have two large ext2fs partitions (368 and 313GB) to hold data > >>>>>>shared between several OSes. While there were no problems on > >>>>>>6-STABLE branch I was quite disappointed after upgrade to > >>>>>>7-STABLE. Whenever I copy/write to ext2fs partition the system > >>>>>>freezes totally without crashdump. So I set debugging settings to > >>>>>>kernel config (DEBUG,WITNESS,..) and in console I reproduced error > >>>>>>situation ending with full screen of unstoppable running text with > >>>>>>lot of memory addresses and a few recognisable words: 'new block > >>>>>>bit set for ext already' - again with no crashdump. Then I have > >>>>>>formatted 1GB partition with ext2fs and the problem on this small > >>>>>>partition appears only sometimes. > >>>>>OK, I am able to reproduce this. > >>>>> > >>>>>Kris > >>>>> > >>>>Is anyone able to look at this? I could not spot a candidate change > >>>>that has not been merged to 6.x. > >>>> > >>>>Kris > >>> > >>Sounds like it may have been broken by the change to ext2_bitops.h by > >>cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? > > > >I don't think my change can cause a new endless loop. > > > >I only reversed the order of tests to ensure we don't overrun a page > >bounddary (into possibly unmapped space). > > > >- while(*p == ~0U && ofs < sz) { > >+ while(ofs < sz && *p == ~0U) { > > > >It is, however, likely that the code was buggy in the first place. > >Linux has replaced all this (the allocation code). > > > >Also note that the code I fixed is amd64 only. If the endless loop > >appears on i386 it's something else. > > > >Martin > > It is amd64 only. I am able to reproduce using the method in the > original mails, can you? Didn't try yet, but I did get a probably unrelated panic on ext2fs just last week :-) I'll fire it up this week. How big does the partition have to be to show the problem in this bug? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From kris at FreeBSD.org Mon Jun 16 12:54:05 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Jun 16 12:54:10 2008 Subject: infinite loop when copying to ext2fs In-Reply-To: <20080616121609.GA26978@cons.org> References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> <20080616034258.GA94873@cons.org> <48563219.9070306@FreeBSD.org> <20080616121609.GA26978@cons.org> Message-ID: <48566269.2050001@FreeBSD.org> Martin Cracauer wrote: > Kris Kennaway wrote on Mon, Jun 16, 2008 at 11:27:53AM +0200: >> Martin Cracauer wrote: >>> Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: >>>> Jakub Siroky wrote: >>>>> I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I >>>>> did not noticed it before because I started using ext2fs extensively >>>>> some months ago. >>>>> >>>>> Regards, >>>>> Jakub >>>>> >>>>> On Sat, 19 Jan 2008 16:44:34 +0100 >>>>> Kris Kennaway wrote: >>>>> >>>>>> Kris Kennaway wrote: >>>>>>> Jakub Siroky wrote: >>>>>>>> I have two large ext2fs partitions (368 and 313GB) to hold data >>>>>>>> shared between several OSes. While there were no problems on >>>>>>>> 6-STABLE branch I was quite disappointed after upgrade to >>>>>>>> 7-STABLE. Whenever I copy/write to ext2fs partition the system >>>>>>>> freezes totally without crashdump. So I set debugging settings to >>>>>>>> kernel config (DEBUG,WITNESS,..) and in console I reproduced error >>>>>>>> situation ending with full screen of unstoppable running text with >>>>>>>> lot of memory addresses and a few recognisable words: 'new block >>>>>>>> bit set for ext already' - again with no crashdump. Then I have >>>>>>>> formatted 1GB partition with ext2fs and the problem on this small >>>>>>>> partition appears only sometimes. >>>>>>> OK, I am able to reproduce this. >>>>>>> >>>>>>> Kris >>>>>>> >>>>>> Is anyone able to look at this? I could not spot a candidate change >>>>>> that has not been merged to 6.x. >>>>>> >>>>>> Kris >>>> Sounds like it may have been broken by the change to ext2_bitops.h by >>>> cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? >>> I don't think my change can cause a new endless loop. >>> >>> I only reversed the order of tests to ensure we don't overrun a page >>> bounddary (into possibly unmapped space). >>> >>> - while(*p == ~0U && ofs < sz) { >>> + while(ofs < sz && *p == ~0U) { >>> >>> It is, however, likely that the code was buggy in the first place. >>> Linux has replaced all this (the allocation code). >>> >>> Also note that the code I fixed is amd64 only. If the endless loop >>> appears on i386 it's something else. >>> >>> Martin >> It is amd64 only. I am able to reproduce using the method in the >> original mails, can you? > > Didn't try yet, but I did get a probably unrelated panic on ext2fs > just last week :-) I'll fire it up this week. > > How big does the partition have to be to show the problem in this bug? Sorry, I don't remember. I probably tried it on a md that was a couple of GB. Kris From brooks at freebsd.org Mon Jun 16 16:24:54 2008 From: brooks at freebsd.org (Brooks Davis) Date: Mon Jun 16 16:24:55 2008 Subject: zfs dump to non-zfs host In-Reply-To: <20080615192750.GA14559@eos.sc1.parodius.com> References: <48532183.2040306@psg.com> <20080615192750.GA14559@eos.sc1.parodius.com> Message-ID: <20080616162522.GA31835@lor.one-eyed-alien.net> On Sun, Jun 15, 2008 at 12:27:50PM -0700, Jeremy Chadwick wrote: > On Sat, Jun 14, 2008 at 10:40:19AM +0900, Randy Bush wrote: > > currently, my dump server is a large non-zfs raid to which i use dump > > over ssh to a remote host, as in > > > > /sbin/dump 0Luaf - /dev/twed0s1a | $SSH $BSYS "/bin/cat > $DDIR/base" > > > > now i have a zfs host that i want to dump to this server. yes, i know i > > can snapshot on the zfs system itself. but what if it goes completely > > dead? it is in an earthquake zone, ... > > > > /sbin/dump does not work, of course. > > > > files created with zsend might not be decodable in a future version, so > > i can not zsend | to it. > > The only two options I see are "zfs send" (which you've covered), and > using rsync for that host. We switched to rsync exclusively (regardless > of fuilesystem) due to dump -L becoming slower and slower over time on > UFS2 filesystems (a known problem), plus more or less deadlocking the > system while it makes the snapshot. Clearly someone needs to teach libarchive to speak zfs send-recieve so people can save these things in tarballs. 1/2 :-) -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080616/cd01cacc/attachment.pgp From ernst.winter at t-online.de Tue Jun 17 03:16:27 2008 From: ernst.winter at t-online.de (Ernst W. Winter) Date: Tue Jun 17 03:16:31 2008 Subject: installation of zfs Message-ID: <20080617030034.GA18701@ewinter.org> Hello, can anyone pount me to a document on how to install zfs with FreeBSD? I am a "end user" mainly, but have enough knowledge to perform the installation. Ihave tried it on a external HD a while back and then screwd somewher along the line ans dleted the system again. I only need a plain installation, no Raid or anything like the. The HD is 230GIG and the partitions are at the moment a 4GIG root with a minimal installation and 4GIG for swap. Thanks in advance foir any help. Ernst -- ================================================== Mail just Ascii plain text. HTML & Base64 is spam email = nur reiner Text. HTML & Base64 sind SPAM From mark at legios.org Tue Jun 17 07:05:51 2008 From: mark at legios.org (Mark Gladman(legios.org)) Date: Tue Jun 17 07:05:54 2008 Subject: installation of zfs Message-ID: <30337.150.101.214.246.1213674415.squirrel@legios.org> > Hello, > > can anyone pount me to a document on how to install zfs with > FreeBSD? > > I am a "end user" mainly, but have enough knowledge to perform > the installation. Ihave tried it on a external HD a while back > and then screwd somewher along the line ans dleted the system > again. I only need a plain installation, no Raid or anything like > the. > > The HD is 230GIG and the partitions are at the moment a 4GIG root > with a minimal installation and 4GIG for swap. > > Thanks in advance foir any help. > > Ernst > > -- > ================================================== > Mail just Ascii plain text. HTML & Base64 is spam > email = nur reiner Text. HTML & Base64 sind SPAM > > _______________________________________________ > 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" > > Hey there, http://wiki.freebsd.org/ZFSQuickStartGuide is a good quickstart guide. I also recommend reading through http://wiki.freebsd.org/ZFS for additional information. Cheers, Mark From ernst.winter at t-online.de Tue Jun 17 20:21:15 2008 From: ernst.winter at t-online.de (Ernst W. Winter) Date: Tue Jun 17 20:21:20 2008 Subject: installation of zfs In-Reply-To: <26377.150.101.214.246.1213676733.squirrel@legios.org> References: <26377.150.101.214.246.1213676733.squirrel@legios.org> Message-ID: <20080617202026.GA1997@ewinter.org> On Tue, 17 Jun 2008, Mark Gladman(legios.org) wrote: [cut] > >> Hey there, > >> > >> http://wiki.freebsd.org/ZFSQuickStartGuide is a good quickstart guide. > >> > > Thanks, just had a look and looks good, ecept for this: > > > > zpool create tank raidz da0 da1 da2 > > > > Does it have to have "raidz"? > > > >> I also recommend reading through http://wiki.freebsd.org/ZFS for > >> additional information. > >> > > Thank you, will do that too. > > > > I will have a bit more time this afternoon and then try to get it > > going again as I try to setup with this HD a new one with the new > > kde4. > > > >> Cheers, > > > > Thanks again, > > > >> Mark > >> > > Ernst > > > Hm.. Not sure my messages are actually going to the mailing > list (given you responded and my email hasn't shown up on it > yet). > well this one will. > In any case, no, if you don't want there to be any raid etc. > just an array of disks you can use zpool create tank da0 da1 > da2. (if I remember correctly - I don't have a machine with me > at work I can test it on). > > http://www.freebsd.org/cgi/man.cgi?query=zpool&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html > ans > http://www.freebsd.org/cgi/man.cgi?query=zfs&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html > are fairly digestable too, if you get the chance. > Got it all going and then compiled it all with make buildworld and kernel, when I try to restart in single user mode I don't have the /usr directory. What could have happen? > Cheers! > Mark > Ernst > > -- ================================================== Mail just Ascii plain text. HTML & Base64 is spam email = nur reiner Text. HTML & Base64 sind SPAM From koitsu at FreeBSD.org Tue Jun 17 21:32:18 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jun 17 21:32:22 2008 Subject: installation of zfs In-Reply-To: <20080617202026.GA1997@ewinter.org> References: <26377.150.101.214.246.1213676733.squirrel@legios.org> <20080617202026.GA1997@ewinter.org> Message-ID: <20080617213218.GA27283@eos.sc1.parodius.com> On Tue, Jun 17, 2008 at 10:20:26PM +0200, Ernst W. Winter wrote: > On Tue, 17 Jun 2008, Mark Gladman(legios.org) wrote: > > [cut] > > >> Hey there, > > >> > > >> http://wiki.freebsd.org/ZFSQuickStartGuide is a good quickstart guide. > > >> > > > Thanks, just had a look and looks good, ecept for this: > > > > > > zpool create tank raidz da0 da1 da2 > > > > > > Does it have to have "raidz"? > > > > > >> I also recommend reading through http://wiki.freebsd.org/ZFS for > > >> additional information. > > >> > > > Thank you, will do that too. > > > > > > I will have a bit more time this afternoon and then try to get it > > > going again as I try to setup with this HD a new one with the new > > > kde4. > > > > > >> Cheers, > > > > > > Thanks again, > > > > > >> Mark > > >> > > > Ernst > > > > > Hm.. Not sure my messages are actually going to the mailing > > list (given you responded and my email hasn't shown up on it > > yet). > > > well this one will. > > > In any case, no, if you don't want there to be any raid etc. > > just an array of disks you can use zpool create tank da0 da1 > > da2. (if I remember correctly - I don't have a machine with me > > at work I can test it on). > > > > http://www.freebsd.org/cgi/man.cgi?query=zpool&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html > > ans > > http://www.freebsd.org/cgi/man.cgi?query=zfs&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html > > are fairly digestable too, if you get the chance. > > > Got it all going and then compiled it all with make buildworld > and kernel, when I try to restart in single user mode I don't > have the /usr directory. What could have happen? You'll need to mount -a once in single-user to get all of your filesystems. Unless you're referring to /usr being on ZFS, which in that case you'll need to run "/etc/rc.d/hostid start", then "/etc/rc.d/zfs start". Your pools should load automatically. -- | 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 randy at psg.com Tue Jun 17 21:34:35 2008 From: randy at psg.com (Randy Bush) Date: Tue Jun 17 21:34:38 2008 Subject: installation of zfs In-Reply-To: <20080617213218.GA27283@eos.sc1.parodius.com> References: <26377.150.101.214.246.1213676733.squirrel@legios.org> <20080617202026.GA1997@ewinter.org> <20080617213218.GA27283@eos.sc1.parodius.com> Message-ID: <48582DE7.4010009@psg.com> > Unless you're referring to /usr being on ZFS, which in that case you'll > need to run "/etc/rc.d/hostid start", then "/etc/rc.d/zfs start". Your > pools should load automatically. iff you did setmountpoint randyu From edwin at mavetju.org Tue Jun 17 22:39:43 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Tue Jun 17 22:39:47 2008 Subject: CFS Cryptographic file system. In-Reply-To: <200806100753.m5A7rFIY079040@fire.js.berklix.net> Message-ID: <20080617222227.GA87804@k7.mavetju> > Is there some replacement of /usr/ports/security/cfs > (encryped file system) for 7.0 ? Call me a slacker, but I got them from somebody else but never commited them. I never tested them, because I got it working with my own patches. Give it a try, if it works then I'll commit it. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ -------------- next part -------------- cvs diff: Diffing . Index: patch-cfs__fh.c =================================================================== RCS file: /home/pcvs/ports/security/cfs/files/patch-cfs__fh.c,v retrieving revision 1.1 diff -u -r1.1 patch-cfs__fh.c --- patch-cfs__fh.c 12 Apr 2005 09:06:25 -0000 1.1 +++ patch-cfs__fh.c 18 Nov 2007 03:56:08 -0000 @@ -1,9 +1,16 @@ +$FreeBSD$ -$FreeBSD: ports/security/cfs/files/patch-cfs__fh.c,v 1.1 2005/04/12 09:06:25 flz Exp $ - ---- cfs_fh.c.orig -+++ cfs_fh.c -@@ -61,7 +61,7 @@ +--- cfs_fh.c.orig Thu May 3 11:24:59 2001 ++++ cfs_fh.c Sat Nov 17 19:43:36 2007 +@@ -43,6 +43,7 @@ + #ifdef NO_UTIMES + #include + #endif ++#include + + #include "nfsproto.h" + #include "admproto.h" +@@ -61,7 +62,7 @@ } #endif @@ -12,7 +19,7 @@ int inst = 0;/* starting point */ instance *instances[NINSTANCES]; -@@ -135,7 +135,6 @@ +@@ -135,7 +136,6 @@ int headlen; int writemore=0; struct stat sb; @@ -20,7 +27,7 @@ char buf[8216]; /* big enough, may not even need it */ /* first, normalize to the proper boundries */ -@@ -763,7 +762,7 @@ +@@ -763,7 +763,7 @@ char vect[9]; union{ u_char ch[9]; @@ -29,7 +36,7 @@ } buf; char linkname[NFS_MAXPATHLEN+1]; -@@ -792,8 +791,8 @@ +@@ -792,8 +792,8 @@ /* sprintf((char *)buf,"%08x",(u_long)sb.st_ino+(u_long)sb.st_ctime); */ @@ -40,7 +47,7 @@ q_block_cipher("fixedkey",&buf,1); /* des is just used here as a hash fn to spread the bits */ /* since we only use 32 bits of the result, its a nonperfect */ -@@ -908,7 +907,7 @@ +@@ -908,7 +908,7 @@ f->name=NULL; } } else { @@ -49,7 +56,7 @@ fprintf(stderr,"cfsd: out of memory\n"); cfserrno=NFSERR_STALE; /* bad news */ return -2; -@@ -1146,7 +1145,7 @@ +@@ -1146,7 +1146,7 @@ break anything */ struct dirent * rootrd(cookie) @@ -58,7 +65,7 @@ { static struct dirent d; -@@ -1198,7 +1197,7 @@ +@@ -1198,7 +1198,7 @@ #endif /* SHORTLINKS */ )) == NULL) { if ((f=(cfs_fileid *) Index: patch-cfs__nfs.c =================================================================== RCS file: /home/pcvs/ports/security/cfs/files/patch-cfs__nfs.c,v retrieving revision 1.1 diff -u -r1.1 patch-cfs__nfs.c --- patch-cfs__nfs.c 12 Apr 2005 09:06:25 -0000 1.1 +++ patch-cfs__nfs.c 18 Nov 2007 03:56:08 -0000 @@ -1,9 +1,170 @@ -$FreeBSD: ports/security/cfs/files/patch-cfs__nfs.c,v 1.1 2005/04/12 09:06:25 flz Exp $ +$FreeBSD$ ---- cfs_nfs.c.orig -+++ cfs_nfs.c -@@ -877,12 +877,11 @@ +--- cfs_nfs.c.orig Sun Dec 24 22:24:31 1995 ++++ cfs_nfs.c Sat Nov 17 19:43:00 2007 +@@ -33,6 +33,7 @@ + #else + #include + #endif ++#include + #include "nfsproto.h" + #include "admproto.h" + #include "cfs.h" +@@ -58,7 +59,7 @@ + } + + void * +-nfsproc_null_2(ap,rp) ++nfsproc_null_2_svc(ap,rp) + void *ap; + SR rp; + { +@@ -72,7 +73,7 @@ + readdirres *rootreaddir(); + + attrstat * +-nfsproc_getattr_2(ap,rp) ++nfsproc_getattr_2_svc(ap,rp) + nfs_fh *ap; + SR rp; + { +@@ -118,7 +119,7 @@ + } + + attrstat * +-nfsproc_setattr_2(ap,rp) ++nfsproc_setattr_2_svc(ap,rp) + sattrargs *ap; + SR rp; + { +@@ -168,7 +169,7 @@ + } + + void * +-nfsproc_root_2(ap,rp) ++nfsproc_root_2_svc(ap,rp) + void *ap; + SR rp; + { +@@ -179,7 +180,7 @@ + + /* fix this to deal w/ fs root (instance root should be ok) */ + diropres * +-nfsproc_lookup_2(ap,rp) ++nfsproc_lookup_2_svc(ap,rp) + diropargs *ap; + SR rp; + { +@@ -258,7 +259,7 @@ + } + + readlinkres * +-nfsproc_readlink_2(ap,rp) ++nfsproc_readlink_2_svc(ap,rp) + nfs_fh *ap; + SR rp; + { +@@ -309,7 +310,7 @@ + + + readres * +-nfsproc_read_2(ap,rp) ++nfsproc_read_2_svc(ap,rp) + readargs *ap; + SR rp; + { +@@ -370,7 +371,7 @@ + + + void * +-nfsproc_writecache_2(ap,rp) ++nfsproc_writecache_2_svc(ap,rp) + void *ap; + SR rp; + { +@@ -381,7 +382,7 @@ + + + attrstat * +-nfsproc_write_2(ap,rp) ++nfsproc_write_2_svc(ap,rp) + writeargs *ap; + SR rp; + { +@@ -442,7 +443,7 @@ + + + diropres * +-nfsproc_create_2(ap,rp) ++nfsproc_create_2_svc(ap,rp) + createargs *ap; + SR rp; + { +@@ -545,7 +546,7 @@ + + + nfsstat * +-nfsproc_remove_2(ap,rp) ++nfsproc_remove_2_svc(ap,rp) + diropargs *ap; + SR rp; + { +@@ -587,7 +588,7 @@ + + + nfsstat * +-nfsproc_rename_2(ap,rp) ++nfsproc_rename_2_svc(ap,rp) + renameargs *ap; + SR rp; + { +@@ -643,7 +644,7 @@ + + + nfsstat * +-nfsproc_link_2(ap,rp) ++nfsproc_link_2_svc(ap,rp) + linkargs *ap; + SR rp; + { +@@ -694,7 +695,7 @@ + + + nfsstat * +-nfsproc_symlink_2(ap,rp) ++nfsproc_symlink_2_svc(ap,rp) + symlinkargs *ap; + SR rp; + { +@@ -743,7 +744,7 @@ + } + + diropres * +-nfsproc_mkdir_2(ap,rp) ++nfsproc_mkdir_2_svc(ap,rp) + createargs *ap; + SR rp; + { +@@ -817,7 +818,7 @@ + + + nfsstat * +-nfsproc_rmdir_2(ap,rp) ++nfsproc_rmdir_2_svc(ap,rp) + diropargs *ap; + SR rp; + { +@@ -864,7 +865,7 @@ + /* #define cfsclosedir(x) fhclosedir(x) */ + + readdirres * +-nfsproc_readdir_2(ap,rp) ++nfsproc_readdir_2_svc(ap,rp) + readdirargs *ap; + SR rp; + { +@@ -877,12 +878,11 @@ static DIR *dp=NULL; static struct dirent *dent; entry **prev; @@ -18,7 +179,7 @@ int eof; int ne; int bytes; -@@ -944,7 +943,7 @@ +@@ -944,7 +944,7 @@ else if (strcmp(s,"..")==0) /* parent */ entrytab[ne].fileid=fhpid(h); else entrytab[ne].fileid=dent->d_fileno; @@ -27,7 +188,7 @@ *prev = &entrytab[ne]; prev = &entrytab[ne].nextentry; entrytab[ne].nextentry=NULL; -@@ -964,12 +963,12 @@ +@@ -964,12 +964,12 @@ DIR *curdir; int curdirid=0; @@ -42,7 +203,16 @@ { DIR *ret; DIR *fhopendir(); -@@ -1151,7 +1150,7 @@ +@@ -991,7 +991,7 @@ + } + + statfsres * +-nfsproc_statfs_2(ap,rp) ++nfsproc_statfs_2_svc(ap,rp) + nfs_fh *ap; + SR rp; + { +@@ -1151,7 +1151,7 @@ typedef char str[NFS_MAXNAMLEN+1]; static str names[MAXENTRIES]; entry **prev; @@ -51,7 +221,7 @@ int eof; int ne; int bytes; -@@ -1163,7 +1162,7 @@ +@@ -1163,7 +1163,7 @@ ne=0; prev= &ret.readdirres_u.reply.entries; *prev=NULL; @@ -60,7 +230,7 @@ eof=1; ret.status=NFS_OK; -@@ -1182,7 +1181,7 @@ +@@ -1182,7 +1182,7 @@ else entrytab[ne].fileid=dent->d_fileno; cookie=dent->d_reclen; /* may not work everywhere */ *prev = &entrytab[ne]; Index: patch-cfs_adm.c =================================================================== RCS file: patch-cfs_adm.c diff -N patch-cfs_adm.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ patch-cfs_adm.c 18 Nov 2007 03:56:08 -0000 @@ -0,0 +1,35 @@ + +$FreeBSD$ + +--- cfs_adm.c.orig Mon Dec 25 01:41:30 1995 ++++ cfs_adm.c Sat Nov 17 19:44:35 2007 +@@ -36,14 +36,14 @@ + } + + void * +-admproc_null_2() ++admproc_null_2_svc(void *v, SR rp) + { + } + + cfsstat * +-admproc_attach_2(ap,rp) ++admproc_attach_2_svc(ap,rp) + cfs_attachargs *ap; +- SR *rp; ++ SR rp; + { + static cfsstat ret; + int i; +@@ -154,9 +154,9 @@ + } + + cfsstat * +-admproc_detach_2(ap,rp) ++admproc_detach_2_svc(ap,rp) + cfs_detachargs *ap; +- SR *rp; ++ SR rp; + { + static cfsstat ret; + int i; From ernst.winter at t-online.de Wed Jun 18 06:36:29 2008 From: ernst.winter at t-online.de (Ernst W. Winter) Date: Wed Jun 18 06:36:36 2008 Subject: installation of zfs In-Reply-To: <48582DE7.4010009@psg.com> References: <26377.150.101.214.246.1213676733.squirrel@legios.org> <20080617202026.GA1997@ewinter.org> <20080617213218.GA27283@eos.sc1.parodius.com> <48582DE7.4010009@psg.com> Message-ID: <20080618063542.GC19490@ewinter.org> On Wed, 18 Jun 2008, Randy Bush wrote: > > Unless you're referring to /usr being on ZFS, which in that case you'll > > need to run "/etc/rc.d/hostid start", then "/etc/rc.d/zfs start". Your > > pools should load automatically. > > iff you did setmountpoint > aha, I see, and where do I set it permanently? Thanks, > randyu Ernst -- ================================================== Mail just Ascii plain text. HTML & Base64 is spam email = nur reiner Text. HTML & Base64 sind SPAM From randy at psg.com Wed Jun 18 06:38:46 2008 From: randy at psg.com (Randy Bush) Date: Wed Jun 18 06:38:48 2008 Subject: installation of zfs In-Reply-To: <20080618063542.GC19490@ewinter.org> References: <26377.150.101.214.246.1213676733.squirrel@legios.org> <20080617202026.GA1997@ewinter.org> <20080617213218.GA27283@eos.sc1.parodius.com> <48582DE7.4010009@psg.com> <20080618063542.GC19490@ewinter.org> Message-ID: <4858AD72.3090707@psg.com> Ernst W. Winter wrote: > On Wed, 18 Jun 2008, Randy Bush wrote: > >>> Unless you're referring to /usr being on ZFS, which in that case you'll >>> need to run "/etc/rc.d/hostid start", then "/etc/rc.d/zfs start". Your >>> pools should load automatically. >> iff you did setmountpoint > aha, I see, and where do I set it permanently? see 'zfs setmountpoint' also in wiki and other docs. then they are mounted automagically, analogously to /etc/fstab mounts for ufs filesystems. randy From ernst.winter at t-online.de Wed Jun 18 06:46:27 2008 From: ernst.winter at t-online.de (Ernst W. Winter) Date: Wed Jun 18 06:46:31 2008 Subject: installation of zfs In-Reply-To: <4858AD72.3090707@psg.com> References: <26377.150.101.214.246.1213676733.squirrel@legios.org> <20080617202026.GA1997@ewinter.org> <20080617213218.GA27283@eos.sc1.parodius.com> <48582DE7.4010009@psg.com> <20080618063542.GC19490@ewinter.org> <4858AD72.3090707@psg.com> Message-ID: <20080618064542.GA35047@ewinter.org> On Wed, 18 Jun 2008, Randy Bush wrote: > Ernst W. Winter wrote: > > On Wed, 18 Jun 2008, Randy Bush wrote: > > > >>> Unless you're referring to /usr being on ZFS, which in that case you'll > >>> need to run "/etc/rc.d/hostid start", then "/etc/rc.d/zfs start". Your > >>> pools should load automatically. > >> iff you did setmountpoint > > aha, I see, and where do I set it permanently? > > see 'zfs setmountpoint' > SUPER! I will recompile everything first as I have csuped it all and so I will be up to date. Looking forward to learn about it more as it sounds good to have a filesystem like that and easy to handle so far. I will add a another HD as well for storage. > also in wiki and other docs. then they are mounted automagically, > analogously to /etc/fstab mounts for ufs filesystems. > Thanks again, > randy > _______________________________________________ > 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" Ernst -- ================================================== Mail just Ascii plain text. HTML & Base64 is spam email = nur reiner Text. HTML & Base64 sind SPAM From gdt at ir.bbn.com Wed Jun 18 12:29:15 2008 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed Jun 18 12:29:18 2008 Subject: CFS Cryptographic file system. In-Reply-To: <20080617222227.GA87804@k7.mavetju> (Edwin Groothuis's message of "Wed, 18 Jun 2008 08:22:27 +1000") References: <20080617222227.GA87804@k7.mavetju> Message-ID: I have been running cfs for a very long time (15 years?), most recently on NetBSD, but I've run it on 4.2BSD, SunOS 4, Linux, FreeBSD (2.1 to 4.x), and NetBSD (1.3ish to present). Your patch looks like it is adjusting for rpcgen differences, which makes sense. I've also had two other problems, but my memory is a bit fuzzy. on sparc, I needed to change something to avoid miscompilation; it worked on i386. It might be the patch appended. on i386, with gcc 4.1.2, it doesn't work (zero-length files?). With binaries built with gcc 3.3 on NetBSD 3, it works (even running on NetBSD 4.0). You may want to look at http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/cfs/ It might be time to roll a lot of these patches in and have a new tarball released. $NetBSD: patch-ae,v 1.1 2001/06/09 04:32:14 jlam Exp $ --- cfs_adm.c.orig Mon Dec 25 01:41:30 1995 +++ cfs_adm.c Fri Jun 8 21:14:35 2001 @@ -43,7 +43,7 @@ cfsstat * admproc_attach_2(ap,rp) cfs_attachargs *ap; - SR *rp; + SR rp; { static cfsstat ret; int i; @@ -156,7 +156,7 @@ cfsstat * admproc_detach_2(ap,rp) cfs_detachargs *ap; - SR *rp; + SR rp; { static cfsstat ret; int i; From gavin at FreeBSD.org Fri Jun 20 20:03:31 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Jun 20 20:03:36 2008 Subject: kern/93942: [vfs] [patch] panic: ufs_dirbad: bad dir (patch from DragonFly) Message-ID: <200806202003.m5KK3VAS030912@freefall.freebsd.org> Synopsis: [vfs] [patch] panic: ufs_dirbad: bad dir (patch from DragonFly) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Fri Jun 20 20:01:34 UTC 2008 Responsible-Changed-Why: Over to freebsd-fs, where hopefully somebody can assess this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=93942 From bugmaster at FreeBSD.org Mon Jun 23 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 23 11:07:13 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200806231106.m5NB6rE2064946@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 7 problems total. From john at kozubik.com Sat Jun 28 21:54:02 2008 From: john at kozubik.com (John Kozubik) Date: Sat Jun 28 21:54:06 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. Message-ID: <20080628132632.R1807@kozubik.com> I needed to set a user quota of greater than 2 TB today. I failed, because FreeBSD does not have 64-bit quota tools. I wasted a fair amount of time trying to track down what I assumed was my own user error. Surely there is _no way_ that an enterprise operating system, in 2008, has 32-bit quotas. Now I know better. I am upset to find that several of my non-technical friends now have larger filesystems _in their living rooms_ than FreeBSD can handle with quotas. Quotas are a long-standing, core piece of filesystem functionality and have been considered a bedrock of unix operating systems for decades. There is nothing new or experimental in moving quotas from 32 to 64 bit. This is _as opposed to_ porting ZFS to FreeBSD, and gjournal, and every other shiny bauble that has monopolized freebsd-fs in the last four years. Those are new. Those are experimental. Apparently those take priority. I don't have time to monitor the core pieces of FreeBSD to make sure _they still exist_. Further, while I might have volunteered to help with the code back in 2004, when it took 5 hard drives to max out the usefulness of the filesystem, that's not how I'll be spending my time in 2008. So I'll try this instead: I will paypal $1000 to whoever can deliver fully clean 64-bit quotas and userland tools in FreeBSD by July 20, 2008. That is, if you can tear yourself away from ZFS and whatever sexy SMP improvements you're building into FreeBSD 14.0 for a week. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com From koitsu at FreeBSD.org Sat Jun 28 23:58:32 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Jun 28 23:58:35 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080628132632.R1807@kozubik.com> References: <20080628132632.R1807@kozubik.com> Message-ID: <20080628235832.GA15910@eos.sc1.parodius.com> On Sat, Jun 28, 2008 at 02:56:03PM -0700, John Kozubik wrote: > I needed to set a user quota of greater than 2 TB today. I failed, > because FreeBSD does not have 64-bit quota tools. > > I wasted a fair amount of time trying to track down what I assumed was my > own user error. Surely there is _no way_ that an enterprise operating > system, in 2008, has 32-bit quotas. > > Now I know better. > > I am upset to find that several of my non-technical friends now have > larger filesystems _in their living rooms_ than FreeBSD can handle with > quotas. > > Quotas are a long-standing, core piece of filesystem functionality and > have been considered a bedrock of unix operating systems for decades. > There is nothing new or experimental in moving quotas from 32 to 64 bit. > > This is _as opposed to_ porting ZFS to FreeBSD, and gjournal, and every > other shiny bauble that has monopolized freebsd-fs in the last four years. > Those are new. Those are experimental. > > Apparently those take priority. > > I don't have time to monitor the core pieces of FreeBSD to make sure _they > still exist_. Further, while I might have volunteered to help with the > code back in 2004, when it took 5 hard drives to max out the usefulness of > the filesystem, that's not how I'll be spending my time in 2008. > > So I'll try this instead: > > I will paypal $1000 to whoever can deliver fully clean 64-bit quotas > and userland tools in FreeBSD by July 20, 2008. > > That is, if you can tear yourself away from ZFS and whatever sexy SMP > improvements you're building into FreeBSD 14.0 for a week. John, We don't use quotas here, but FWIW, I agree with you. Additionally, that 2GB limit should really be 4GB; someone likely used a signed number instead of unsigned. I'll take this project on (and there's no need for any monetary exchange) if I can make heads or tails of the existing quota infrastructure. No promises, but I'll at least look into it. I definitely can't meet the July 20th deadline, sorry about that. -- | 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 kostikbel at gmail.com Sun Jun 29 13:14:53 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Jun 29 13:14:56 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080628235832.GA15910@eos.sc1.parodius.com> References: <20080628132632.R1807@kozubik.com> <20080628235832.GA15910@eos.sc1.parodius.com> Message-ID: <20080629123733.GO17123@deviant.kiev.zoral.com.ua> On Sat, Jun 28, 2008 at 04:58:32PM -0700, Jeremy Chadwick wrote: > On Sat, Jun 28, 2008 at 02:56:03PM -0700, John Kozubik wrote: > > I needed to set a user quota of greater than 2 TB today. I failed, > > because FreeBSD does not have 64-bit quota tools. > > > > I wasted a fair amount of time trying to track down what I assumed was my > > own user error. Surely there is _no way_ that an enterprise operating > > system, in 2008, has 32-bit quotas. > > > > Now I know better. > > > > I am upset to find that several of my non-technical friends now have > > larger filesystems _in their living rooms_ than FreeBSD can handle with > > quotas. > > > > Quotas are a long-standing, core piece of filesystem functionality and > > have been considered a bedrock of unix operating systems for decades. > > There is nothing new or experimental in moving quotas from 32 to 64 bit. > > > > This is _as opposed to_ porting ZFS to FreeBSD, and gjournal, and every > > other shiny bauble that has monopolized freebsd-fs in the last four years. > > Those are new. Those are experimental. > > > > Apparently those take priority. > > > > I don't have time to monitor the core pieces of FreeBSD to make sure _they > > still exist_. Further, while I might have volunteered to help with the > > code back in 2004, when it took 5 hard drives to max out the usefulness of > > the filesystem, that's not how I'll be spending my time in 2008. > > > > So I'll try this instead: > > > > I will paypal $1000 to whoever can deliver fully clean 64-bit quotas > > and userland tools in FreeBSD by July 20, 2008. > > > > That is, if you can tear yourself away from ZFS and whatever sexy SMP > > improvements you're building into FreeBSD 14.0 for a week. > > John, > > We don't use quotas here, but FWIW, I agree with you. Additionally, > that 2GB limit should really be 4GB; someone likely used a signed number > instead of unsigned. > > I'll take this project on (and there's no need for any monetary > exchange) if I can make heads or tails of the existing quota > infrastructure. No promises, but I'll at least look into it. I > definitely can't meet the July 20th deadline, sorry about that. The change alone of the 32/31-bit fields in the struct dqblk to the 64-bit is a trivial part. I think in-kernel part would simply work after the conversion, but I have no idea about user-mode utilites. Most likely, usermode would require some tweaking. Not so easy is the backward compatibility. Quota file is read/written directly by the kernel, and have no useful magic sequence to identify it. Some external measures are needed to inform kernel about the version of the dqblk on the disk. Then, either code shall be conditionalized to do the keeping in 32/64 bitness (preferrable), or old dqblk layout shall be converted from/to on i/o. Another useful thing to do with in-kernel quota implementation is to move it from ufs/ to the generic VFS service. Again, the code is mostly filesystem-neutral, and the change should be in the interfaces. This would make addition of the quota support for some non-ufs filesystems nearly trivial. -------------- 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/20080629/a3ce284d/attachment.pgp From rwatson at FreeBSD.org Sun Jun 29 16:53:47 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 29 16:53:52 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080629123733.GO17123@deviant.kiev.zoral.com.ua> References: <20080628132632.R1807@kozubik.com> <20080628235832.GA15910@eos.sc1.parodius.com> <20080629123733.GO17123@deviant.kiev.zoral.com.ua> Message-ID: <20080629174039.Q20262@fledge.watson.org> On Sun, 29 Jun 2008, Kostik Belousov wrote: > The change alone of the 32/31-bit fields in the struct dqblk to the 64-bit > is a trivial part. I think in-kernel part would simply work after the > conversion, but I have no idea about user-mode utilites. Most likely, > usermode would require some tweaking. > > Not so easy is the backward compatibility. Quota file is read/written > directly by the kernel, and have no useful magic sequence to identify it. > Some external measures are needed to inform kernel about the version of the > dqblk on the disk. Then, either code shall be conditionalized to do the > keeping in 32/64 bitness (preferrable), or old dqblk layout shall be > converted from/to on i/o. > > Another useful thing to do with in-kernel quota implementation is to move it > from ufs/ to the generic VFS service. Again, the code is mostly > filesystem-neutral, and the change should be in the interfaces. This would > make addition of the quota support for some non-ufs filesystems nearly > trivial. Quite, and compatibility needs to be done fairly carefully to prevent some rather awkward foot-shooting that might otherwise take place. One possibility might be to have a header the size of the existing dqblk and store a magic value (perhaps in the negative range) in one or both of the two signed int fields (dqb_btime and dqb_itime). Other than this one issue, updating to 64-bit support should really be no problem, and as the reporter points out, is long-overdue. FWIW, that "make it a library" change would be very similar to what we've done for ACLs, where there are central vfs_acl.c and subr_acl_posix1e.c which represent common system call code, and a library to be used by file systems in implementing ACLs to avoid duplicated code. I think Apple may already have made this change for quotas as well, btw. Robert N M Watson Computer Laboratory University of Cambridge From bugmaster at FreeBSD.org Mon Jun 30 11:06:56 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 30 11:07:04 2008 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200806301106.m5UB6uQM095730@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 7 problems total. From des at des.no Mon Jun 30 12:06:53 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jun 30 12:06:57 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080628132632.R1807@kozubik.com> (John Kozubik's message of "Sat\, 28 Jun 2008 14\:56\:03 -0700 \(PDT\)") References: <20080628132632.R1807@kozubik.com> Message-ID: <864p7bw387.fsf@ds4.des.no> John Kozubik writes: > I needed to set a user quota of greater than 2 TB today. I failed, > because FreeBSD does not have 64-bit quota tools. > [long rant about how 64-bit quotas should take precedence over > everything else we do] FreeBSD is a volunteer-driven open source project. Basically, this means you don't get to dictate what people work on. It also means you don't get to throw shit at people the way you just did. > Quotas are a long-standing, core piece of filesystem functionality and > have been considered a bedrock of unix operating systems for decades. I dunno, I've never used them, nor have I ever encountered them in any of the places I've worked or studied. Frankly, disk space is so cheap these days (as you point out yourself) that I don't see the point. > There is nothing new or experimental in moving quotas from 32 to 64 bit. It breaks backward compat rather badly. All quotas need to be recalculated, and there no way to tell whether the existing quota file is 32-bit or 64-bit. > This is _as opposed to_ porting ZFS to FreeBSD, and gjournal, and every > other shiny bauble that has monopolized freebsd-fs in the last four > years. Those "shiny baubles", not quotas, are what make FreeBSD a viable server operating system in 2008. BTW, ZFS has 128-bit quotas. DES -- Dag-Erling Sm?rgrav - des@des.no From jhs at berklix.org Mon Jun 30 13:17:11 2008 From: jhs at berklix.org (Julian Stacey) Date: Mon Jun 30 13:17:18 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: Your message "Mon, 30 Jun 2008 13:51:04 +0200." <864p7bw387.fsf@ds4.des.no> Message-ID: <200806301304.m5UD4fVw001005@fire.js.berklix.net> > FreeBSD is a volunteer-driven open source project. Basically, this > means you don't get to dictate what people work on. It also means you > don't get to throw shit at people the way you just did. It was a mixed post, but he did offer money unlike most complainers :-) I will extract a bit of John Kozubik's $1000 offer to jobs@freebsd maybe someone there has the time & needs the money. Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From john at kozubik.com Mon Jun 30 14:47:10 2008 From: john at kozubik.com (John Kozubik) Date: Mon Jun 30 14:47:24 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <864p7bw387.fsf@ds4.des.no> References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> Message-ID: <20080630073539.U1807@kozubik.com> On Mon, 30 Jun 2008, [utf-8] Dag-Erling Sm?rgrav wrote: > John Kozubik writes: > > I needed to set a user quota of greater than 2 TB today. I failed, > > because FreeBSD does not have 64-bit quota tools. > > [long rant about how 64-bit quotas should take precedence over > > everything else we do] > > FreeBSD is a volunteer-driven open source project. Basically, this > means you don't get to dictate what people work on. It also means you > don't get to throw shit at people the way you just did. When I offered monetary rewards for these items: http://www.rsync.net/resources/notices/2007cb.html http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html they were merely polite suggestions. That's because, at the end of the day, FreeBSD on the desktop, and these particular aspects of FreeBSD on the desktop, must be kept a bit down on the priority list. The core, expected functionality of a unix operating system are a different story. Nobody cares about your feelings. > > There is nothing new or experimental in moving quotas from 32 to 64 bit. > > It breaks backward compat rather badly. All quotas need to be > recalculated, and there no way to tell whether the existing quota file > is 32-bit or 64-bit. As I said, nothing new or experimental. Please note that you've had five years to address this: http://www.freebsd.org/projects/bigdisk/index.html That task list, and the things left undone on it, are a joke. > > This is _as opposed to_ porting ZFS to FreeBSD, and gjournal, and every > > other shiny bauble that has monopolized freebsd-fs in the last four > > years. > > Those "shiny baubles", not quotas, are what make FreeBSD a viable server > operating system in 2008. You are wrong. No set of services is worthwhile[1] without a solid foundation. You may not use a lot of core, historical pieces of a unix system, but you should be alarmed to find them missing or broken. I regret not aggressively pursuing this four years ago. [1] I am _very_ excited about ZFS on FreeBSD and amazed at the great work that pjd and others have put into it. They have total freedom to pursue whatever they choose. However, FreeBSD has a core team for a reason - direction and priorities need to be set and followed. It is the asymmetry of attention and priority between the new and experimental and the old and foundational that I am so troubled with. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com From kris at FreeBSD.org Mon Jun 30 15:26:42 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Jun 30 15:26:44 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080630073539.U1807@kozubik.com> References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> Message-ID: <4868FB2F.7010204@FreeBSD.org> John Kozubik wrote: > [1] I am _very_ excited about ZFS on FreeBSD and amazed at the great work > that pjd and others have put into it. They have total freedom to pursue > whatever they choose. However, FreeBSD has a core team for a reason - > direction and priorities need to be set and followed. FreeBSD does indeed have a core team for several reasons, but directing other developers to work on projects isn't among them. Indeed, you say as much in your previous sentence, but perhaps this is the cognitive dissonance at the core of your misunderstanding. Furthermore, every FreeBSD user has a different idea of what constitutes the "core" of the operating system, for them. quota support is obviously in your core feature set. That's fine, and I applaud you for doing something about its deficiencies (although as I have already noted, not your attitude in doing so). However, quota support is not in the core feature set of most developers, or dare I say most users. Likewise, you may be surprised to hear what kind of "peripheral" features other users and developers consider to be "core". For me, ZFS has become a core feature, even though to you it's merely a "shiny bauble". I am sure we can point to most systems in FreeBSD and find a user somewhere who considers it to be an indispensible, "core feature". Kris From des at des.no Mon Jun 30 15:34:41 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jun 30 15:34:45 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080630073539.U1807@kozubik.com> (John Kozubik's message of "Mon\, 30 Jun 2008 08\:11\:04 -0700 \(PDT\)") References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> Message-ID: <86prpzq6lt.fsf@ds4.des.no> John Kozubik writes: > On Mon, 30 Jun 2008, [utf-8] Dag-Erling Sm?rgrav wrote: > > John Kozubik writes: > > > [long rant about how 64-bit quotas should take precedence over > > > everything else we do] > > FreeBSD is a volunteer-driven open source project. Basically, this > > means you don't get to dictate what people work on. It also means > > you don't get to throw shit at people the way you just did. > When I offered monetary rewards for these items: > > http://www.rsync.net/resources/notices/2007cb.html > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > they were merely polite suggestions. That's because, at the end of the > day, FreeBSD on the desktop, and these particular aspects of FreeBSD on > the desktop, must be kept a bit down on the priority list. > > The core, expected functionality of a unix operating system are a > different story. Nobody cares about your feelings. You seriously need to reconsider your attitude. FreeBSD is volunteer-driven. If you want something done, you can either do it yourself, or provide incentive for someone else to do it for you. I see you're trying to do the latter, and that's great, but it does *not* entitle you to berate people for doing something else. Bear in mind, also, that this is not a zero-sum game. Pawel and Ivan worked on ZFS and gjournal because they felt like it. If they hadn't been allowed to do so, they wouldn't have fixed quotas instead; they would just have gone somewhere else. > > > There is nothing new or experimental in moving quotas from 32 to > > > 64 bit. > > It breaks backward compat rather badly. All quotas need to be > > recalculated, and there no way to tell whether the existing quota > > file is 32-bit or 64-bit. > As I said, nothing new or experimental. I hardly think you're qualified to judge the level of difficulty involved. If you were, you'd be busy fixing the problem, not bitching about it. > Please note that you've had five years to address this: > > http://www.freebsd.org/projects/bigdisk/index.html > > That task list, and the things left undone on it, are a joke. Absolutely. Lists like this are pointless: they are never complete, they are never up-to-date, and they never reflect the relative importance of the listed items accurately. DES -- Dag-Erling Sm?rgrav - des@des.no From john at kozubik.com Mon Jun 30 15:41:53 2008 From: john at kozubik.com (John Kozubik) Date: Mon Jun 30 15:41:57 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <4868FB2F.7010204@FreeBSD.org> References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> <4868FB2F.7010204@FreeBSD.org> Message-ID: <20080630085612.G1807@kozubik.com> On Mon, 30 Jun 2008, Kris Kennaway wrote: > However, quota support is not in the core feature set of most > developers, or dare I say most users. > > Likewise, you may be surprised to hear what kind of "peripheral" > features other users and developers consider to be "core". For me, ZFS > has become a core feature, even though to you it's merely a "shiny > bauble". I am sure we can point to most systems in FreeBSD and find a > user somewhere who considers it to be an indispensible, "core feature". That point is well taken. However, regardless of the adoption rate, I _do_ believe that there is still a qualitative difference between quotas and, for instance, ZFS - in terms of "coreness". I believe this because of the historical presence of this functionality and the reasonable expectation that it represents a basic function of a unix-based OS (not just FreeBSD). This may change. It may, as you say, be changing as we speak. That is why I regret not speaking up years ago when the bigdisk "progress" page was still only a minor embarrassment. That is also why I have offered funds for the work. From john at kozubik.com Mon Jun 30 16:09:52 2008 From: john at kozubik.com (John Kozubik) Date: Mon Jun 30 16:10:36 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <86prpzq6lt.fsf@ds4.des.no> References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> <86prpzq6lt.fsf@ds4.des.no> Message-ID: <20080630090947.H1807@kozubik.com> On Mon, 30 Jun 2008, [utf-8] Dag-Erling Sm?rgrav wrote: > Bear in mind, also, that this is not a zero-sum game. Pawel and Ivan > worked on ZFS and gjournal because they felt like it. If they hadn't > been allowed to do so, they wouldn't have fixed quotas instead; they > would just have gone somewhere else. Perhaps. Like I said, I'm excited about ZFS and the experimental work being done - so long as the existing core remains functional. However, I wonder how a call to action and a sense of priority would have affected their own priorities in these past five years. Somewhere, a collective decision was made that these things being broken were somehow acceptable and reasonable, and that decision was reaffirmed year after year. That is what I am upset about. > > > > There is nothing new or experimental in moving quotas from 32 to > > > > 64 bit. > > > It breaks backward compat rather badly. All quotas need to be > > > recalculated, and there no way to tell whether the existing quota > > > file is 32-bit or 64-bit. > > As I said, nothing new or experimental. > > I hardly think you're qualified to judge the level of difficulty > involved. If you were, you'd be busy fixing the problem, not bitching > about it. I can do this. It would take me 4x as long and would require auditing and corrections greater than or equal to the time it takes (for instance) someone like you to do it. We have comparative advantages at particular activities. I pursue what I am best at, you pursue what you are best at, and we exchange them in the marketplace. The world becomes slightly better. We forget that this community is a marketplace because most transactions are based on goodwill only. It shouldn't be surprising that an offer of something more than goodwill is accompanied by something more than meek suggestion. From des at des.no Mon Jun 30 16:34:40 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jun 30 16:34:44 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080630090947.H1807@kozubik.com> (John Kozubik's message of "Mon\, 30 Jun 2008 09\:33\:46 -0700 \(PDT\)") References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> <86prpzq6lt.fsf@ds4.des.no> <20080630090947.H1807@kozubik.com> Message-ID: <86fxqurie9.fsf@ds4.des.no> John Kozubik writes: > I can do this. It would take me 4x as long and would require auditing > and corrections greater than or equal to the time it takes (for instance) > someone like you to do it. > [...] > We forget that this community is a marketplace because most transactions > are based on goodwill only. It shouldn't be surprising that an offer of > something more than goodwill is accompanied by something more than meek > suggestion. I don't get it. Do you think that just because you put money on the table - of your own free will, without anyone asking you to do so - you get to order us around? Besides, do you think anyone is impressed by the sum you're offering? At my usual rate, it would buy you around five hours of my time. If you want someone you can order around, hire them, pay them real money, and *then* tell them what to do; but as long as you want them to work for free (or as close as makes no difference), you'll have to stick to meek suggestions. DES -- Dag-Erling Sm?rgrav - des@des.no From john at kozubik.com Mon Jun 30 17:17:08 2008 From: john at kozubik.com (John Kozubik) Date: Mon Jun 30 17:17:10 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <86fxqurie9.fsf@ds4.des.no> References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> <86prpzq6lt.fsf@ds4.des.no> <20080630090947.H1807@kozubik.com> <86fxqurie9.fsf@ds4.des.no> Message-ID: <20080630103210.B1807@kozubik.com> On Mon, 30 Jun 2008, [utf-8] Dag-Erling Sm?rgrav wrote: > John Kozubik writes: > > I can do this. It would take me 4x as long and would require auditing > > and corrections greater than or equal to the time it takes (for instance) > > someone like you to do it. > > [...] > > We forget that this community is a marketplace because most transactions > > are based on goodwill only. It shouldn't be surprising that an offer of > > something more than goodwill is accompanied by something more than meek > > suggestion. > > I don't get it. Do you think that just because you put money on the > table - of your own free will, without anyone asking you to do so - you > get to order us around? No. I think that putting money on the table will demonstrate just how deeply I am frustrated by these issues. I understand that you aren't interested in this work. Thank you, nonetheless, for all the work that you do for FreeBSD. From freebsd-fs at wheelhouse.org Mon Jun 30 17:35:42 2008 From: freebsd-fs at wheelhouse.org (Jeff Wheelhouse) Date: Mon Jun 30 17:35:45 2008 Subject: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. In-Reply-To: <20080630085612.G1807@kozubik.com> References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> <4868FB2F.7010204@FreeBSD.org> <20080630085612.G1807@kozubik.com> Message-ID: <2D2DBAC8-43E2-4AB8-9EEE-44C8304A0E82@wheelhouse.org> I suspect a lot of John's frustration on this issue stems from the amount of effort he put into getting it to work before realizing it was a lost cause. I suspect that a lot of that work occurred because the 32-bit limitation is not well documented. Maybe edquota(1) deserves an update reflecting the limitation, so the next guy doesn't waste a day? I have a separate, semi-sarcastic rhetorical question: if John is really the only person left using quotas, and he's willing to bite the bullet, is backwards-compatibility really that big of a deal? :-) Disclosure: I don't use quotas (but one of my companies is a customer of one of John's, so I assume they affect us indirectly). That said, yes, I'd agree with his statement that quotas are one of those features that I would expect to see present and working in a *Nix operating system. The tone of John's message was definitely short in the tact department, due no doubt to the aforementioned frustration, but the content appears to be this: FreeBSD is the operating system that uses "The Power To Serve" as its tagline. In 2008, 64 bit filesystem quotas are a reasonable expectation from a server operating system. What will it take to make that happen? As far as the resulting argument, which is as old as the hills, it is fundamental to open source projects. In my personal opinion, one of the reasons people pick FreeBSD over Linux (for example) is because of the tighter, more stable, more reliable, less "shiny-bauble"-oriented control exerted by the core team. That's waned, somewhat, out of competitive necessity and out of the "well if I can't work on teh sexay here, I'll go somewhere else" attitude justifiably espoused by people who are doing it out of personal desire. ZFS is kind of an ugly example of "coreness," because a lot of the traffic on this list is devoted to the ZFS deadlocks, crashes and other problems that render it suitable only as an "experimental" in 7.0. Historically, my impression of FreeBSD is that it doesn't tend to put "experimental" and "core" labels on the same feature. That's why I depend on it. At the same time, there are *thousands* of open PRs on problems that have been open for years because the problems, while they may be important, aren't sexy enough to attract the attention of people who work for free. If you're trying to run a business and you're hit by these types of problems, yeah, it's pretty frustrating. So are the "fix it yourself, if you care so much" and/or "I don't want to fix it and you can't make me" responses that inevitably follow, particularly if you don't have the expertise to do it yourself or the money to pay a developer to do it for you, if you could even find one. There is a lot of unsexy work that, left to their own devices, nobody is ever going to do. (Which is not to imply that it never happens; I'm thrilled and grateful that we finally got a working nullfs after I- don't-know-how-many-years.) It sounds like part of John's frustration is that he'd like the core team to take a more active rule in convincing people to do that unsexy but important work. I don't know about him, but I use FreeBSD in a very mission critical way. It is the single most important piece of software we run, but we pay nothing for it. I'm not running any big rich companies but I could probably afford a few hundred dollars a month, and I'd be more than willing to spend that on a support contract on FreeBSD, similar in spirit to what we paid Sun all those years ago, if it would help our FreeBSD problems get fixed even when they weren't sexy. Now I don't hold any mistaken memory that having a support contract with Sun guaranteed that SunOS bugs/limitations we found automatically got fixed, but Sun does/did officially pay people to do work that was important but not sexy, and there is an advantage in that. I know there are all sorts of FreeBSD support offerings out there, but I don't believe any of them are "official." And, as far as I know, very few of them go to the level of fixing bugs in the source and committing the changes back to FreeBSD. Those that do seem to charge a heftily-inflated per-hour fee to do so. I also know that there are zillions of ways to financially support FreeBSD. But, like John and like the developers who work for free, I am motivated by self-interest. I want the equivalent of a maintenance contract; if I open my wallet, I want that money to go toward *maintaining* FreeBSD: fixing what's broke and keeping existing things updated, not paying to accelerate new feature development that (a) people are already willing to do for free and (b) may or may not benefit me. For something like that, I'd be looking for somebody "official," somebody who cares enough about FreeBSD, cares about its reputation (and reality) as a rock-solid bulletproof server OS, someone who uses the money that comes in to improve FreeBSD, and not to fund a fancy professional consultancy. Somebody connected enough to know where limited funds can make the biggest difference, and to whom they should be directed to make that difference. I don't know if that would be a job for the core team, or the FreeBSD Foundation, or who exactly, but it sure would be neat if it were *somebody's* job. Thanks, Jeff From j at uriah.heep.sax.de Mon Jun 30 21:40:04 2008 From: j at uriah.heep.sax.de (Joerg Wunsch) Date: Mon Jun 30 21:40:05 2008 Subject: kern/114676: snapshot creation panics: snapacct_ufs2: bad block Message-ID: <200806302140.m5ULe4LF067139@freefall.freebsd.org> The following reply was made to PR kern/114676; it has been noted by GNATS. From: Joerg Wunsch To: bug-followup@freebsd.org Cc: Subject: Re: kern/114676: snapshot creation panics: snapacct_ufs2: bad block Date: Mon, 30 Jun 2008 22:34:42 +0200 FreeBSD-7-stable is completely unstable for me due to this panic. I used to have regular snapshots enabled on /var and /home. While there has been random (and not quite reproducible) file corruption happened within snapshotted binary files in the past, after upgrading from FreeBSD 6.x to 7-stable, the system went completely unstable due to this panic. It crashes every couple of days now. I have already disabled the regular snapshots, but it's got a tendency for a complete hard lockup during startup after a crash. The only remedy then is to manually fsck everything in single-user mode. Here's the dump information from the recent crash dumps: Dump header from device /dev/ad4s1b Architecture: i386 Architecture Version: 2 Dump Length: 317976576B (303 MB) Blocksize: 512 Dumptime: Wed Jun 25 04:10:25 2008 Hostname: uriah.heep.sax.de Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-STABLE #5: Tue Jun 17 15:06:46 MET DST 2008 r@uriah.heep.sax.de:/usr/obj/usr/src/sys/URIAH Panic String: snapacct_ufs2: bad block Dump Parity: 558154102 Bounds: 42 Dump Status: good Dump header from device /dev/ad4s1b Architecture: i386 Architecture Version: 2 Dump Length: 180707328B (172 MB) Blocksize: 512 Dumptime: Mon Jun 30 22:05:09 2008 Hostname: uriah.heep.sax.de Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-STABLE #6: Mon Jun 30 21:24:35 MET DST 2008 root@uriah.heep.sax.de:/usr/obj/usr/src/sys/URIAH Panic String: snapacct_ufs2: bad block Dump Parity: 859829782 Bounds: 43 Dump Status: good I'm going to avoid /any/ kind of snapshot (even dump -L) now just to get a stable system again (hopefully). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)