From markocpc at gmail.com Sat May 2 08:30:03 2009 From: markocpc at gmail.com (Lagrange Marc) Date: Sat May 2 08:30:09 2009 Subject: kern/132960: [ufs] [panic] panic:ffs_blkfree: freeing free frag Message-ID: <200905020830.n428U2vW056808@freefall.freebsd.org> The following reply was made to PR kern/132960; it has been noted by GNATS. From: Lagrange Marc To: bug-followup@FreeBSD.org, kevinxlinuz@163.com Cc: Subject: Re: kern/132960: [ufs] [panic] panic:ffs_blkfree: freeing free frag Date: Sat, 2 May 2009 09:58:29 +0200 Hi, I think i've also the bug with panic: ffs_blkfree but my panic is : fsync: giving up on dirty 0xc3ff3114: tag devfs, type VCHR usecount 1, writecount 0, refcount 771 mountedhere 0xc3fac300 flags () v_object 0xc1045600 ref 0 pages 3836 lock type devfs: EXCL (count 1) by thread 0xc41a6690 (pid 1831) dev ad4s1f fsync: giving up on dirty 0xc3ff3114: tag devfs, type VCHR usecount 1, writecount 0, refcount 771 mountedhere 0xc3fac300 flags () v_object 0xc1045600 ref 0 pages 3836 lock type devfs: EXCL (count 1) by thread 0xc41a6690 (pid 1831) dev ad4s1f dev = ad4s1f, block = 1, fs = /usr panic: ffs_blkfree: freeing free block I've got this, two times i think when rebuilding the kernel, this is a FreeBSD 7.2-RELEASE installed last day in 7.2-RC2 and recompilled in 7.2-RELEASE. I can't reproduce this bug for the moment... Is it related ? Any informations about this bug ? Thx. From Juergen.Dankoweit at T-Online.de Sat May 2 10:26:25 2009 From: Juergen.Dankoweit at T-Online.de (Juergen Dankoweit) Date: Sat May 2 10:26:36 2009 Subject: UFS2 and SSDs Message-ID: <49FC1BD0.4030306@T-Online.de> Hello to the list, my question is, how does UFS2 behave on solid state disks? What about performance, stability and data security? Many thanks for the answers. Best regards J.D. From bugmaster at FreeBSD.org Mon May 4 11:07:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 4 11:08:32 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200905041107.n44B7lUm098532@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int o kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/133134 fs [zfs] Missing ZFS zpool labels o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132551 fs [zfs] ZFS locks up on extattr_list_link syscall o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132337 fs [zfs] [panic] kernel panic in zfs_fuid_create_cred o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132145 fs [panic] File System Hard Crashes f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/131084 fs [xfs] xfs destroys itself after copying data o kern/131081 fs [zfs] User cannot delete a file when a ZFS dataset is o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o bin/130105 fs [zfs] zfs send -R dumps core o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs o kern/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs] [panic] changing into .zfs dir from nfs client c f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc 59 problems total. From doug at polands.org Mon May 4 20:30:04 2009 From: doug at polands.org (Doug Poland) Date: Mon May 4 20:30:12 2009 Subject: kern/94769: [ufs] Multiple file deletions on multi-snapshotted filesystems causes hang Message-ID: <200905042030.n44KU3Bp058343@freefall.freebsd.org> The following reply was made to PR kern/94769; it has been noted by GNATS. From: Doug Poland To: bug-followup@FreeBSD.org, john@kozubik.com Cc: Subject: Re: kern/94769: [ufs] Multiple file deletions on multi-snapshotted filesystems causes hang Date: Mon, 4 May 2009 15:11:33 -0500 I recently started experiencing similar behavior on a 7.1-RELEASE i386 host. In this case the deadlock occurs as soon as sysutils/freebsd-snapshots run it's weekly cron entry: 0 * * * * root periodic-snapshot hourly 0 0 * * * root periodic-snapshot daily 0 0 * * 0 root periodic-snapshot weekly I am running a GENERIC kernel without quotas. Here's the list of snapshots on the various filesystems: Filesystem User User% Snap Snap% Snapshot / 267MB 54.0% 704KB 0.1% daily.0 / 267MB 54.0% 704KB 0.1% daily.1 / 267MB 54.0% 704KB 0.1% daily.2 / 267MB 54.0% 704KB 0.1% daily.3 / 267MB 54.0% 704KB 0.1% daily.4 / 267MB 54.0% 784KB 0.2% daily.5 / 267MB 54.0% 784KB 0.2% daily.6 / 267MB 54.0% 608KB 0.1% hourly.0 / 267MB 54.0% 640KB 0.1% hourly.1 / 267MB 54.0% 656KB 0.1% hourly.2 / 267MB 54.0% 656KB 0.1% hourly.3 / 267MB 54.0% 704KB 0.1% weekly.0 / 267MB 54.0% 896KB 0.2% weekly.1 / 267MB 54.0% 928KB 0.2% weekly.2 / 267MB 54.0% 1MB 0.2% weekly.3 /var 1237MB 10.4% 16MB 0.1% daily.0 /var 1237MB 10.4% 17MB 0.1% daily.1 /var 1237MB 10.4% 30MB 0.3% daily.2 /var 1237MB 10.4% 32MB 0.3% daily.3 /var 1237MB 10.4% 32MB 0.3% daily.4 /var 1237MB 10.4% 33MB 0.3% daily.5 /var 1237MB 10.4% 141MB 1.2% daily.6 /var 1237MB 10.4% 7MB 0.1% hourly.0 /var 1237MB 10.4% 7MB 0.1% hourly.1 /var 1237MB 10.4% 7MB 0.1% hourly.2 /var 1237MB 10.4% 8MB 0.1% hourly.3 /var 1237MB 10.4% 8MB 0.1% hourly.4 /var 1237MB 10.4% 8MB 0.1% hourly.5 /var 1237MB 10.4% 8MB 0.1% hourly.6 /var 1237MB 10.4% 8MB 0.1% hourly.7 /var 1237MB 10.4% 8MB 0.1% hourly.8 /var 1237MB 10.4% 8MB 0.1% hourly.9 /var 1237MB 10.4% 25MB 0.2% weekly.0 /usr 87545MB 74.1% 138MB 0.1% daily.0 /usr 87545MB 74.1% 217MB 0.2% daily.1 /usr 87545MB 74.1% 234MB 0.2% daily.2 /usr 87545MB 74.1% 287MB 0.2% daily.3 /usr 87545MB 74.1% 292MB 0.2% daily.4 /usr 87545MB 74.1% 278MB 0.2% daily.5 /usr 87545MB 74.1% 349MB 0.3% daily.6 /usr 87545MB 74.1% 88MB 0.1% hourly.0 /usr 87545MB 74.1% 200MB 0.2% hourly.1 /usr 87545MB 74.1% 864MB 0.7% weekly.0 /usr 87545MB 74.1% 721MB 0.6% weekly.1 /usr 87545MB 74.1% 782MB 0.7% weekly.2 /usr 87545MB 74.1% 4772MB 4.0% weekly.3 I am eager and willing to assist in anyway to investigate and eliminate this issue. -- Regards, Doug From kostikbel at gmail.com Tue May 5 12:13:25 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue May 5 12:13:36 2009 Subject: kern/94769: [ufs] Multiple file deletions on multi-snapshotted filesystems causes hang In-Reply-To: <200905042030.n44KU3Bp058343@freefall.freebsd.org> References: <200905042030.n44KU3Bp058343@freefall.freebsd.org> Message-ID: <20090505115119.GM1948@deviant.kiev.zoral.com.ua> On Mon, May 04, 2009 at 08:30:03PM +0000, Doug Poland wrote: > The following reply was made to PR kern/94769; it has been noted by GNATS. > > From: Doug Poland > To: bug-followup@FreeBSD.org, john@kozubik.com > Cc: > Subject: Re: kern/94769: [ufs] Multiple file deletions on multi-snapshotted > filesystems causes hang > Date: Mon, 4 May 2009 15:11:33 -0500 > > I recently started experiencing similar behavior on a 7.1-RELEASE i386 > host. In this case the deadlock occurs as soon as > sysutils/freebsd-snapshots run it's weekly cron entry: > > 0 * * * * root periodic-snapshot hourly > 0 0 * * * root periodic-snapshot daily > 0 0 * * 0 root periodic-snapshot weekly > > I am running a GENERIC kernel without quotas. > > Here's the list of snapshots on the various filesystems: > > Filesystem User User% Snap Snap% Snapshot > / 267MB 54.0% 704KB 0.1% daily.0 > / 267MB 54.0% 704KB 0.1% daily.1 > / 267MB 54.0% 704KB 0.1% daily.2 > / 267MB 54.0% 704KB 0.1% daily.3 > / 267MB 54.0% 704KB 0.1% daily.4 > / 267MB 54.0% 784KB 0.2% daily.5 > / 267MB 54.0% 784KB 0.2% daily.6 > / 267MB 54.0% 608KB 0.1% hourly.0 > / 267MB 54.0% 640KB 0.1% hourly.1 > / 267MB 54.0% 656KB 0.1% hourly.2 > / 267MB 54.0% 656KB 0.1% hourly.3 > / 267MB 54.0% 704KB 0.1% weekly.0 > / 267MB 54.0% 896KB 0.2% weekly.1 > / 267MB 54.0% 928KB 0.2% weekly.2 > / 267MB 54.0% 1MB 0.2% weekly.3 > /var 1237MB 10.4% 16MB 0.1% daily.0 > /var 1237MB 10.4% 17MB 0.1% daily.1 > /var 1237MB 10.4% 30MB 0.3% daily.2 > /var 1237MB 10.4% 32MB 0.3% daily.3 > /var 1237MB 10.4% 32MB 0.3% daily.4 > /var 1237MB 10.4% 33MB 0.3% daily.5 > /var 1237MB 10.4% 141MB 1.2% daily.6 > /var 1237MB 10.4% 7MB 0.1% hourly.0 > /var 1237MB 10.4% 7MB 0.1% hourly.1 > /var 1237MB 10.4% 7MB 0.1% hourly.2 > /var 1237MB 10.4% 8MB 0.1% hourly.3 > /var 1237MB 10.4% 8MB 0.1% hourly.4 > /var 1237MB 10.4% 8MB 0.1% hourly.5 > /var 1237MB 10.4% 8MB 0.1% hourly.6 > /var 1237MB 10.4% 8MB 0.1% hourly.7 > /var 1237MB 10.4% 8MB 0.1% hourly.8 > /var 1237MB 10.4% 8MB 0.1% hourly.9 > /var 1237MB 10.4% 25MB 0.2% weekly.0 > /usr 87545MB 74.1% 138MB 0.1% daily.0 > /usr 87545MB 74.1% 217MB 0.2% daily.1 > /usr 87545MB 74.1% 234MB 0.2% daily.2 > /usr 87545MB 74.1% 287MB 0.2% daily.3 > /usr 87545MB 74.1% 292MB 0.2% daily.4 > /usr 87545MB 74.1% 278MB 0.2% daily.5 > /usr 87545MB 74.1% 349MB 0.3% daily.6 > /usr 87545MB 74.1% 88MB 0.1% hourly.0 > /usr 87545MB 74.1% 200MB 0.2% hourly.1 > /usr 87545MB 74.1% 864MB 0.7% weekly.0 > /usr 87545MB 74.1% 721MB 0.6% weekly.1 > /usr 87545MB 74.1% 782MB 0.7% weekly.2 > /usr 87545MB 74.1% 4772MB 4.0% weekly.3 > > I am eager and willing to assist in anyway to investigate and eliminate > this issue. Try today stable/7 after the r190690. -------------- 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/20090505/3b499d1b/attachment.pgp From kmacy at FreeBSD.org Fri May 8 03:09:14 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Fri May 8 03:09:21 2009 Subject: bin/130105: [zfs] zfs send -R dumps core Message-ID: <200905080309.n4839D0M034154@freefall.freebsd.org> Synopsis: [zfs] zfs send -R dumps core Responsible-Changed-From-To: freebsd-fs->kmacy Responsible-Changed-By: kmacy Responsible-Changed-When: Fri May 8 03:08:17 UTC 2009 Responsible-Changed-Why: take over committing fix http://www.freebsd.org/cgi/query-pr.cgi?pr=130105 From dgerow at afflictions.org Sat May 9 19:00:08 2009 From: dgerow at afflictions.org (Damian Gerow) Date: Sat May 9 19:00:14 2009 Subject: kern/133373: [zfs] umass attachment causes ZFS checksum errors, data loss Message-ID: <200905091900.n49J067u033101@freefall.freebsd.org> The following reply was made to PR kern/133373; it has been noted by GNATS. From: Damian Gerow To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/133373: [zfs] umass attachment causes ZFS checksum errors, data loss Date: Sat, 9 May 2009 14:31:45 -0400 This PR can be closed, it was a problem with bounced buffers in the new USB2 code, and has since been fixed. From bugmaster at FreeBSD.org Mon May 11 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 11 11:07:55 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200905111106.n4BB6sLC085938@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int o kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/133134 fs [zfs] Missing ZFS zpool labels o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132551 fs [zfs] ZFS locks up on extattr_list_link syscall o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132337 fs [zfs] [panic] kernel panic in zfs_fuid_create_cred o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132145 fs [panic] File System Hard Crashes f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/131084 fs [xfs] xfs destroys itself after copying data o kern/131081 fs [zfs] User cannot delete a file when a ZFS dataset is o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs o kern/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs] [panic] changing into .zfs dir from nfs client c f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc 58 problems total. From pav at FreeBSD.org Mon May 11 21:25:47 2009 From: pav at FreeBSD.org (Pav Lucistnik) Date: Mon May 11 21:25:52 2009 Subject: pointyhat panic in nfs client code Message-ID: <1242075515.72992.119.camel@hood.oook.cz> Copying fs@.. panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 cpuid = 2 KDB: enter: panic [thread pid 0 tid 100029 ] Stopped at kdb_enter+0x3d: movq $0,0x3f5fb8(%rip) db> bt Tracing pid 0 tid 100029 td 0xffffff00018e1000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b _mtx_lock_flags() at _mtx_lock_flags+0xc5 clnt_vc_soupcall() at clnt_vc_soupcall+0x273 sowakeup() at sowakeup+0xf8 tcp_do_segment() at tcp_do_segment+0x23c9 tcp_input() at tcp_input+0x9ec ip_input() at ip_input+0xbc ether_demux() at ether_demux+0x1ed ether_input() at ether_input+0x171 em_rxeof() at em_rxeof+0x201 em_handle_rxtx() at em_handle_rxtx+0x4b taskqueue_run() at taskqueue_run+0x96 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffff240a6d40, rbp = 0 --- The box is in kdb on serial console for now. May 9 -CURRENT, I think. -- Pav Lucistnik A spoonful of curry, garlic and mustard helps the medicine go down... and come straight back up again. -- JLE on #angband -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090511/990f3494/attachment.pgp From linimon at FreeBSD.org Tue May 12 19:53:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue May 12 19:53:16 2009 Subject: kern/134491: [zfs] Hot spares are rather cold... Message-ID: <200905121953.n4CJr0st097811@freefall.freebsd.org> Old Synopsis: ZFS: Hot spares are rather cold... New Synopsis: [zfs] Hot spares are rather cold... Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 12 19:52:40 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134491 From linimon at FreeBSD.org Tue May 12 20:14:13 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue May 12 20:14:25 2009 Subject: kern/134496: [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt") Message-ID: <200905122014.n4CKECsV024873@freefall.freebsd.org> Old Synopsis: ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt") New Synopsis: [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt") Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 12 20:13:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134496 From randy at psg.com Wed May 13 08:29:45 2009 From: randy at psg.com (Randy Bush) Date: Wed May 13 08:29:52 2009 Subject: ZFSBoot try and bsdlabel bootstrap code In-Reply-To: <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> References: <367b2c980811191412h5e0af470k165b37edc2fc5853@mail.gmail.com> <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> Message-ID: next week, i have to do a system install on a 24tb array which has no cdrom. i want to use raidz2. the new issues to me are o install from usb stick o installing on a new zfs o boot from zfs i have a couple of systems where i did a small bootable gmirror partition on the first two drives, and then gave the rest of the drives, and other whole drives, to zfs. i could do that this time too, i guess. but i wondered if i could do an install which was pure zfs. i have been collecting email on the subject for six months. so now i have some clues and some confusion. is there a zfs capable loader? i will be doing this a jet-lagged. is there a recipe? randy From roberto at keltia.freenix.fr Wed May 13 08:39:40 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Wed May 13 08:39:47 2009 Subject: ZFSBoot try and bsdlabel bootstrap code In-Reply-To: References: <367b2c980811191412h5e0af470k165b37edc2fc5853@mail.gmail.com> <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> Message-ID: <20090513083936.GA35365@keltia.freenix.fr> According to Randy Bush: > i have been collecting email on the subject for six months. so now i > have some clues and some confusion. is there a zfs capable loader? > > i will be doing this a jet-lagged. is there a recipe? There are a few tutorials around here. I'd suggest starting with the following: http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ What's in there could help: http://wiki.freebsd.org/AppleMacbook Here is a translation into English of a french blog post about gpt only: http://translate.google.com/translate?prev=hp&hl=en&js=n&u=http%3A%2F%2Fbaptux.free.fr%2Findex.php%3Fpost%2F2009%2F04%2F18%2FChanger-le-disque-systeme-sur-FreeBSD&sl=fr&tl=en I also attach a script I've found (maybe here) too, to be used as an example. For the moment booting is only accepted from single or mirrored zpool, not raidz/raidz2 although Doug Rabson has patches for both. I plan to try to summarize all these into a wiki article (unless someone beat me to it) by playing with my vmware fusion setup. I plan to have a new server at home soon and ant it full zfs... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From roberto at keltia.freenix.fr Wed May 13 08:46:54 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Wed May 13 08:47:00 2009 Subject: ZFSBoot try and bsdlabel bootstrap code In-Reply-To: <367b2c980905130141t66fd1fffseeb355e3512e003f@mail.gmail.com> References: <367b2c980811191412h5e0af470k165b37edc2fc5853@mail.gmail.com> <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> <20090513083936.GA35365@keltia.freenix.fr> <367b2c980905130141t66fd1fffseeb355e3512e003f@mail.gmail.com> Message-ID: <20090513084651.GA35608@keltia.freenix.fr> According to Olivier SMEDTS: > Do you know if the patches allow booting on a degraded array ? >From what Doug said last week at BSDCan's WIP session, yes. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From olivier at gid0.org Wed May 13 09:14:29 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Wed May 13 09:14:37 2009 Subject: ZFSBoot try and bsdlabel bootstrap code In-Reply-To: <20090513083936.GA35365@keltia.freenix.fr> References: <367b2c980811191412h5e0af470k165b37edc2fc5853@mail.gmail.com> <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> <20090513083936.GA35365@keltia.freenix.fr> Message-ID: <367b2c980905130141t66fd1fffseeb355e3512e003f@mail.gmail.com> 2009/5/13 Ollivier Robert : > According to Randy Bush: >> i have been collecting email on the subject for six months. ?so now i >> have some clues and some confusion. ?is there a zfs capable loader? >> >> i will be doing this a jet-lagged. ?is there a recipe? > > There are a few tutorials around here. ?I'd suggest starting with the > following: > > http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ > > What's in there could help: > http://wiki.freebsd.org/AppleMacbook > > Here is a translation into English of a french blog ?post about gpt only: > http://translate.google.com/translate?prev=hp&hl=en&js=n&u=http%3A%2F%2Fbaptux.free.fr%2Findex.php%3Fpost%2F2009%2F04%2F18%2FChanger-le-disque-systeme-sur-FreeBSD&sl=fr&tl=en > > I also attach a script I've found (maybe here) too, to be used as an > example. ?For the moment booting is only accepted from single or mirrored > zpool, not raidz/raidz2 although Doug Rabson has patches for both. Do you know if the patches allow booting on a degraded array ? > I plan to try to summarize all these into a wiki article (unless someone > beat me to it) by playing with my vmware fusion setup. ?I plan to have a > new server at home soon and ant it full zfs... > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr > In memoriam to Ondine : http://ondine.keltia.net/ > > _______________________________________________ > 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" -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From ivoras at freebsd.org Wed May 13 12:00:52 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed May 13 12:01:24 2009 Subject: UFS2 and SSDs In-Reply-To: <49FC1BD0.4030306@T-Online.de> References: <49FC1BD0.4030306@T-Online.de> Message-ID: Juergen Dankoweit wrote: > Hello to the list, > > my question is, how does UFS2 behave on solid state disks? What about > performance, stability and data security? > There are no special optimizations or pessimizations, compared to other mainstream file systems, so - average performance, unchanged stability and data security. From kmacy at freebsd.org Wed May 13 12:51:32 2009 From: kmacy at freebsd.org (Kip Macy) Date: Wed May 13 12:51:38 2009 Subject: UFS2 and SSDs In-Reply-To: References: <49FC1BD0.4030306@T-Online.de> Message-ID: <3c1674c90905130529r70589318tf57198d24cf2bd57@mail.gmail.com> On Wed, May 13, 2009 at 5:00 AM, Ivan Voras wrote: > Juergen Dankoweit wrote: >> Hello to the list, >> >> my question is, how does UFS2 behave on solid state disks? What about >> performance, stability and data security? >> > > There are no special optimizations or pessimizations, compared to other > mainstream file systems, so - average performance, unchanged stability > and data security. > I accidentally bought a camera-grade SSD. Random write performance with UFS made it unusable. I ended up converting /usr to ZFS - since which time I've been very happy with performance. -Kip -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From tom.hurst at clara.net Wed May 13 14:09:29 2009 From: tom.hurst at clara.net (Thomas Hurst) Date: Wed May 13 14:09:36 2009 Subject: UFS2 and SSDs In-Reply-To: <3c1674c90905130529r70589318tf57198d24cf2bd57@mail.gmail.com> References: <49FC1BD0.4030306@T-Online.de> <3c1674c90905130529r70589318tf57198d24cf2bd57@mail.gmail.com> Message-ID: <20090513135335.GA42884@voi.aagh.net> * Kip Macy (kmacy@freebsd.org) wrote: > I accidentally bought a camera-grade SSD. Random write performance > with UFS made it unusable. I ended up converting /usr to ZFS - since > which time I've been very happy with performance. Did you try gjournal on it? SSD's should do better with sequential journal writes. -- Thomas 'Freaky' Hurst http://hur.st/ From ivoras at freebsd.org Wed May 13 14:31:45 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed May 13 14:31:52 2009 Subject: UFS2 and SSDs In-Reply-To: <20090513135335.GA42884@voi.aagh.net> References: <49FC1BD0.4030306@T-Online.de> <3c1674c90905130529r70589318tf57198d24cf2bd57@mail.gmail.com> <20090513135335.GA42884@voi.aagh.net> Message-ID: Thomas Hurst wrote: > * Kip Macy (kmacy@freebsd.org) wrote: > >> I accidentally bought a camera-grade SSD. Random write performance >> with UFS made it unusable. I ended up converting /usr to ZFS - since >> which time I've been very happy with performance. > > Did you try gjournal on it? SSD's should do better with sequential > journal writes. My guess is that it won't matter - the issue is "small writes" not "sequential writes". Gjournal will issue writes as it receives them - if it receives a bunch of small ones, it will pass them on in the same form, only sequential (the drive will still see a bunch of small writes). This works well for mechanical drives because of rotational properties but does nothing to SSDs. ZFS OTOH does a great deal of buffering. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090513/db349eb2/signature.pgp From kmacy at freebsd.org Wed May 13 14:51:05 2009 From: kmacy at freebsd.org (Kip Macy) Date: Wed May 13 14:51:12 2009 Subject: UFS2 and SSDs In-Reply-To: References: <49FC1BD0.4030306@T-Online.de> <3c1674c90905130529r70589318tf57198d24cf2bd57@mail.gmail.com> <20090513135335.GA42884@voi.aagh.net> Message-ID: <3c1674c90905130751s60757be2t8039965b71c75467@mail.gmail.com> On Wed, May 13, 2009 at 7:31 AM, Ivan Voras wrote: > Thomas Hurst wrote: >> * Kip Macy (kmacy@freebsd.org) wrote: >> >>> I accidentally bought a camera-grade SSD. Random write performance >>> with UFS made it unusable. I ended up converting /usr to ZFS - since >>> which time I've been very happy with performance. >> >> Did you try gjournal on it? ?SSD's should do better with sequential >> journal writes. > > My guess is that it won't matter - the issue is "small writes" not > "sequential writes". Gjournal will issue writes as it receives them - if > it receives a bunch of small ones, it will pass them on in the same > form, only sequential (the drive will still see a bunch of small > writes). This works well for mechanical drives because of rotational > properties but does nothing to SSDs. > > ZFS OTOH does a great deal of buffering. The benefits come from write-allocate - writes always end up being some multiple of erase blocks. With FFS the drive constantly has to GC partial blocks. -Kip -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From dfr at rabson.org Wed May 13 18:35:21 2009 From: dfr at rabson.org (Doug Rabson) Date: Wed May 13 18:35:27 2009 Subject: ZFSBoot try and bsdlabel bootstrap code In-Reply-To: References: <367b2c980811191412h5e0af470k165b37edc2fc5853@mail.gmail.com> <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> Message-ID: On 13 May 2009, at 09:29, Randy Bush wrote: > next week, i have to do a system install on a 24tb array which has no > cdrom. i want to use raidz2. the new issues to me are > o install from usb stick > o installing on a new zfs > o boot from zfs > > i have a couple of systems where i did a small bootable gmirror > partition on the first two drives, and then gave the rest of the > drives, > and other whole drives, to zfs. i could do that this time too, i > guess. but i wondered if i could do an install which was pure zfs. > > i have been collecting email on the subject for six months. so now i > have some clues and some confusion. is there a zfs capable loader? > > i will be doing this a jet-lagged. is there a recipe? There is basic support in the FreeBSD-current tree which covers booting from simple disks, mirrors and collections of mirrors. I have patches for raidz and raidz2 but they really aren't ready for prime time (they work in small test cases but not for larger real-world arrays). What you could do to allow the installation of ZFS boot code in the future is use GPT to partition the drives and create a small boot partition. Something like this: # gpt create -f da0 # gpt boot -b /boot/pmbr -g /boot/gptzfsboot da0 # gpt add -t freebsd-zfs da0 The bootstrap code in /boot/gptzfsboot doesn't currently support raidz or raidz2 but initialising the array this way will make it easier to install a functioning bootstrap at a later date. From randy at psg.com Thu May 14 07:44:44 2009 From: randy at psg.com (Randy Bush) Date: Thu May 14 07:44:50 2009 Subject: ZFSBoot try and bsdlabel bootstrap code In-Reply-To: <20090513083936.GA35365@keltia.freenix.fr> References: <367b2c980811191412h5e0af470k165b37edc2fc5853@mail.gmail.com> <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> <20090513083936.GA35365@keltia.freenix.fr> Message-ID: > There are a few tutorials around here. I'd suggest starting with the > following: > > http://lulf.geeknest.org/blog/freebsd/Setting_up_a_zfs-only_system/ > > What's in there could help: > http://wiki.freebsd.org/AppleMacbook > > Here is a translation into English of a french blog post about gpt only: > http://translate.google.com/translate?prev=hp&hl=en&js=n&u=http%3A%2F%2Fbaptux.free.fr%2Findex.php%3Fpost%2F2009%2F04%2F18%2FChanger-le-disque-systeme-sur-FreeBSD&sl=fr&tl=en excellent! thank you. and doug hit me with a few clues too. > I also attach a script I've found (maybe here) too, to be used as an > example. i can not see that a script is attached. thank you! randy From roberto at keltia.freenix.fr Thu May 14 10:17:35 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Thu May 14 10:18:08 2009 Subject: ZFSBoot try and bsdlabel bootstrap code In-Reply-To: References: <367b2c980811191412h5e0af470k165b37edc2fc5853@mail.gmail.com> <16C31872-6A83-4FAB-AC85-213D604CDDE4@rabson.org> <20090513083936.GA35365@keltia.freenix.fr> Message-ID: <20090514101556.GA62335@roberto-al.eurocontrol.fr> According to Randy Bush: > excellent! thank you. and doug hit me with a few clues too. Good. > > I also attach a script I've found (maybe here) too, to be used as an > > example. > > i can not see that a script is attached. It must have been stripped out, maybe at your end. Anyway: http://people.freebsd.org/~roberto/create-zfsboot-gpt.sh -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From dfr at rabson.org Thu May 14 15:24:50 2009 From: dfr at rabson.org (Doug Rabson) Date: Thu May 14 15:24:57 2009 Subject: Booting from ZFS raidz In-Reply-To: <20090201072432.GA25276@server.vk2pj.dyndns.org> References: <9461581F-F354-486D-961D-3FD5B1EF007C@rabson.org> <20090201072432.GA25276@server.vk2pj.dyndns.org> Message-ID: <246ecf0c87f944d70c5562eeed4165c9@mail.rabson.org> On Sun, 1 Feb 2009 18:24:32 +1100, Peter Jeremy wrote: > On 2008-Dec-17 18:25:51 +0000, Doug Rabson wrote: >>I've been working on adding raidz and raidz2 support to the boot code >>and I have a patch which could use some testing if anyone here is >>interested. This http://people.freebsd.org/~dfr/ >>raidzboot-17122008.diff adds support for raidz and raidz2. The easiest >>way to prepare a bootable pool is to put a GPT boot partition on each >>disk that will make up the raidz pool and install gptzfsboot on the >>boot partition of every drive. > > This sounds great so I thought I'd try it. Unfortunately, it didn't > work on my degraded pool [ZFS managed to kill a disk and I thought I'd > experiment]. When I tried to boot, I got: > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type lld > > FreeBSD/i386 boot > Default: tank:/boot/loader > boot: > > The boot loader is up-to-date and was built with 'LOADER_ZFS_SUPPORT'. > Any ideas? I fixed a bug in the patch. Try this version: http://people.freebsd.org/~dfr/raidzboot-14052009.diff From peterjeremy at optushome.com.au Fri May 15 00:31:20 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri May 15 00:31:27 2009 Subject: Booting from ZFS raidz In-Reply-To: <246ecf0c87f944d70c5562eeed4165c9@mail.rabson.org> References: <9461581F-F354-486D-961D-3FD5B1EF007C@rabson.org> <20090201072432.GA25276@server.vk2pj.dyndns.org> <246ecf0c87f944d70c5562eeed4165c9@mail.rabson.org> Message-ID: <20090514210616.GA57001@server.vk2pj.dyndns.org> On 2009-May-14 16:25:02 +0100, Doug Rabson wrote: >I fixed a bug in the patch. Try this version: >http://people.freebsd.org/~dfr/raidzboot-14052009.diff Thanks for that but I'm not in a position to test it at present. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090515/061ce015/attachment.pgp From avg at icyb.net.ua Fri May 15 10:49:51 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 15 10:49:58 2009 Subject: stable/7: shutdown stuck in zfs_umount (z_op_cnt > 0) Message-ID: <4A0D48CB.7030707@icyb.net.ua> Quite frequently when rebooting or shutting down after long uptime my amd64 stable/7 system gets stuck in shutdown after printing "All buffers synced". Below is some kgdb examination after breaking to ddb and inducing panic. I also see lots of threads with zfs-related names (also below). Any ideas/suggestions on cause/fix/workaround? Thanks! (kgdb) i thr ... 3 Thread 100002 (PID=1: init) sched_switch (td=0xffffff0001411a50, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 ... (kgdb) thr 3 [Switching to thread 3 (Thread 100002)]#0 sched_switch (td=0xffffff0001411a50, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xffffff0001411a50, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xffffffff802b35d9 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 #2 0xffffffff802e0085 in sleepq_switch (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xffffffff802e0c0f in sleepq_timedwait (wchan=0xffffffff80660be8) at /usr/src/sys/kern/subr_sleepqueue.c:615 #4 0xffffffff802b3a27 in _sleep (ident=0xffffffff80660be8, lock=0x0, priority=0, wmesg=0xffffffff807e3ce3 "soldelay", timo=1) at /usr/src/sys/kern/kern_synch.c:226 #5 0xffffffff802b3b1c in pause (wmesg=Variable "wmesg" is not available. ) at /usr/src/sys/kern/kern_synch.c:334 #6 0xffffffff807cf8ce in zfs_umount (vfsp=0xffffff00076b7000, fflag=524288, td=0xffffff0001411a50) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:738 #7 0xffffffff80326bbb in dounmount (mp=0xffffff00076b7000, flags=524288, td=0xffffff0001411a50) at /usr/src/sys/kern/vfs_mount.c:1298 #8 0xffffffff80329e91 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:3099 #9 0xffffffff802abcdd in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:400 #10 0xffffffff802ac3f4 in reboot (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:172 #11 0xffffffff8044827d in syscall (frame=0xfffffffe8001ec80) at /usr/src/sys/amd64/amd64/trap.c:900 #12 0xffffffff8042d37b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #13 0x0000000000407e7c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 6 #6 0xffffffff807cf8ce in zfs_umount (vfsp=0xffffff00076b7000, fflag=524288, td=0xffffff0001411a50) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:738 738 delay(1); (kgdb) list 733 * mutex in order to cv_signal 734 * - only occurs on forced unmount in the rare case when 735 * there are outstanding threads within the file system. 736 */ 737 while (zfsvfs->z_op_cnt) { 738 delay(1); 739 } 740 } 741 742 zfs_objset_close(zfsvfs); (kgdb) p zfsvfs->z_op_cnt $11 = 2 (kgdb) p *zfsvfs $12 = {z_vfs = 0xffffff00076b7000, z_parent = 0xffffff00076a7000, z_os = 0xffffff000768aa60, z_root = 3, z_unlinkedobj = 2, z_max_blksz = 131072, z_assign = 2, z_log = 0xffffff00076d1a00, z_acl_mode = 2, z_acl_inherit = 4, z_atime = 0, z_unmounted1 = 1, z_unmounted2 = 0, z_op_cnt = 2, z_um_lock = {lock_object = {lo_name = 0xffffffff807e3d2a "zfsvfs->z_um_lock", lo_type = 0xffffffff807e3d2a "zfsvfs->z_um_lock", lo_flags = 41484288, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0}, z_all_znodes = { list_size = 432, list_offset = 400, list_head = {list_next = 0xffffff00076a7098, list_prev = 0xffffff00076a7098}}, z_znodes_lock = {lock_object = {lo_name = 0xffffffff807e3d13 "zfsvfs->z_znodes_lock", lo_type = 0xffffffff807e3d13 "zfsvfs->z_znodes_lock", lo_flags = 41484288, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0}, z_ctldir = 0x0, z_show_ctldir = 0, z_issnap = 0, z_hold_mtx = {{lock_object = {lo_name = 0xffffffff807e3554 "zfsvfs->z_hold_mtx[i]", lo_type = 0xffffffff807e3554 "zfsvfs->z_hold_mtx[i]", lo_flags = 41484288, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0} }} (kgdb) p *zfsvfs->z_vfs $13 = {mnt_lock = {lk_object = {lo_name = 0xffffffff804bb9b5 "vfslock", lo_type = 0xffffffff804bb9b5 "vfslock", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xffffffff8065ff30, lk_flags = 1310720, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 0, lk_lockholder = 0xffffff0001411a50, lk_newlock = 0x0}, mnt_mtx = {lock_object = {lo_name = 0xffffffff804bb9a4 "struct mount mtx", lo_type = 0xffffffff804bb9a4 "struct mount mtx", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, mnt_gen = 1, mnt_list = {tqe_next = 0x0, tqe_prev = 0xffffff00076b7408}, mnt_op = 0xffffffff807e6460, mnt_vfc = 0xffffffff807e6400, mnt_vnodecovered = 0xffffff00076cd1f8, mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0, tqh_last = 0xffffff00076b70c0}, mnt_nvnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag = 1627389961, mnt_flag = 268439552, mnt_noasync = 0, mnt_opt = 0xffffff00076cb060, mnt_optnew = 0x0, mnt_maxsymlinklen = 0, mnt_stat = {f_version = 537068824, f_type = 1, f_flags = 268439552, f_bsize = 131072, f_iosize = 131072, f_blocks = 460060, f_bfree = 458184, f_bavail = 458184, f_files = 487824, f_ffree = 458184, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {-673697102, -1110623743}}, f_charspare = '\0' , f_fstypename = "zfs", '\0' , f_mntfromname = "tank/var/db", '\0' , f_mntonname = "/var/db", '\0' }, mnt_cred = 0xffffff00076bd000, mnt_data = 0xffffff00076a7000, mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label = 0x0, mnt_hashseed = 192489048, mnt_markercnt = 0, mnt_holdcnt = 0, mnt_holdcntwaiters = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider = 0x0, mnt_explock = {lk_object = {lo_name = 0xffffffff804bb9bd "explock", lo_type = 0xffffffff804bb9bd "explock", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xffffffff8065ff60, lk_flags = 0, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_timo = 0, lk_lockholder = 0xffffffffffffffff, lk_newlock = 0x0}} 131 Thread 100341 (PID=4039: zvol:worker zvol/ta) sched_switch (td=0xffffff00a87a5000, newtd=Variable "newtd" is not available. 130 Thread 100257 (PID=4038: zil_clean) sched_switch (td=0xffffff0011b1a000, newtd=Variable "newtd" is not available. 125 Thread 100127 (PID=210: zil_clean) sched_switch (td=0xffffff00076946e0, newtd=Variable "newtd" is not available. 124 Thread 100126 (PID=209: zil_clean) sched_switch (td=0xffffff0004f84370, newtd=Variable "newtd" is not available. 123 Thread 100125 (PID=208: zil_clean) sched_switch (td=0xffffff0004f846e0, newtd=Variable "newtd" is not available. 122 Thread 100124 (PID=207: zil_clean) sched_switch (td=0xffffff0007694a50, newtd=Variable "newtd" is not available. 121 Thread 100123 (PID=206: zil_clean) sched_switch (td=0xffffff0004f84a50, newtd=Variable "newtd" is not available. 120 Thread 100122 (PID=205: zil_clean) sched_switch (td=0xffffff0007695000, newtd=Variable "newtd" is not available. 119 Thread 100060 (PID=204: zil_clean) sched_switch (td=0xffffff0004d2e000, newtd=Variable "newtd" is not available. 118 Thread 100121 (PID=203: zil_clean) sched_switch (td=0xffffff0007695370, newtd=Variable "newtd" is not available. 117 Thread 100059 (PID=202: zil_clean) sched_switch (td=0xffffff0004d2e370, newtd=Variable "newtd" is not available. 116 Thread 100057 (PID=201: zil_clean) sched_switch (td=0xffffff0004d2ea50, newtd=Variable "newtd" is not available. 115 Thread 100120 (PID=200: zil_clean) sched_switch (td=0xffffff0004d43370, newtd=Variable "newtd" is not available. 114 Thread 100070 (PID=199: zil_clean) sched_switch (td=0xffffff0004d41a50, newtd=Variable "newtd" is not available. 113 Thread 100058 (PID=198: zil_clean) sched_switch (td=0xffffff0004d2e6e0, newtd=Variable "newtd" is not available. 112 Thread 100055 (PID=197: zil_clean) sched_switch (td=0xffffff0004d2f370, newtd=Variable "newtd" is not available. 111 Thread 100076 (PID=196: zil_clean) sched_switch (td=0xffffff0004d40370, newtd=Variable "newtd" is not available. 110 Thread 100056 (PID=195: zil_clean) sched_switch (td=0xffffff0004d2f000, newtd=Variable "newtd" is not available. 109 Thread 100069 (PID=194: zil_clean) sched_switch (td=0xffffff0004d42000, newtd=Variable "newtd" is not available. 108 Thread 100053 (PID=193: zil_clean) sched_switch (td=0xffffff0004d2fa50, newtd=Variable "newtd" is not available. 107 Thread 100117 (PID=192: zil_clean) sched_switch (td=0xffffff0004d65000, newtd=Variable "newtd" is not available. 106 Thread 100054 (PID=191: zil_clean) sched_switch (td=0xffffff0004d2f6e0, newtd=Variable "newtd" is not available. 105 Thread 100078 (PID=190: zil_clean) sched_switch (td=0xffffff0004d686e0, newtd=Variable "newtd" is not available. 104 Thread 100111 (PID=189: zil_clean) sched_switch (td=0xffffff0004d676e0, newtd=Variable "newtd" is not available. 103 Thread 100077 (PID=188: zil_clean) sched_switch (td=0xffffff0004d40000, newtd=Variable "newtd" is not available. 102 Thread 100067 (PID=187: zil_clean) sched_switch (td=0xffffff0004d426e0, newtd=Variable "newtd" is not available. 101 Thread 100068 (PID=186: zil_clean) sched_switch (td=0xffffff0004d42370, newtd=Variable "newtd" is not available. 100 Thread 100112 (PID=185: zil_clean) sched_switch (td=0xffffff0004d67370, newtd=Variable "newtd" is not available. 99 Thread 100075 (PID=184: zil_clean) sched_switch (td=0xffffff0004d406e0, newtd=Variable "newtd" is not available. 98 Thread 100119 (PID=183: zil_clean) sched_switch (td=0xffffff0004d436e0, newtd=Variable "newtd" is not available. 97 Thread 100114 (PID=182: zil_clean) sched_switch (td=0xffffff0004d65a50, newtd=Variable "newtd" is not available. 96 Thread 100118 (PID=181: zil_clean) sched_switch (td=0xffffff0004d43a50, newtd=Variable "newtd" is not available. 95 Thread 100115 (PID=180: zil_clean) sched_switch (td=0xffffff0004d656e0, newtd=Variable "newtd" is not available. 94 Thread 100113 (PID=179: zil_clean) sched_switch (td=0xffffff0004d67000, newtd=Variable "newtd" is not available. 93 Thread 100073 (PID=178: zil_clean) sched_switch (td=0xffffff0004d41000, newtd=Variable "newtd" is not available. 92 Thread 100074 (PID=177: zil_clean) sched_switch (td=0xffffff0004d40a50, newtd=Variable "newtd" is not available. 91 Thread 100071 (PID=176: zil_clean) sched_switch (td=0xffffff0004d416e0, newtd=Variable "newtd" is not available. 90 Thread 100072 (PID=175: zil_clean) sched_switch (td=0xffffff0004d41370, newtd=Variable "newtd" is not available. 89 Thread 100116 (PID=174: zil_clean) sched_switch (td=0xffffff0004d65370, newtd=Variable "newtd" is not available. 88 Thread 100066 (PID=173: zil_clean) sched_switch (td=0xffffff0004d42a50, newtd=Variable "newtd" is not available. 87 Thread 100063 (PID=172: zil_clean) sched_switch (td=0xffffff0004d2b370, newtd=Variable "newtd" is not available. 86 Thread 100064 (PID=171: zil_clean) sched_switch (td=0xffffff0004d2b000, newtd=Variable "newtd" is not available. 85 Thread 100065 (PID=170: zil_clean) sched_switch (td=0xffffff0004d43000, newtd=Variable "newtd" is not available. 84 Thread 100109 (PID=109: zil_clean) sched_switch (td=0xffffff0004d67a50, newtd=Variable "newtd" is not available. 80 Thread 100105 (PID=105: vdev:worker ad16s1d) sched_switch (td=0xffffff0004d68000, newtd=Variable "newtd" is not available. 79 Thread 100104 (PID=104: vdev:worker ad10s2d) sched_switch (td=0xffffff0004f87000, newtd=Variable "newtd" is not available. 78 Thread 100103 (PID=103: vdev:worker ad6s2d) sched_switch (td=0xffffff0004d68370, newtd=Variable "newtd" is not available. 77 Thread 100102 (PID=102: spa_zio_intr_5) sched_switch (td=0xffffff0004f87370, newtd=Variable "newtd" is not available. 76 Thread 100101 (PID=101: spa_zio_intr_5) sched_switch (td=0xffffff0004f876e0, newtd=Variable "newtd" is not available. 75 Thread 100100 (PID=100: spa_zio_issue_5) sched_switch (td=0xffffff0004f87a50, newtd=Variable "newtd" is not available. 74 Thread 100099 (PID=99: spa_zio_issue_5) sched_switch (td=0xffffff0004f88000, newtd=Variable "newtd" is not available. 73 Thread 100098 (PID=98: spa_zio_intr_4) sched_switch (td=0xffffff0004f88370, newtd=Variable "newtd" is not available. 72 Thread 100097 (PID=97: spa_zio_intr_4) sched_switch (td=0xffffff0004d68a50, newtd=Variable "newtd" is not available. 71 Thread 100096 (PID=96: spa_zio_issue_4) sched_switch (td=0xffffff0004f67000, newtd=Variable "newtd" is not available. 70 Thread 100095 (PID=95: spa_zio_issue_4) sched_switch (td=0xffffff0004f67370, newtd=Variable "newtd" is not available. 69 Thread 100094 (PID=94: spa_zio_intr_3) sched_switch (td=0xffffff0004f676e0, newtd=Variable "newtd" is not available. 68 Thread 100093 (PID=93: spa_zio_intr_3) sched_switch (td=0xffffff0004f67a50, newtd=Variable "newtd" is not available. 67 Thread 100092 (PID=92: spa_zio_issue_3) sched_switch (td=0xffffff0004f69000, newtd=Variable "newtd" is not available. 66 Thread 100091 (PID=91: spa_zio_issue_3) sched_switch (td=0xffffff0004f69370, newtd=Variable "newtd" is not available. 65 Thread 100090 (PID=90: spa_zio_intr_2) sched_switch (td=0xffffff0004f696e0, newtd=Variable "newtd" is not available. 64 Thread 100089 (PID=89: spa_zio_intr_2) sched_switch (td=0xffffff0004f69a50, newtd=Variable "newtd" is not available. 63 Thread 100088 (PID=88: spa_zio_issue_2) sched_switch (td=0xffffff0004f6a000, newtd=Variable "newtd" is not available. 62 Thread 100087 (PID=87: spa_zio_issue_2) sched_switch (td=0xffffff0004f6a370, newtd=Variable "newtd" is not available. 61 Thread 100086 (PID=86: spa_zio_intr_1) sched_switch (td=0xffffff0004f6a6e0, newtd=Variable "newtd" is not available. 60 Thread 100085 (PID=85: spa_zio_intr_1) sched_switch (td=0xffffff0004f6aa50, newtd=Variable "newtd" is not available. 59 Thread 100084 (PID=84: spa_zio_issue_1) sched_switch (td=0xffffff0004f6b000, newtd=Variable "newtd" is not available. 58 Thread 100083 (PID=83: spa_zio_issue_1) sched_switch (td=0xffffff0004f6b370, newtd=Variable "newtd" is not available. 57 Thread 100082 (PID=82: spa_zio_intr_0) sched_switch (td=0xffffff0003310370, newtd=Variable "newtd" is not available. 56 Thread 100081 (PID=81: spa_zio_intr_0) sched_switch (td=0xffffff00033106e0, newtd=Variable "newtd" is not available. 55 Thread 100080 (PID=80: spa_zio_issue_0) sched_switch (td=0xffffff0003310a50, newtd=Variable "newtd" is not available. 54 Thread 100079 (PID=79: spa_zio_issue_0) sched_switch (td=0xffffff0004cd4000, newtd=Variable "newtd" is not available. -- Andriy Gapon From 000.fbsd at quip.cz Fri May 15 11:27:47 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri May 15 11:27:54 2009 Subject: stable/7: shutdown stuck in zfs_umount (z_op_cnt > 0) In-Reply-To: <4A0D48CB.7030707@icyb.net.ua> References: <4A0D48CB.7030707@icyb.net.ua> Message-ID: <4A0D4DAF.3080902@quip.cz> Andriy Gapon wrote: > Quite frequently when rebooting or shutting down after long uptime my amd64 > stable/7 system gets stuck in shutdown after printing "All buffers synced". > Below is some kgdb examination after breaking to ddb and inducing panic. > I also see lots of threads with zfs-related names (also below). > Any ideas/suggestions on cause/fix/workaround? > Thanks! Just "me too" with amd64 7-STABLE (pre 7.2-RELEASE) and onetime with 7.2-RC1 i386 in Qemu session (also with ZFS mounted filesystem) Miroslav Lachman From avg at icyb.net.ua Fri May 15 12:21:59 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 15 12:22:05 2009 Subject: stable/7: shutdown stuck in zfs_umount (z_op_cnt > 0) In-Reply-To: <4A0D48CB.7030707@icyb.net.ua> References: <4A0D48CB.7030707@icyb.net.ua> Message-ID: <4A0D5E64.1050500@icyb.net.ua> Red herring or not (I don't see the general picture of zfs code), but it seems that there is no ZFS_EXIT for return at the end of zfsctl_snapdir_lookup function. P.S. C++ RAII could have been handy in this case [or not] :-) -- Andriy Gapon From avg at icyb.net.ua Fri May 15 12:39:21 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 15 12:39:38 2009 Subject: stable/7: shutdown stuck in zfs_umount (z_op_cnt > 0) In-Reply-To: <4A0D5E64.1050500@icyb.net.ua> References: <4A0D48CB.7030707@icyb.net.ua> <4A0D5E64.1050500@icyb.net.ua> Message-ID: <4A0D6276.2080902@icyb.net.ua> on 15/05/2009 15:21 Andriy Gapon said the following: > Red herring or not (I don't see the general picture of zfs code), but it seems > that there is no ZFS_EXIT for return at the end of zfsctl_snapdir_lookup function. > > P.S. C++ RAII could have been handy in this case [or not] :-) Couple of notes: 1. this doesn't appear to be a red herring as ZFS_EXIT before the last return statement can be found in head 2. yes, I do mount snapshots from time to time (backups, etc) -- Andriy Gapon From kmacy at freebsd.org Fri May 15 20:11:22 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri May 15 20:11:29 2009 Subject: stable/7: shutdown stuck in zfs_umount (z_op_cnt > 0) In-Reply-To: <4A0D6276.2080902@icyb.net.ua> References: <4A0D48CB.7030707@icyb.net.ua> <4A0D5E64.1050500@icyb.net.ua> <4A0D6276.2080902@icyb.net.ua> Message-ID: <3c1674c90905151311jc3cc9a8jb60eb526d849a616@mail.gmail.com> On Fri, May 15, 2009 at 5:39 AM, Andriy Gapon wrote: > on 15/05/2009 15:21 Andriy Gapon said the following: >> Red herring or not (I don't see the general picture of zfs code), but it seems >> that there is no ZFS_EXIT for return at the end of zfsctl_snapdir_lookup function. >> >> P.S. C++ RAII could have been handy in this case [or not] :-) > > Couple of notes: > 1. this doesn't appear to be a red herring as ZFS_EXIT before the last return > statement can be found in head > 2. yes, I do mount snapshots from time to time (backups, etc) > Thanks for the bug reports. Unfortunately, pjd is very busy and I do not intend to track down bugs in a very old version of ZFS. Your best bet will be to test the MFC patch when it is ready in a day or two. Cheers, Kip From kmacy at freebsd.org Fri May 15 23:28:59 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri May 15 23:29:05 2009 Subject: RFT: ZFS MFC Message-ID: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From noackjr at alumni.rice.edu Sat May 16 00:34:13 2009 From: noackjr at alumni.rice.edu (Jonathan Noack) Date: Sat May 16 00:34:46 2009 Subject: Booting from ZFS raidz In-Reply-To: <246ecf0c87f944d70c5562eeed4165c9@mail.rabson.org> References: <9461581F-F354-486D-961D-3FD5B1EF007C@rabson.org> <20090201072432.GA25276@server.vk2pj.dyndns.org> <246ecf0c87f944d70c5562eeed4165c9@mail.rabson.org> Message-ID: <9cc826f0720e1624489dd6e6d384babc.squirrel@www.noacks.org> On Thu, May 14, 2009 10:25, Doug Rabson wrote: > I fixed a bug in the patch. Try this version: > http://people.freebsd.org/~dfr/raidzboot-14052009.diff I know the bug fix was for booting from degraded pools, but I can at least give you a "no regression" report. I just set up a new amd64 box and was able to boot from a raidz1 pool using your latest patch. Getting this working from scratch was tedious but not too complicated. I followed lulf's instructions (http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-system/) using the May snapshot fixit CD. Only differences were that I set up all 4 disks with gpart (identically), created a raidz1 pool, and used a patched gptzfsboot that I cross-compiled on my 7.2 i386 box for the bootcode (applied to all 4 disks). If only I had remembered to patch my /usr/src tree before rebuilding world and rebooting... *sigh* Once more unto the fixit breach... :) -Jon From avg at icyb.net.ua Sat May 16 06:57:15 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Sat May 16 06:57:21 2009 Subject: stable/7: shutdown stuck in zfs_umount (z_op_cnt > 0) In-Reply-To: <3c1674c90905151311jc3cc9a8jb60eb526d849a616@mail.gmail.com> References: <4A0D48CB.7030707@icyb.net.ua> <4A0D5E64.1050500@icyb.net.ua> <4A0D6276.2080902@icyb.net.ua> <3c1674c90905151311jc3cc9a8jb60eb526d849a616@mail.gmail.com> Message-ID: <4A0E63C6.4050303@icyb.net.ua> on 15/05/2009 23:11 Kip Macy said the following: > On Fri, May 15, 2009 at 5:39 AM, Andriy Gapon wrote: >> on 15/05/2009 15:21 Andriy Gapon said the following: >>> Red herring or not (I don't see the general picture of zfs code), but it seems >>> that there is no ZFS_EXIT for return at the end of zfsctl_snapdir_lookup function. >>> >>> P.S. C++ RAII could have been handy in this case [or not] :-) >> Couple of notes: >> 1. this doesn't appear to be a red herring as ZFS_EXIT before the last return >> statement can be found in head >> 2. yes, I do mount snapshots from time to time (backups, etc) >> > > > Thanks for the bug reports. Unfortunately, pjd is very busy and I do > not intend to track down bugs in a very old version of ZFS. Your best > bet will be to test the MFC patch when it is ready in a day or two. Actually I already fixed this for meself with the below patch :-) Nevertheless, MFC news are great! Thank you for the work, you can count on me as a tester. diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c index cb789c0..7e06ed2 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c @@ -745,6 +745,7 @@ domount: VN_RELE(*vpp); *vpp = NULL; } + ZFS_EXIT(zfsvfs); return (err); } -- Andriy Gapon From kmacy at FreeBSD.org Sun May 17 04:28:08 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Sun May 17 04:28:16 2009 Subject: kern/134496: [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt") Message-ID: <200905170428.n4H4S7Gj094456@freefall.freebsd.org> Synopsis: [zfs] [panic] ZFS pool export occasionally causes a kernel panic ("vrele: negative ref cnt") State-Changed-From-To: open->feedback State-Changed-By: kmacy State-Changed-When: Sun May 17 04:26:54 UTC 2009 State-Changed-Why: waiting for feedback http://www.freebsd.org/cgi/query-pr.cgi?pr=134496 From kmacy at FreeBSD.org Sun May 17 04:48:22 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Sun May 17 04:48:29 2009 Subject: kern/133150: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data Message-ID: <200905170448.n4H4mM93022279@freefall.freebsd.org> Synopsis: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data State-Changed-From-To: open->feedback State-Changed-By: kmacy State-Changed-When: Sun May 17 04:47:42 UTC 2009 State-Changed-Why: awaiting feedback on ZFS_MFC branch http://www.freebsd.org/cgi/query-pr.cgi?pr=133150 From kmacy at FreeBSD.org Sun May 17 05:50:31 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Sun May 17 05:50:37 2009 Subject: kern/131081: [zfs] User cannot delete a file when a ZFS dataset is full. Message-ID: <200905170550.n4H5oTol011786@freefall.freebsd.org> Synopsis: [zfs] User cannot delete a file when a ZFS dataset is full. State-Changed-From-To: open->feedback State-Changed-By: kmacy State-Changed-When: Sun May 17 05:49:18 UTC 2009 State-Changed-Why: 1) do you have snapshots? 2) could you try: http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ Responsible-Changed-From-To: freebsd-fs->kmacy Responsible-Changed-By: kmacy Responsible-Changed-When: Sun May 17 05:49:18 UTC 2009 Responsible-Changed-Why: 1) do you have snapshots? 2) could you try: http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ http://www.freebsd.org/cgi/query-pr.cgi?pr=131081 From sudakov at sibptus.tomsk.ru Sun May 17 12:50:44 2009 From: sudakov at sibptus.tomsk.ru (Victor Sudakov) Date: Sun May 17 12:50:51 2009 Subject: kern/131081: [zfs] User cannot delete a file when a ZFS dataset is full. In-Reply-To: <200905170550.n4H5oTol011786@freefall.freebsd.org> References: <200905170550.n4H5oTol011786@freefall.freebsd.org> Message-ID: <20090517115036.GA13638@admin.sibptus.tomsk.ru> kmacy@FreeBSD.org wrote: > Synopsis: [zfs] User cannot delete a file when a ZFS dataset is full. > > State-Changed-From-To: open->feedback > State-Changed-By: kmacy > State-Changed-When: Sun May 17 05:49:18 UTC 2009 > State-Changed-Why: > > > 1) do you have snapshots? No, I don't. [sudakov@vas ~] zfs list NAME USED AVAIL REFER MOUNTPOINT d01 96,7G 9,57G 795K /d01 d01/home 4,71G 3,29G 4,71G /home d01/media 90,4G 9,57G 90,4G /msdos d01/ports 895M 9,57G 895M /usr/ports d01/soft 764M 9,57G 764M /usr/local d01/swap 90K 9,57G 90K - [sudakov@vas ~] dd if=/dev/zero of=bigfile bs=1m dd: bigfile: Disc quota exceeded 3369+0 records in 3368+1 records out 3532128256 bytes transferred in 115.604244 secs (30553621 bytes/sec) [sudakov@vas ~] rm bigfile rm: bigfile: Disc quota exceeded [sudakov@vas ~] > > 2) could you try: http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ Excuse me, what should I do with this? I could try a patch against 7.1-RELEASE if you give me one. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From kmacy at freebsd.org Sun May 17 20:19:44 2009 From: kmacy at freebsd.org (Kip Macy) Date: Sun May 17 20:19:50 2009 Subject: kern/131081: [zfs] User cannot delete a file when a ZFS dataset is full. In-Reply-To: <20090517115036.GA13638@admin.sibptus.tomsk.ru> References: <200905170550.n4H5oTol011786@freefall.freebsd.org> <20090517115036.GA13638@admin.sibptus.tomsk.ru> Message-ID: <3c1674c90905171319t7443dbf9xfbc4affe8c86da60@mail.gmail.com> On Sun, May 17, 2009 at 4:50 AM, Victor Sudakov wrote: > kmacy@FreeBSD.org wrote: >> Synopsis: [zfs] User cannot delete a file when a ZFS dataset is full. >> >> State-Changed-From-To: open->feedback >> State-Changed-By: kmacy >> State-Changed-When: Sun May 17 05:49:18 UTC 2009 >> State-Changed-Why: >> >> >> 1) do you have snapshots? > > No, I don't. > > [sudakov@vas ~] zfs list > NAME ? ? ? ?USED ?AVAIL ?REFER ?MOUNTPOINT > d01 ? ? ? ?96,7G ?9,57G ? 795K ?/d01 > d01/home ? 4,71G ?3,29G ?4,71G ?/home > d01/media ?90,4G ?9,57G ?90,4G ?/msdos > d01/ports ? 895M ?9,57G ? 895M ?/usr/ports > d01/soft ? ?764M ?9,57G ? 764M ?/usr/local > d01/swap ? ? 90K ?9,57G ? ?90K ?- > [sudakov@vas ~] dd if=/dev/zero of=bigfile bs=1m > dd: bigfile: Disc quota exceeded > 3369+0 records in > 3368+1 records out > 3532128256 bytes transferred in 115.604244 secs (30553621 bytes/sec) > [sudakov@vas ~] rm bigfile > rm: bigfile: Disc quota exceeded > [sudakov@vas ~] > >> >> 2) could you try: http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ > > Excuse me, what should I do with this? > > I could try a patch against 7.1-RELEASE if you give me one. I don't envision a patch for 7.1-RELEASE. This is a MFC to 7-STABLE. FWIW, I am not able to reproduce this in a VM. -Kip From kmacy at freebsd.org Sun May 17 23:38:43 2009 From: kmacy at freebsd.org (Kip Macy) Date: Sun May 17 23:38:54 2009 Subject: RELENG 7.2 with v13 ZFS branch Message-ID: <3c1674c90905171638u18f4a297gd82c79ff668adfce@mail.gmail.com> For those of you who prefer to stay on a release I've created a 7.2 branch with v13 ZFS. http://svn.freebsd.org/base/user/kmacy/releng_7_2_zfs/ -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From linimon at FreeBSD.org Mon May 18 02:33:17 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:33:31 2009 Subject: kern/127492: [zfs] System hang on ZFS input-output Message-ID: <200905180233.n4I2XGku043887@freefall.freebsd.org> Synopsis: [zfs] System hang on ZFS input-output Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:32:51 UTC 2009 Responsible-Changed-Why: probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=127492 From linimon at FreeBSD.org Mon May 18 02:35:43 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:35:54 2009 Subject: kern/129488: [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: kernel: bug: ecnt = 1, but m_len = 0 and m_next = 0 Message-ID: <200905180235.n4I2Zhqh044045@freefall.freebsd.org> Synopsis: [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: kernel: bug: ecnt = 1, but m_len = 0 and m_next = 0 Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:35:25 UTC 2009 Responsible-Changed-Why: This does not sound amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=129488 From linimon at FreeBSD.org Mon May 18 02:53:44 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:53:56 2009 Subject: kern/125644: [zfs] [panic] zfs unfixable fs errors caused panic when trying to destroy filesystem Message-ID: <200905180253.n4I2rhGN069881@freefall.freebsd.org> Old Synopsis: [zfs] zfs unfixable fs errors caused panic when trying to destroy filesystem New Synopsis: [zfs] [panic] zfs unfixable fs errors caused panic when trying to destroy filesystem Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:53:18 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125644 From linimon at FreeBSD.org Mon May 18 02:55:18 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:55:29 2009 Subject: bin/124424: [zfs] zfs(8): zfs list -r shows strange snapshots' size Message-ID: <200905180255.n4I2tH9b070018@freefall.freebsd.org> Synopsis: [zfs] zfs(8): zfs list -r shows strange snapshots' size Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:54:57 UTC 2009 Responsible-Changed-Why: Reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=124424 From linimon at FreeBSD.org Mon May 18 02:55:42 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:55:49 2009 Subject: kern/124360: [zfs] [patch] Add ZFS tunable Message-ID: <200905180255.n4I2tf4k070072@freefall.freebsd.org> Synopsis: [zfs] [patch] Add ZFS tunable Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:55:30 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124360 From linimon at FreeBSD.org Mon May 18 02:56:39 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:56:47 2009 Subject: kern/121770: [zfs] ZFS on i386, large file or heavy I/O leads to kernel panic or reboot Message-ID: <200905180256.n4I2ubGc070130@freefall.freebsd.org> Synopsis: [zfs] ZFS on i386, large file or heavy I/O leads to kernel panic or reboot State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Mon May 18 02:55:50 UTC 2009 State-Changed-Why: Note that feedback was received, and assign properly. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:55:50 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=121770 From linimon at FreeBSD.org Mon May 18 02:57:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:57:12 2009 Subject: bin/121366: [zfs] [patch] Automatic disk scrubbing from periodic(8) Message-ID: <200905180257.n4I2v0jK070181@freefall.freebsd.org> Synopsis: [zfs] [patch] Automatic disk scrubbing from periodic(8) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:56:46 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121366 From linimon at FreeBSD.org Mon May 18 02:57:36 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:57:47 2009 Subject: kern/119298: [xfs] [patch] 7-Stable/sys/modules/xfs fails to make from world Message-ID: <200905180257.n4I2vZov070234@freefall.freebsd.org> Synopsis: [xfs] [patch] 7-Stable/sys/modules/xfs fails to make from world Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:57:11 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=119298 From linimon at FreeBSD.org Mon May 18 02:58:09 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:58:21 2009 Subject: kern/102943: [xfs] kernel crash when unloading the xfs kernel module Message-ID: <200905180258.n4I2w7rK070284@freefall.freebsd.org> Synopsis: [xfs] kernel crash when unloading the xfs kernel module Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:57:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=102943 From linimon at FreeBSD.org Mon May 18 02:58:31 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:58:38 2009 Subject: bin/121779: [ufs] snapinfo(8) (and related tools?) only work for toplevel mount points Message-ID: <200905180258.n4I2wUhk070335@freefall.freebsd.org> Synopsis: [ufs] snapinfo(8) (and related tools?) only work for toplevel mount points Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:58:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121779 From linimon at FreeBSD.org Mon May 18 02:59:23 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 02:59:29 2009 Subject: kern/111782: [ufs] dump(8) fails horribly for large filesystems Message-ID: <200905180259.n4I2xMpm070397@freefall.freebsd.org> Old Synopsis: [ufs] /sbin/dump fails horribly for large filesystems New Synopsis: [ufs] dump(8) fails horribly for large filesystems Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:58:36 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=111782 From linimon at FreeBSD.org Mon May 18 03:02:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:02:27 2009 Subject: kern/106030: [ufs] [panic] panic in ufs from geom when a dead disk is invalidated Message-ID: <200905180302.n4I3235M080075@freefall.freebsd.org> Synopsis: [ufs] [panic] panic in ufs from geom when a dead disk is invalidated Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 02:59:31 UTC 2009 Responsible-Changed-Why: Analysis showed that this is either a UFS or buffer cache problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=106030 From linimon at FreeBSD.org Mon May 18 03:02:36 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:02:43 2009 Subject: kern/104406: [ufs] Processes get stuck in "ufs" state under persistent CPU load Message-ID: <200905180302.n4I32ZXQ083333@freefall.freebsd.org> Synopsis: [ufs] Processes get stuck in "ufs" state under persistent CPU load Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:02:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=104406 From linimon at FreeBSD.org Mon May 18 03:02:56 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:03:07 2009 Subject: kern/94849: [ufs] rename on UFS filesystem is not atomic Message-ID: <200905180302.n4I32tWJ083514@freefall.freebsd.org> Synopsis: [ufs] rename on UFS filesystem is not atomic Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:02:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94849 From linimon at FreeBSD.org Mon May 18 03:03:42 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:03:48 2009 Subject: kern/91568: [ufs] [panic] writing to UFS/softupdates DVD media in DVD-ROM drive Message-ID: <200905180303.n4I33fHQ083568@freefall.freebsd.org> Synopsis: [ufs] [panic] writing to UFS/softupdates DVD media in DVD-ROM drive State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Mon May 18 03:03:02 UTC 2009 State-Changed-Why: To submitter: is this still a problem on 7.2? Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:03:02 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=91568 From linimon at FreeBSD.org Mon May 18 03:04:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:04:41 2009 Subject: bin/73019: [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for inoinfo Message-ID: <200905180304.n4I34SkF083641@freefall.freebsd.org> Synopsis: [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for inoinfo Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:04:18 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=73019 From linimon at FreeBSD.org Mon May 18 03:04:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:05:05 2009 Subject: kern/26323: [ufs] [patch] Quota system creates zero-length files Message-ID: <200905180304.n4I34mQt083692@freefall.freebsd.org> Synopsis: [ufs] [patch] Quota system creates zero-length files Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:04:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=26323 From linimon at FreeBSD.org Mon May 18 03:05:34 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:05:45 2009 Subject: kern/127659: [tmpfs] tmpfs memory leak Message-ID: <200905180305.n4I35X1a083755@freefall.freebsd.org> Synopsis: [tmpfs] tmpfs memory leak Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:05:16 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127659 From linimon at FreeBSD.org Mon May 18 03:05:53 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:06:00 2009 Subject: kern/122038: [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc7d2fab0 0 Message-ID: <200905180305.n4I35q8p083816@freefall.freebsd.org> Synopsis: [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc7d2fab0 0 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:05:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122038 From linimon at FreeBSD.org Mon May 18 03:07:10 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:07:16 2009 Subject: kern/116583: [ffs] [hang] System freezes for short time when using mmap on full filesystem Message-ID: <200905180307.n4I378XP083930@freefall.freebsd.org> Old Synopsis: [ffs] System freezes for short time when using mmap on full filesystem New Synopsis: [ffs] [hang] System freezes for short time when using mmap on full filesystem Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:06:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=116583 From linimon at FreeBSD.org Mon May 18 03:07:30 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:07:42 2009 Subject: kern/116913: [ffs] [panic] ffs_blkfree: freeing free block Message-ID: <200905180307.n4I37Teh083982@freefall.freebsd.org> Synopsis: [ffs] [panic] ffs_blkfree: freeing free block Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:07:17 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=116913 From linimon at FreeBSD.org Mon May 18 03:09:24 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:09:29 2009 Subject: kern/122380: [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash mem) Message-ID: <200905180309.n4I39NXP084087@freefall.freebsd.org> Synopsis: [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash mem) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:09:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122380 From linimon at FreeBSD.org Mon May 18 03:09:41 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:09:48 2009 Subject: kern/133980: [panic] [ffs] panic: ffs_valloc: dup alloc Message-ID: <200905180309.n4I39eva084155@freefall.freebsd.org> Synopsis: [panic] [ffs] panic: ffs_valloc: dup alloc Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:09:32 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133980 From linimon at FreeBSD.org Mon May 18 03:10:00 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:10:11 2009 Subject: kern/120991: [panic] [fs] [snapshot] System crashes when manipulating fs snapshots Message-ID: <200905180309.n4I39vnL084205@freefall.freebsd.org> Synopsis: [panic] [fs] [snapshot] System crashes when manipulating fs snapshots Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:09:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=120991 From linimon at FreeBSD.org Mon May 18 03:10:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:10:27 2009 Subject: kern/95222: [iso9660] File sections on ISO9660 level 3 CDs ignored Message-ID: <200905180310.n4I3AKdo085490@freefall.freebsd.org> Synopsis: [iso9660] File sections on ISO9660 level 3 CDs ignored Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:10:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=95222 From linimon at FreeBSD.org Mon May 18 03:18:44 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 03:18:50 2009 Subject: kern/115645: [snapshots] [panic] lockmgr: thread 0xc4c00d80, not exclusive lock holder 0xc4dd7c00 unlocking Message-ID: <200905180318.n4I3IhUr098435@freefall.freebsd.org> Synopsis: [snapshots] [panic] lockmgr: thread 0xc4c00d80, not exclusive lock holder 0xc4dd7c00 unlocking Responsible-Changed-From-To: freebsd-s->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 03:18:34 UTC 2009 Responsible-Changed-Why: fix typo http://www.freebsd.org/cgi/query-pr.cgi?pr=115645 From sudakov at sibptus.tomsk.ru Mon May 18 04:09:14 2009 From: sudakov at sibptus.tomsk.ru (Victor Sudakov) Date: Mon May 18 04:09:21 2009 Subject: kern/131081: [zfs] User cannot delete a file when a ZFS dataset is full. In-Reply-To: <3c1674c90905171319t7443dbf9xfbc4affe8c86da60@mail.gmail.com> References: <200905170550.n4H5oTol011786@freefall.freebsd.org> <20090517115036.GA13638@admin.sibptus.tomsk.ru> <3c1674c90905171319t7443dbf9xfbc4affe8c86da60@mail.gmail.com> Message-ID: <20090518040911.GB34748@admin.sibptus.tomsk.ru> Kip Macy wrote: > FWIW, I am not able to reproduce this in a VM. I hope you were not working as root. I also cannot reproduce the problem when trying as root. The problem can be reproduced only under an ordinary user. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From kmacy at freebsd.org Mon May 18 04:13:12 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon May 18 04:13:18 2009 Subject: kern/131081: [zfs] User cannot delete a file when a ZFS dataset is full. In-Reply-To: <20090518040911.GB34748@admin.sibptus.tomsk.ru> References: <200905170550.n4H5oTol011786@freefall.freebsd.org> <20090517115036.GA13638@admin.sibptus.tomsk.ru> <3c1674c90905171319t7443dbf9xfbc4affe8c86da60@mail.gmail.com> <20090518040911.GB34748@admin.sibptus.tomsk.ru> Message-ID: <3c1674c90905172113o58202b98nc60fc4689e7a760@mail.gmail.com> No. What happens now is that the dd just becomes infinitely slow and never quite fills up the pool. -Kip On Sun, May 17, 2009 at 9:09 PM, Victor Sudakov wrote: > Kip Macy wrote: >> FWIW, I am not able to reproduce this in a VM. > > I hope you were not working as root. > I also cannot reproduce the problem when trying as root. The problem > can be reproduced only under an ordinary user. > > -- > Victor Sudakov, ?VAS4-RIPE, VAS47-RIPN > sip:sudakov@sibptus.tomsk.ru > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From linimon at FreeBSD.org Mon May 18 04:20:48 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:20:53 2009 Subject: bin/117315: [smbfs] mount_smbfs(8) and related options can't mount administration mounts (c$, d$, etc) on Windows PCs Message-ID: <200905180420.n4I4KldU082498@freefall.freebsd.org> Synopsis: [smbfs] mount_smbfs(8) and related options can't mount administration mounts (c$, d$, etc) on Windows PCs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:20:33 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=117315 From linimon at FreeBSD.org Mon May 18 04:21:02 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:21:15 2009 Subject: kern/113852: [smbfs] smbfs does not properly implement DFS referrals Message-ID: <200905180421.n4I4L24q083884@freefall.freebsd.org> Synopsis: [smbfs] smbfs does not properly implement DFS referrals Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:20:53 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=113852 From linimon at FreeBSD.org Mon May 18 04:21:23 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:21:30 2009 Subject: kern/101324: [smbfs] smbfs sometimes not case sensitive when it's supposed to be Message-ID: <200905180421.n4I4LLV8085997@freefall.freebsd.org> Synopsis: [smbfs] smbfs sometimes not case sensitive when it's supposed to be Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:21:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=101324 From linimon at FreeBSD.org Mon May 18 04:21:39 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:21:51 2009 Subject: kern/94733: [smbfs] smbfs may cause double unlock Message-ID: <200905180421.n4I4LcNE088461@freefall.freebsd.org> Synopsis: [smbfs] smbfs may cause double unlock Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:21:28 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94733 From linimon at FreeBSD.org Mon May 18 04:21:57 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:22:08 2009 Subject: kern/91134: [smbfs] [patch] Preserve access and modification time when cp to a smbfs destination path Message-ID: <200905180421.n4I4Lsf0090633@freefall.freebsd.org> Synopsis: [smbfs] [patch] Preserve access and modification time when cp to a smbfs destination path Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:21:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=91134 From linimon at FreeBSD.org Mon May 18 04:22:08 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:22:17 2009 Subject: kern/90815: [smbfs] [patch] SMBFS with character conversions sometimes hangs Message-ID: <200905180422.n4I4M79T092022@freefall.freebsd.org> Synopsis: [smbfs] [patch] SMBFS with character conversions sometimes hangs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:22:01 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=90815 From linimon at FreeBSD.org Mon May 18 04:22:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:22:41 2009 Subject: kern/88657: [smbfs] windows client hang when browsing a samba share which is on a nfs fs [regression] (workaround) Message-ID: <200905180422.n4I4MXJN092089@freefall.freebsd.org> Synopsis: [smbfs] windows client hang when browsing a samba share which is on a nfs fs [regression] (workaround) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:22:22 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=88657 From linimon at FreeBSD.org Mon May 18 04:22:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:22:56 2009 Subject: kern/88266: [smbfs] smbfs does not implement UIO_NOCOPY and sendfile(2) on smbfs mounted files fails Message-ID: <200905180422.n4I4MmL2092138@freefall.freebsd.org> Synopsis: [smbfs] smbfs does not implement UIO_NOCOPY and sendfile(2) on smbfs mounted files fails Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:22:40 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=88266 From linimon at FreeBSD.org Mon May 18 04:23:05 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:23:16 2009 Subject: kern/87859: [smbfs] System reboot while umount smbfs. Message-ID: <200905180423.n4I4N3pP092188@freefall.freebsd.org> Synopsis: [smbfs] System reboot while umount smbfs. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:22:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=87859 From linimon at FreeBSD.org Mon May 18 04:23:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:23:28 2009 Subject: kern/85326: [smbfs] [panic] saving a file via samba to an overquota account crashes system Message-ID: <200905180423.n4I4NJrh092237@freefall.freebsd.org> Synopsis: [smbfs] [panic] saving a file via samba to an overquota account crashes system Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:23:11 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=85326 From linimon at FreeBSD.org Mon May 18 04:23:34 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:23:41 2009 Subject: kern/80088: [smbfs] Incorrect file time setting on NTFS mounted via mount_smbfs Message-ID: <200905180423.n4I4NWkA092289@freefall.freebsd.org> Synopsis: [smbfs] Incorrect file time setting on NTFS mounted via mount_smbfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:23:24 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=80088 From linimon at FreeBSD.org Mon May 18 04:23:48 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:23:55 2009 Subject: kern/65901: [smbfs] [patch] smbfs fails fsx write/truncate-down/truncate-up/reread old write +FIX Message-ID: <200905180423.n4I4NkYv092338@freefall.freebsd.org> Synopsis: [smbfs] [patch] smbfs fails fsx write/truncate-down/truncate-up/reread old write +FIX Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:23:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=65901 From linimon at FreeBSD.org Mon May 18 04:23:59 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:24:06 2009 Subject: kern/61503: [smbfs] mount_smbfs does not work as non-root Message-ID: <200905180423.n4I4Nv7M092398@freefall.freebsd.org> Synopsis: [smbfs] mount_smbfs does not work as non-root Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:23:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=61503 From linimon at FreeBSD.org Mon May 18 04:24:13 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:24:25 2009 Subject: kern/55617: [smbfs] Accessing an nsmb-mounted drive via a smb export causes lockup Message-ID: <200905180424.n4I4OCuT092447@freefall.freebsd.org> Synopsis: [smbfs] Accessing an nsmb-mounted drive via a smb export causes lockup Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:24:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=55617 From linimon at FreeBSD.org Mon May 18 04:24:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:24:41 2009 Subject: kern/36566: [smbfs] System reboot with dead smb mount and umount Message-ID: <200905180424.n4I4OSZ9092499@freefall.freebsd.org> Synopsis: [smbfs] System reboot with dead smb mount and umount Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:24:19 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=36566 From linimon at FreeBSD.org Mon May 18 04:25:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:25:12 2009 Subject: bin/121898: [nullfs] pwd(1)/getcwd(2) fails with Permission denied Message-ID: <200905180424.n4I4Ox8B092570@freefall.freebsd.org> Synopsis: [nullfs] pwd(1)/getcwd(2) fails with Permission denied Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:24:49 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121898 From linimon at FreeBSD.org Mon May 18 04:25:14 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:25:21 2009 Subject: kern/104938: [nullfs] [request] readlink("/proc/curproc/file") does not work over nullfs Message-ID: <200905180425.n4I4PDHj092632@freefall.freebsd.org> Synopsis: [nullfs] [request] readlink("/proc/curproc/file") does not work over nullfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:25:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=104938 From linimon at FreeBSD.org Mon May 18 04:25:47 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:25:53 2009 Subject: kern/94269: [nullfs] procfs shows wrong data if executable is running from nullfs Message-ID: <200905180425.n4I4Pfst092683@freefall.freebsd.org> Synopsis: [nullfs] procfs shows wrong data if executable is running from nullfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:25:33 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94269 From linimon at FreeBSD.org Mon May 18 04:26:02 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:26:15 2009 Subject: kern/51583: [nullfs] [patch] allow to work with devices and sockets over nullfs [STABLE, 5.0-CURRENT] Message-ID: <200905180426.n4I4Q1S4092732@freefall.freebsd.org> Synopsis: [nullfs] [patch] allow to work with devices and sockets over nullfs [STABLE, 5.0-CURRENT] Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:25:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=51583 From linimon at FreeBSD.org Mon May 18 04:26:16 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:26:31 2009 Subject: kern/120483: [ntfs] [patch] NTFS filesystem locking changes Message-ID: <200905180426.n4I4QFwQ092783@freefall.freebsd.org> Synopsis: [ntfs] [patch] NTFS filesystem locking changes Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:26:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=120483 From linimon at FreeBSD.org Mon May 18 04:26:30 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:26:37 2009 Subject: kern/120482: [ntfs] [patch] Sync style changes between NetBSD and FreeBSD ntfs filesystem Message-ID: <200905180426.n4I4QT1g092835@freefall.freebsd.org> Synopsis: [ntfs] [patch] Sync style changes between NetBSD and FreeBSD ntfs filesystem Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:26:21 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=120482 From linimon at FreeBSD.org Mon May 18 04:26:42 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:26:54 2009 Subject: kern/118107: [ntfs] [panic] Kernel panic when accessing a file at NTFS file system [regression] Message-ID: <200905180426.n4I4Qe5b092884@freefall.freebsd.org> Synopsis: [ntfs] [panic] Kernel panic when accessing a file at NTFS file system [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:26:34 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=118107 From linimon at FreeBSD.org Mon May 18 04:26:54 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:27:00 2009 Subject: kern/117314: [ntfs] Long-filename only NTFS fs'es cause kernel panics on read Message-ID: <200905180426.n4I4QrGj092933@freefall.freebsd.org> Synopsis: [ntfs] Long-filename only NTFS fs'es cause kernel panics on read Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:26:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=117314 From linimon at FreeBSD.org Mon May 18 04:27:07 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:27:16 2009 Subject: kern/103035: [ntfs] Directories in NTFS mounted disc images appear as empty files in Samba export Message-ID: <200905180427.n4I4R6Zc092985@freefall.freebsd.org> Synopsis: [ntfs] Directories in NTFS mounted disc images appear as empty files in Samba export Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:26:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=103035 From linimon at FreeBSD.org Mon May 18 04:27:20 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:27:31 2009 Subject: kern/99290: [ntfs] mount_ntfs ignorant of cluster sizes Message-ID: <200905180427.n4I4RJlO093034@freefall.freebsd.org> Synopsis: [ntfs] mount_ntfs ignorant of cluster sizes Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:27:13 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=99290 From linimon at FreeBSD.org Mon May 18 04:27:30 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:27:42 2009 Subject: kern/97377: [ntfs] [patch] syntax cleanup for ntfs_ihash.c Message-ID: <200905180427.n4I4RT4w093085@freefall.freebsd.org> Synopsis: [ntfs] [patch] syntax cleanup for ntfs_ihash.c Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:27:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=97377 From linimon at FreeBSD.org Mon May 18 04:27:47 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:27:58 2009 Subject: kern/73484: [ntfs] Kernel panic when doing `ls` from the client side (running Solaris 8) on an NFS exported ntfs file system in 4.10 Message-ID: <200905180427.n4I4Rj3Q093134@freefall.freebsd.org> Synopsis: [ntfs] Kernel panic when doing `ls` from the client side (running Solaris 8) on an NFS exported ntfs file system in 4.10 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:27:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=73484 From linimon at FreeBSD.org Mon May 18 04:28:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:28:12 2009 Subject: kern/71774: [ntfs] NTFS cannot "see" files on a WinXP filesystem Message-ID: <200905180427.n4I4Rxow093183@freefall.freebsd.org> Synopsis: [ntfs] NTFS cannot "see" files on a WinXP filesystem Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:27:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=71774 From linimon at FreeBSD.org Mon May 18 04:28:18 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:28:24 2009 Subject: kern/132237: [msdosfs] msdosfs has problems to read MSDOS Floppy Message-ID: <200905180428.n4I4SGhZ093239@freefall.freebsd.org> Synopsis: [msdosfs] msdosfs has problems to read MSDOS Floppy Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:28:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132237 From linimon at FreeBSD.org Mon May 18 04:28:31 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:28:43 2009 Subject: kern/123939: [msdosfs] corrupts new files Message-ID: <200905180428.n4I4SUna093290@freefall.freebsd.org> Synopsis: [msdosfs] corrupts new files Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:28:24 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123939 From linimon at FreeBSD.org Mon May 18 04:29:09 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:29:15 2009 Subject: bin/116980: [msdosfs] [patch] mount_msdosfs(8) resets some flags for 'update' mount Message-ID: <200905180429.n4I4T8cN093371@freefall.freebsd.org> Synopsis: [msdosfs] [patch] mount_msdosfs(8) resets some flags for 'update' mount Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:28:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=116980 From linimon at FreeBSD.org Mon May 18 04:29:24 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:29:36 2009 Subject: kern/116608: [panic] [patch] [msdosfs] msdosfs fails to check mount options Message-ID: <200905180429.n4I4TNrc093421@freefall.freebsd.org> Synopsis: [panic] [patch] [msdosfs] msdosfs fails to check mount options Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:29:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=116608 From linimon at FreeBSD.org Mon May 18 04:30:13 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:30:25 2009 Subject: kern/111843: [msdosfs] Long Names of files are incorrectly created on msdosfs Message-ID: <200905180430.n4I4UCaa094907@freefall.freebsd.org> Synopsis: [msdosfs] Long Names of files are incorrectly created on msdosfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:30:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=111843 From linimon at FreeBSD.org Mon May 18 04:30:28 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:30:35 2009 Subject: kern/109024: [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not permitted Message-ID: <200905180430.n4I4URA2096706@freefall.freebsd.org> Synopsis: [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not permitted Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:30:20 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=109024 From linimon at FreeBSD.org Mon May 18 04:30:42 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:30:54 2009 Subject: kern/109010: [msdosfs] can't mv directory within fat32 file system Message-ID: <200905180430.n4I4Ue88097999@freefall.freebsd.org> Synopsis: [msdosfs] can't mv directory within fat32 file system Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:30:34 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=109010 From linimon at FreeBSD.org Mon May 18 04:30:57 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:31:04 2009 Subject: kern/86587: [msdosfs] rm -r /PATH fails with lots of small files Message-ID: <200905180430.n4I4Uu68098269@freefall.freebsd.org> Synopsis: [msdosfs] rm -r /PATH fails with lots of small files Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:30:50 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=86587 From linimon at FreeBSD.org Mon May 18 04:31:14 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:31:26 2009 Subject: kern/118713: [minidump] [patch] Display media size required for a kernel dump Message-ID: <200905180431.n4I4VAQV099545@freefall.freebsd.org> Synopsis: [minidump] [patch] Display media size required for a kernel dump Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:31:03 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=118713 From linimon at FreeBSD.org Mon May 18 04:31:39 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:31:45 2009 Subject: kern/122047: [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / UF_APPEND flag on EXT2FS (maybe others) Message-ID: <200905180431.n4I4Vb8P002026@freefall.freebsd.org> Synopsis: [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / UF_APPEND flag on EXT2FS (maybe others) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:31:25 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122047 From linimon at FreeBSD.org Mon May 18 04:31:53 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:32:05 2009 Subject: kern/119529: [ext2fs] [patch] Freezes when compiling code on mounter ext2fs partitions Message-ID: <200905180431.n4I4Vq2R003856@freefall.freebsd.org> Synopsis: [ext2fs] [patch] Freezes when compiling code on mounter ext2fs partitions Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:31:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=119529 From linimon at FreeBSD.org Mon May 18 04:32:08 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:32:20 2009 Subject: kern/105093: [ext2fs] [patch] ext2fs on read-only media cannot be mounted Message-ID: <200905180432.n4I4W6nh005587@freefall.freebsd.org> Synopsis: [ext2fs] [patch] ext2fs on read-only media cannot be mounted Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:32:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=105093 From linimon at FreeBSD.org Mon May 18 04:32:36 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:32:48 2009 Subject: kern/104133: [ext2fs] EXT2FS module corrupts EXT2/3 filesystems Message-ID: <200905180432.n4I4WYG5007966@freefall.freebsd.org> Synopsis: [ext2fs] EXT2FS module corrupts EXT2/3 filesystems Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:32:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=104133 From linimon at FreeBSD.org Mon May 18 04:32:54 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:33:16 2009 Subject: kern/77826: [ext2fs] ext2fs usb filesystem will not mount RW Message-ID: <200905180432.n4I4Wpmk008207@freefall.freebsd.org> Synopsis: [ext2fs] ext2fs usb filesystem will not mount RW Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:32:40 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=77826 From linimon at FreeBSD.org Mon May 18 04:33:07 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:33:16 2009 Subject: kern/118912: [2tb] disk sizing/geometry problem with large array Message-ID: <200905180433.n4I4X40a008513@freefall.freebsd.org> Synopsis: [2tb] disk sizing/geometry problem with large array Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:32:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=118912 From linimon at FreeBSD.org Mon May 18 04:33:28 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:33:40 2009 Subject: bin/111146: [2tb] fsck(8) fails on 6T filesystem Message-ID: <200905180433.n4I4XRcx009150@freefall.freebsd.org> Synopsis: [2tb] fsck(8) fails on 6T filesystem Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:33:11 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=111146 From linimon at FreeBSD.org Mon May 18 04:33:43 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:33:54 2009 Subject: bin/107829: [2TB] fdisk(8): invalid boundary checking in fdisk / wraps value of > 2TB filesystem. Message-ID: <200905180433.n4I4Xfl6009199@freefall.freebsd.org> Synopsis: [2TB] fdisk(8): invalid boundary checking in fdisk / wraps value of > 2TB filesystem. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:33:35 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=107829 From linimon at FreeBSD.org Mon May 18 04:33:58 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:34:10 2009 Subject: kern/84589: [2TB] 5.4-STABLE unresponsive during background fsck 2TB partition Message-ID: <200905180433.n4I4XvAF009248@freefall.freebsd.org> Synopsis: [2TB] 5.4-STABLE unresponsive during background fsck 2TB partition Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:33:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=84589 From linimon at FreeBSD.org Mon May 18 04:34:16 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 04:34:27 2009 Subject: kern/18874: [2TB] 32bit NFS servers export wrong negative values to 64bit clients Message-ID: <200905180434.n4I4YFe6009298@freefall.freebsd.org> Synopsis: [2TB] 32bit NFS servers export wrong negative values to 64bit clients Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 04:34:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=18874 From brde at optusnet.com.au Mon May 18 05:20:05 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Mon May 18 05:20:12 2009 Subject: kern/133980: [panic] [ffs] panic: ffs_valloc: dup alloc In-Reply-To: <200905180309.n4I39eva084155@freefall.freebsd.org> References: <200905180309.n4I39eva084155@freefall.freebsd.org> Message-ID: <20090518151631.B18475@delplex.bde.org> On Mon, 18 May 2009 linimon@FreeBSD.org wrote: > Synopsis: [panic] [ffs] panic: ffs_valloc: dup alloc > ... > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133980 There seem to be several PRs about this bug. This one seems to have a correct diagnosis (just another missing range check). My previous followup to it (to the submitter and freebsd-bugs) didn't seem to go anywhere :-(. Is it necessary to put freebsd-gnats-submit in the headers again? Bruce From maxim at macomnet.ru Mon May 18 05:32:11 2009 From: maxim at macomnet.ru (Maxim Konovalov) Date: Mon May 18 05:32:22 2009 Subject: kern/133980: [panic] [ffs] panic: ffs_valloc: dup alloc In-Reply-To: <20090518151631.B18475@delplex.bde.org> References: <200905180309.n4I39eva084155@freefall.freebsd.org> <20090518151631.B18475@delplex.bde.org> Message-ID: <20090518093117.S7472@mp2.macomnet.net> [...] > anywhere :-(. Is it necessary to put freebsd-gnats-submit in the > headers again? > Just bug-followup@ -- Maxim Konovalov From ulf.lilleengen at gmail.com Mon May 18 05:50:45 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Mon May 18 05:50:51 2009 Subject: MFC of svn commit: r187395 - head/sys/gnu/fs/ext2fs Message-ID: <20090518055040.GA3501@carrot.geeknest.org> Hi, I was wondering if there is anything against MFCing this change, as it has not yet happened? I saw there was some discussion around the patch, but it fixes at least these PRs 77826, 81568 and 105093 according to Aditya Sarawgi. I saw the problems outlined in http://lists.freebsd.org/pipermail/svn-src-head/2009-January/002937.html So I haven't gone ahead with it. Log: - Obtain inode sizes and location of the first inode based on the contents of superblock rather than using hardcoded values. This fixes ext2fs on filesystems with inode sized other than 128. Submitted by: Alex Lyashkov (based on) MFC after: 2 weeks -- Ulf Lilleengen From lulf at FreeBSD.org Mon May 18 06:34:44 2009 From: lulf at FreeBSD.org (lulf@FreeBSD.org) Date: Mon May 18 06:35:26 2009 Subject: kern/124360: [zfs] [patch] Add ZFS tunable Message-ID: <200905180634.n4I6YhfL076731@freefall.freebsd.org> Synopsis: [zfs] [patch] Add ZFS tunable State-Changed-From-To: open->closed State-Changed-By: lulf State-Changed-When: Mon May 18 06:33:44 UTC 2009 State-Changed-Why: - A patch similar to this is already in HEAD, and will probably be MFCed in the case of a ZFS MFC. http://www.freebsd.org/cgi/query-pr.cgi?pr=124360 From brde at optusnet.com.au Mon May 18 07:28:22 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Mon May 18 07:28:29 2009 Subject: MFC of svn commit: r187395 - head/sys/gnu/fs/ext2fs In-Reply-To: <20090518055040.GA3501@carrot.geeknest.org> References: <20090518055040.GA3501@carrot.geeknest.org> Message-ID: <20090518160049.E2212@besplex.bde.org> On Mon, 18 May 2009, Ulf Lilleengen wrote: > I was wondering if there is anything against MFCing this change, as it has > not yet happened? Yes, there is. > I saw there was some discussion around the patch, but it > fixes at least these PRs 77826, 81568 and 105093 according to Aditya Sarawgi. > I saw the problems outlined in > http://lists.freebsd.org/pipermail/svn-src-head/2009-January/002937.html > > So I haven't gone ahead with it. > > Log: > - Obtain inode sizes and location of the first inode based on the contents > of superblock rather than using hardcoded values. This fixes ext2fs on > filesystems with inode sized other than 128. > > Submitted by: Alex Lyashkov (based on) > MFC after: 2 weeks The submitted patch was committed verbatim but was not suitable for committing verbatim. It turns the nearby comments and ifdef tangle in ext2_fs.h into nonsense, and is wrong (unlike for ifdefed-out code in the ifdef tangle) for the case of old file systems that don't have the inode size or the first inode number in the superblock. >From ext2_fs.h: % /* % * Note: under FreeBSD, the "user" versions of the following macros are % * used (and must be used) in most cases, because ((s)->u.ext2_sb.s_es is % * not accessible. This depends on __KERNEL__ not being defined for % * kernel builds under FreeBSD. % */ Most of this mail is an expansion of this comment. % ... % #ifdef notyet % #ifdef __KERNEL__ % #define EXT2_ADDR_PER_BLOCK_BITS(s) ((s)->u.ext2_sb.s_addr_per_block_bits) % #define EXT2_INODE_SIZE(s) ((s)->u.ext2_sb.s_inode_size) % #define EXT2_FIRST_INO(s) ((s)->u.ext2_sb.s_first_ino) % #else % #define EXT2_INODE_SIZE(s) (((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \ % EXT2_GOOD_OLD_INODE_SIZE : \ % (s)->s_inode_size) % #define EXT2_FIRST_INO(s) (((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \ % EXT2_GOOD_OLD_FIRST_INO : \ % (s)->s_first_ino) % #endif % #else /* !notyet */ Except for the "notyet" ifdef, this is identical with at least old versions of ext2_fs.h (same name) in Linux. The !__KERNEL__ case needs to be more complicated so that it can work without extra initialization in userland. The kernel case can be simpler because the kernel can do extra initialization consisting of initializing the "new" superblock fields in at least the in-core copy of the superblock. Native Linux ext2fs does this, but FreeBSD ext2fs doesn't. Thus FreeBSD ext2fs needs something like the userland code so as to support all values of s_rev_level. For other macros, it gets this by depending on Linux's spelling of *KERNEL* being different from FreeBSD's (__KERNEL__ in Linux and _KERNEL in FreeBSD) -- see the first comment. This doesn't quite work here, mainly because the FreeBSD macros didn't take an s parameter. So FreeBSD uses the notyet hack followed by further uglyness. The "fix" made things uglier than before by suppling an s parameter with different semantics so that the Linux macros still don't work. It still needs a third set of macros, and it gets these wrong by not making them either semantically or API-compatible with the above correct ones (it essentially duplicates the __KERNEL__ version of the ones above with a different API, but this gives wrong semantics because FreeBSD doesn't have the extra initialization). % #define EXT2_INODES_PER_BLOCK(s) ((s)->s_inodes_per_block) This is the old hack for accesses to the s_inodes_per_block field. It works even for old file systems because this field isn't in the on-disk superblock. This field is in the in-core superblock and is always initialized from other data in both Linux and FreeBSD. Linux doesn't even have a macro for it and neither should FreeBSD. Note that this macro has a different form than the ones above related to this -- in the above, s is has to be followed through u.ext2_sb to get to the on-disk superblock, while this macro gets data directly from the in-core superblock. % /* Should be sizeof(struct ext2_inode): */ This comment is now nonsense. One thing that the following values should NOT be is a fixed value given by either a literal or sizeof(). % #define EXT2_INODE_SIZE(s) ((s)->s_inode_size) % #define EXT2_FIRST_INO(s) ((s)->s_first_inode) % #endif /* notyet */ The values here used to be given by literals with no s parameter: $ #define EXT2_INODE_SIZE 128 $ #define EXT2_FIRST_INO 11 These were wrong for newer file systems with different values in the superblock. The new definitions are wrong for older file systems with no values in the superblock. Other parts of the commit consisted of adding the s parameter. These are not so bad, except they use an inconsistent API -- elsewhere, the s parameter is consistently a pointer to the in-core superblock, except in FreeBSD's version of these macros where it is a pointer to the on-disk superblock. This API difference is confusing and is the main thing that prevents direct use of the Linux macros (I think there are also some spelling differences like s_es instead of u.ext2_sb). Bruce From bugmaster at FreeBSD.org Mon May 18 11:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 18 11:08:06 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200905181106.n4IB6ple075637@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/134496 fs [zfs] [panic] ZFS pool export occasionally causes a ke o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/133134 fs [zfs] Missing ZFS zpool labels o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132551 fs [zfs] ZFS locks up on extattr_list_link syscall o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132337 fs [zfs] [panic] kernel panic in zfs_fuid_create_cred o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/131084 fs [xfs] xfs destroys itself after copying data o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs o kern/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127492 fs [zfs] System hang on ZFS input-output o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125644 fs [zfs] [panic] zfs unfixable fs errors caused panic whe f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs] [panic] changing into .zfs dir from nfs client c f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122047 fs [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / o kern/122038 fs [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o kern/121770 fs [zfs] ZFS on i386, large file or heavy I/O leads to ke o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119529 fs [ext2fs] [patch] Freezes when compiling code on mounte o kern/119298 fs [xfs] [patch] 7-Stable/sys/modules/xfs fails to make f o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/105093 fs [ext2fs] [patch] ext2fs on read-only media cannot be m s kern/104938 fs [nullfs] [request] readlink("/proc/curproc/file") does o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist f kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/102943 fs [xfs] kernel crash when unloading the xfs kernel modul o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock s kern/94269 fs [nullfs] procfs shows wrong data if executable is runn o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/77826 fs [ext2fs] ext2fs usb filesystem will not mount RW o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/26323 fs [ufs] [patch] Quota system creates zero-length files o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 131 problems total. From kmacy at freebsd.org Mon May 18 13:07:35 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon May 18 13:07:42 2009 Subject: RELENG 7.2 with v13 ZFS branch Message-ID: <3c1674c90905171638u18f4a297gd82c79ff668adfce@mail.gmail.com> For those of you who prefer to stay on a release I've created a 7.2 branch with v13 ZFS. http://svn.freebsd.org/base/user/kmacy/releng_7_2_zfs/ -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From antonakis at gmail.com Mon May 18 14:06:28 2009 From: antonakis at gmail.com (Antonios Anastasiadis) Date: Mon May 18 14:06:36 2009 Subject: RFT: ZFS MFC In-Reply-To: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> References: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> Message-ID: <655a934b0905180634s315888c3r3a91e218c5f1253e@mail.gmail.com> 2009/5/16 Kip Macy : > I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. > > http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ > > The standard disclaimers apply. This has only been lightly tested in a > VM. Please do not use it with data you care about at this time. > > > Thanks, > Kip Thanks! I've upgraded a pool from v6 to v13 and I'm currently battering a postgresql database on it, while using the system for other work. Everything seems to be stable. I just got some forced unmount warnings during shutdown, but I guess that's normal, isnt'it? Antonios From kib at FreeBSD.org Mon May 18 14:19:30 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Mon May 18 14:19:37 2009 Subject: kern/104938: [nullfs] [request] readlink("/proc/curproc/file") does not work over nullfs Message-ID: <200905181419.n4IEJTTU037638@freefall.freebsd.org> Synopsis: [nullfs] [request] readlink("/proc/curproc/file") does not work over nullfs State-Changed-From-To: suspended->open State-Changed-By: kib State-Changed-When: Mon May 18 14:17:22 UTC 2009 State-Changed-Why: Take it. I have prototyped VOP_VPTOCNP bypass for nullfs on CURRENT. Responsible-Changed-From-To: freebsd-fs->kib Responsible-Changed-By: kib Responsible-Changed-When: Mon May 18 14:17:22 UTC 2009 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=104938 From kib at FreeBSD.org Mon May 18 14:21:33 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Mon May 18 14:21:40 2009 Subject: kern/94269: [nullfs] procfs shows wrong data if executable is running from nullfs Message-ID: <200905181421.n4IELWi9045993@freefall.freebsd.org> Synopsis: [nullfs] procfs shows wrong data if executable is running from nullfs State-Changed-From-To: suspended->open State-Changed-By: kib State-Changed-When: Mon May 18 14:20:53 UTC 2009 State-Changed-Why: I have prototyped VOP_VPTOCNP bypass for CURRENT. Responsible-Changed-From-To: freebsd-fs->kib Responsible-Changed-By: kib Responsible-Changed-When: Mon May 18 14:20:53 UTC 2009 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=94269 From kan at FreeBSD.org Mon May 18 16:36:05 2009 From: kan at FreeBSD.org (kan@FreeBSD.org) Date: Mon May 18 16:36:11 2009 Subject: kern/119298: [xfs] [patch] 7-Stable/sys/modules/xfs fails to make from world Message-ID: <200905181636.n4IGa4Uj029073@freefall.freebsd.org> Synopsis: [xfs] [patch] 7-Stable/sys/modules/xfs fails to make from world Responsible-Changed-From-To: freebsd-fs->kan Responsible-Changed-By: kan Responsible-Changed-When: Mon May 18 16:35:36 UTC 2009 Responsible-Changed-Why: I'll look at this. http://www.freebsd.org/cgi/query-pr.cgi?pr=119298 From kan at FreeBSD.org Mon May 18 16:37:04 2009 From: kan at FreeBSD.org (kan@FreeBSD.org) Date: Mon May 18 16:37:11 2009 Subject: kern/102943: [xfs] kernel crash when unloading the xfs kernel module Message-ID: <200905181637.n4IGb3oq029133@freefall.freebsd.org> Synopsis: [xfs] kernel crash when unloading the xfs kernel module Responsible-Changed-From-To: freebsd-fs->kan Responsible-Changed-By: kan Responsible-Changed-When: Mon May 18 16:36:24 UTC 2009 Responsible-Changed-Why: Likely OBE, but I will vberify before closing. http://www.freebsd.org/cgi/query-pr.cgi?pr=102943 From kib at FreeBSD.org Mon May 18 16:40:58 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Mon May 18 16:41:44 2009 Subject: kern/26323: [ufs] [patch] Quota system creates zero-length files Message-ID: <200905181640.n4IGevag033578@freefall.freebsd.org> Synopsis: [ufs] [patch] Quota system creates zero-length files State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Mon May 18 16:37:26 UTC 2009 State-Changed-Why: Described behaviour is a consequence of the design of the quita system and (probably) misbehaving applications. Proposed patch tries to implement the "disallow new inode allocations when too low number of blocks in user quota left", that is just silly, IMHO. http://www.freebsd.org/cgi/query-pr.cgi?pr=26323 From kib at FreeBSD.org Mon May 18 16:44:54 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Mon May 18 16:45:00 2009 Subject: kern/119529: [ext2fs] [patch] Freezes when compiling code on mounter ext2fs partitions Message-ID: <200905181644.n4IGirp3042083@freefall.freebsd.org> Synopsis: [ext2fs] [patch] Freezes when compiling code on mounter ext2fs partitions State-Changed-From-To: feedback->closed State-Changed-By: kib State-Changed-When: Mon May 18 16:44:21 UTC 2009 State-Changed-Why: The patch in the trail log was committed. I believe it should fix the issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=119529 From kan at FreeBSD.org Mon May 18 16:56:57 2009 From: kan at FreeBSD.org (kan@FreeBSD.org) Date: Mon May 18 16:57:03 2009 Subject: kern/131084: [xfs] xfs destroys itself after copying data Message-ID: <200905181656.n4IGuuW2055147@freefall.freebsd.org> Synopsis: [xfs] xfs destroys itself after copying data State-Changed-From-To: open->closed State-Changed-By: kan State-Changed-When: Mon May 18 16:54:59 UTC 2009 State-Changed-Why: Writes are not supported at this time. Responsible-Changed-From-To: freebsd-fs->kan Responsible-Changed-By: kan Responsible-Changed-When: Mon May 18 16:54:59 UTC 2009 Responsible-Changed-Why: Grab to close. http://www.freebsd.org/cgi/query-pr.cgi?pr=131084 From keramida at freebsd.org Tue May 19 03:30:04 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Tue May 19 03:30:11 2009 Subject: bin/121366: [zfs] [patch] Automatic disk scrubbing from periodic(8) Message-ID: <200905190330.n4J3U3V6017615@freefall.freebsd.org> The following reply was made to PR bin/121366; it has been noted by GNATS. From: Giorgos Keramidas To: bug-followup@freebsd.org Cc: Subject: Re: bin/121366: [zfs] [patch] Automatic disk scrubbing from periodic(8) Date: Tue, 19 May 2009 06:29:07 +0300 On Mon, 18 May 2009 02:57:00 GMT, linimon@FreeBSD.org wrote: > Synopsis: [zfs] [patch] Automatic disk scrubbing from periodic(8) > > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon May 18 02:56:46 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121366 A variation of the same idea that should auto-kick scrubbing if the 'age' of the last scrub exceeds a configurable threshold would be nice too. The _untested_ patch below is a start at implementing that: http://people.freebsd.org/~keramida/diff/zfs-scrub.periodic.diff I'll give this a few test runs and if it looks useful resubmit with the matching manpage updates too. %%% diff -r cc894c49974d etc/defaults/periodic.conf --- a/etc/defaults/periodic.conf Mon May 18 10:31:18 2009 +0300 +++ b/etc/defaults/periodic.conf Tue May 19 06:27:09 2009 +0300 @@ -226,6 +226,11 @@ pkg_version=pkg_version # Use this program pkg_version_index=/usr/ports/INDEX-8 # Use this index file +# 500.zfs-scrub +weekly_status_zfs_scrub_enable="NO" # Scrub zfs pools +weekly_status_zfs_scrub_auto="NO" # Auto-scrub old pools +weekly_status_zfs_scrub_max_age="1728000" # Scrub age in seconds + # 999.local weekly_local="/etc/weekly.local" # Local scripts diff -r cc894c49974d etc/periodic/weekly/500.zfs-scrub --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/etc/periodic/weekly/500.zfs-scrub Tue May 19 06:27:09 2009 +0300 @@ -0,0 +1,131 @@ +#!/bin/sh +# +# $FreeBSD$ +# +# Report the last time a zfs pool was scrubbed and if auto-scrubbing is +# enabled, kick off a 'zfs scrub' run for pools that were checked too +# far in the past. +# + +# If there is a global system configuration file, suck it in. +if [ -r /etc/defaults/periodic.conf ] +then + . /etc/defaults/periodic.conf + source_periodic_confs +fi + +# scrubdate +# Find the time since the Epoch of the last pool scrub for all +# active zfs pools (0=never, -1=running now). +scrubdate() +{ + for pool in $(/sbin/zpool list -H -o name) ; do + /sbin/zpool status "${pool}" | + while read line ; do + case "${line}" in + scrub:\ scrub\ completed*|scrub:\ resilver\ completed*) + # Extract date from zpool output and convert to epoch. + date=$(echo $line | sed 's/^scrub: .* on //') + date=$(date -jn -f '%+' "$date" '+%s') + ;; + + scrub:\ scrub\ in\ progress*|scrub:\ resilver\ in\ progress*) + # Scrub or resilver is running now. + date='-1' + ;; + + scrub:\ none\ requested) + # Pool has never been scrubed or resilvered. + date='0' + ;; + esac + echo "${date} ${pool}" + done + done +} + +# scrubpool POOL TIME +# Kick off a scrub of zfs pool `POOL' if the `TIME' of its last +# scrub is too old and auto-scrubbing is enabled. +scrubpool() +{ + local _pool="$1" + local _time="$2" + + case "${weekly_status_zfs_scrub_auto}" in + [Yy][Ee][Ss]) + case "${weekly_status_zfs_scrub_max_age}" in + [0-9]*) + ;; + *) + echo '$weekly_status_zfs_scrub_max_age is not set' \ + 'properly - see periodic.conf(5)' + ;; + esac + now=$(date '+%s') + age=$(( "${now}" - "${_time}" )) + if [ -z "${age}" ]; then + echo "Cannot find scrub age for pool ${_pool} -" \ + "forcing a scrub run" + zfs scrub "${_pool}" + return $? + fi + if [ "${age}" -gt "${weekly_status_zfs_scrub_max_age}" ]; then + echo "Last scrub for pool ${_pool} was ${age} seconds ago." + echo "Starting automatic scrub run." + zfs scrub "${_pool}" + return $? + fi + ;; + + [Nn][Oo]) + return 0 + ;; + + *) + echo '$weekly_zfs_scrub_auto is not set properly - ' \ + 'see periodic.conf(5)' + return 1 + ;; + esac +} + +rc=0 +case "$weekly_zfs_scrub_enable" in + [Yy][Ee][Ss]) + havepools=1 + scrubdate | sort -n | \ + while read date pool ; do + havepools=1 + echo "" + case ${date} in + -1) + echo "Scrub or resilver is running for pool $pool:" + /sbin/zpool status ${pool} + status=$? + [ ${status} -ne 0 ] && rc=${status} + ;; + + 0) + scrubpool ${pool} ${time} + status=$? + [ ${status} -ne 0 ] && rc=${status} + ;; + esac + done + if [ ${havepools} -eq 0 ]; then + echo '$weekly_zfs_scrub_enable is set' \ + 'but no zfs pools have been created' + rc=2 + fi + ;; + + [Nn][Oo]) + ;; + + *) + echo '$weekly_zfs_scrub_enable is not set properly - ' \ + 'see periodic.conf(5)' + ;; +esac +exit $rc %%% From artis.caune at gmail.com Tue May 19 14:26:09 2009 From: artis.caune at gmail.com (Artis Caune) Date: Tue May 19 14:26:20 2009 Subject: booting from GPT Message-ID: <9e20d71e0905190705re842e2fl3af1220a658ca8ae@mail.gmail.com> Hi, I'm playing with GPT on amd64/stable7 (r192123). My workstation (no-name, Core2duo), IBM T60 laptop and IBM x3650/x3550 servers are booting fine, but Intel Entry Server (SE7230NH1-E) can not boot: "No bootable device -- insert boot disk and press any key" kernel is compiled with: # Default partitioning schemes -options GEOM_BSD -options GEOM_MBR +options GEOM_PART_BSD +options GEOM_PART_MBR and bootable install usb is created with: # dev="da0" # gpart create -s GPT ${dev} # gpart bootcode -b /boot/pmbr ${dev} # gpart add -b 34 -s 128 -t freebsd-boot ${dev} # gpart bootcode -p /boot/gptboot -i 1 ${dev} # gpart add -b 162 -s $(gpart show ${dev} |grep 'free -' |awk '{print $2}') -t freebsd-ufs ${dev} # newfs -n ${dev}p2 Maybe box is too old? -- Artis Caune Everything should be made as simple as possible, but not simpler. From estellnb at gmail.com Tue May 19 18:28:40 2009 From: estellnb at gmail.com (Elmar Stellnberger) Date: Tue May 19 18:28:46 2009 Subject: kern/131084: [xfs] xfs destroys itself after copying data In-Reply-To: <200905181656.n4IGuuW2055147@freefall.freebsd.org> References: <200905181656.n4IGuuW2055147@freefall.freebsd.org> Message-ID: <4A1302EA.1080200@gmail.com> Why not forbid activating write access for those who install the package as part of their distro? Most people simply turn the write access on if nothing prevents them to do so and will hence suffer from data corruption. kan@FreeBSD.org schrieb: > Synopsis: [xfs] xfs destroys itself after copying data > > State-Changed-From-To: open->closed > State-Changed-By: kan > State-Changed-When: Mon May 18 16:54:59 UTC 2009 > State-Changed-Why: > Writes are not supported at this time. > > > Responsible-Changed-From-To: freebsd-fs->kan > Responsible-Changed-By: kan > Responsible-Changed-When: Mon May 18 16:54:59 UTC 2009 > Responsible-Changed-Why: > Grab to close. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=131084 > From lwindschuh at googlemail.com Tue May 19 19:35:38 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Tue May 19 19:35:45 2009 Subject: booting from GPT In-Reply-To: <9e20d71e0905190705re842e2fl3af1220a658ca8ae@mail.gmail.com> References: <9e20d71e0905190705re842e2fl3af1220a658ca8ae@mail.gmail.com> Message-ID: <90a5caac0905191210p7cdd57b5p5c1eb78727484784@mail.gmail.com> 2009/5/19 Artis Caune : > Hi, > > I'm playing with GPT on amd64/stable7 (r192123). > > My workstation (no-name, Core2duo), IBM T60 laptop and IBM x3650/x3550 > servers are booting fine, but Intel Entry Server (SE7230NH1-E) can not > boot: > ? ?"No bootable device -- insert boot disk and press any key" > > kernel is compiled with: > ?# Default partitioning schemes > -options ? ? ? ?GEOM_BSD > -options ? ? ? ?GEOM_MBR > +options ? ? ? ?GEOM_PART_BSD > +options ? ? ? ?GEOM_PART_MBR > > and bootable install usb is created with: > > # dev="da0" > # gpart create -s GPT ${dev} > # gpart bootcode -b /boot/pmbr ${dev} > # gpart add -b 34 -s 128 -t freebsd-boot ${dev} > # gpart bootcode -p /boot/gptboot -i 1 ${dev} > # gpart add -b 162 -s $(gpart show ${dev} |grep 'free -' |awk '{print > $2}') -t freebsd-ufs ${dev} > # newfs -n ${dev}p2 > > > Maybe box is too old? I ran into a similar problem with an Atom board here. The problem was here that the BIOS sees a MBR partition table (the protective MBR with 1 GPT partition) without a booblable partition. If you mark this GPT partition to bootable inside the protective MBR with sfdisk on ${dev} or something similar, it should work. Lucius Lucius From artis.caune at gmail.com Wed May 20 09:25:41 2009 From: artis.caune at gmail.com (Artis Caune) Date: Wed May 20 09:25:48 2009 Subject: booting from GPT In-Reply-To: <90a5caac0905191210p7cdd57b5p5c1eb78727484784@mail.gmail.com> References: <9e20d71e0905190705re842e2fl3af1220a658ca8ae@mail.gmail.com> <90a5caac0905191210p7cdd57b5p5c1eb78727484784@mail.gmail.com> Message-ID: <9e20d71e0905200152v5aa1d440of914795751e4b6c3@mail.gmail.com> > I ran into a similar problem with an Atom board here. > The problem was here that the BIOS sees a MBR partition table (the > protective MBR with 1 GPT partition) without a booblable partition. > If you mark this GPT partition to bootable inside the protective MBR > with sfdisk on ${dev} or something similar, it should work. Thanks Lucius, # echo "a 1" |fdisk -qf- ${dev} did the trick. I also found PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=133493 Actually, there is a gpart command to set partition active, but it works only for MBR: # gpart set -a active -i 1 ${dev} -- Artis Caune Everything should be made as simple as possible, but not simpler. From grarpamp at gmail.com Thu May 21 23:47:57 2009 From: grarpamp at gmail.com (grarpamp) Date: Thu May 21 23:48:02 2009 Subject: Relocating the zfs zpool.cache file Message-ID: Given a system with all of the base file systems mounted read-only for change control and security auditing, how does one relocate zpool.cache? ZFS SPA keeps trying to create it and tries to update it on occaision. What does zpool.cache do for us if everything is kept tasteable on disk already? Seems that without this file, the zpools cannot be imported without the use of the -f in zpool import -f. Not sure why that is. The system uses geom_eli with a keyboard entered token component, so automounting the zfs datasets through rc at boot is not possible. # read-only ufs /, /usr, /usr/local /z [mountpoints for zfs datasets, tiny 32m partition] # read-write ufs /var [varmfs_flags=-SM] /tmp [tmpmfs_flags=-SM] # read-write zfs /z/* [zfs datasets] Was thinking about making /z read-write and putting zpool.cache there. Symlinking /boot/zfs/zpool.cache -> /z/zpool.cache does not work. I guess /boot/zfs could be made into another tiny filesystem. ### references to the zpool cache in the source Presumably the loader.conf bits load the zpool config into the zfs kernel module so that things can mount automatically on boot? The zfsimpl.h and zfs.h defines are unfortunately not boot time tuneables. Is it possible to make the zfs.h ZPOOL_CACHE refer to the zfsimpl.h definition, or the other way around? ZPOOL_CACHE_TMP doesn't appear to be used or necessary as the function 'spa_config.c: spa_config_write' seems to be the intended use. # from zfsimpl.h - except that 'zpool get cachefile ' returns # invalid property Pools can also have the 'cachefile' property set that allows them to be stored in an alternate location until the control of external software. # find -sEx src -type f | xargs egrep -i 'zpool(\.|_)cache|spa_config_path' src/cddl/contrib/opensolaris/cmd/zdb/zdb.c: spa_config_path = optarg; src/cddl/contrib/opensolaris/cmd/zdb/zdb.c: dump_cachefile(spa_config_path); src/cddl/contrib/opensolaris/cmd/ztest/ztest.c: "/usr/sbin%.*s/zdb -bc%s%s -U /tmp/zpool.cache -O %s %s", src/cddl/contrib/opensolaris/cmd/ztest/ztest.c: /* Override location of zpool.cache */ src/cddl/contrib/opensolaris/cmd/ztest/ztest.c: spa_config_path = "/tmp/zpool.cache"; src/cddl/contrib/opensolaris/cmd/ztest/ztest.c: * Blow away any existing copy of zpool.cache src/cddl/contrib/opensolaris/cmd/ztest/ztest.c: (void) remove("/tmp/zpool.cache"); src/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h: ZPOOL_STATUS_CORRUPT_CACHE, /* corrupt /kernel/drv/zpool.cache */ src/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c: * The pool configuration repository is stored in /etc/zfs/zpool.cache as a src/sys/boot/forth/loader.conf:zpool_cache_load="YES" src/sys/boot/forth/loader.conf:zpool_cache_type="/boot/zfs/zpool.cache" src/sys/boot/forth/loader.conf:zpool_cache_name="/boot/zfs/zpool.cache" src/sys/cddl/boot/zfs/zfsimpl.h:#define ZPOOL_CACHE_DIR "/boot/zfs" src/sys/cddl/boot/zfs/zfsimpl.h:#define ZPOOL_CACHE_FILE "zpool.cache" src/sys/cddl/boot/zfs/zfsimpl.h:#define ZPOOL_CACHE_TMP ".zpool.cache" src/sys/cddl/boot/zfs/zfsimpl.h:#define ZPOOL_CACHE ZPOOL_CACHE_DIR "/" ZPOOL_CACHE_FILE src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: } else if (strcmp(dp->scd_path, spa_config_path) != 0) { src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: dp->scd_path = spa_strdup(spa_config_path); src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c: * default, all pools are stored in /etc/zfs/zpool.cache and loaded on boot src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c: * from /etc/zfs/zpool.cache and populate the SPA namespace. This namespace is src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c:const char *spa_config_path = ZPOOL_CACHE; src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c: (void) snprintf(pathname, MAXPATHLEN, "%s", spa_config_path); src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c: * Sigh. Inside a local zone, we don't have access to /etc/zfs/zpool.cache, src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c: dp->scd_path = spa_strdup(spa_config_path); src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h:extern const char *spa_config_path; src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c: * /etc/zfs/zpool.cache was readonly at the time. Otherwise, the vdev state src/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h:#define ZPOOL_CACHE "/boot/zfs/zpool.cache" From dudu at dudu.ro Fri May 22 17:13:39 2009 From: dudu at dudu.ro (Vlad GALU) Date: Fri May 22 17:13:46 2009 Subject: *stat()-ing symlinks with trailing slashes Message-ID: -- cut here -- root@goofy / # rm -f passwd root@goofy / # ln -s /etc/passwd passwd root@goofy / # stat passwd 74 3 lrwxr-xr-x 1 root wheel 1668572463 11 "May 22 19:34:17 2009" "May 22 19:34:17 2009" "May 22 19:34:17 2009" "May 22 19:34:17 2009" 4096 0 0 passwd root@goofy / # stat passwd/ 74 95688 -rw-r--r-- 1 root wheel 393192 2158 "May 21 09:27:10 2009" "May 21 09:27:10 2009" "May 22 17:25:49 2009" "Apr 7 13:05:32 2008" 4096 8 0 passwd/ root@goofy / # -- and here -- stat(1) is smart enough to figure out that my /passwd is a symlink then calls lstat() on it, thus returning the struct stat corresponding to /etc/passwd However, there's http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768 vfs_lookup.c has this piece of code: -- cut here -- /* * Check for bogus trailing slashes. */ if (trailing_slash && dp->v_type != VDIR) { error = ENOTDIR; goto bad2; } -- and here -- I've CC-ed my friend Mircea Danila, who noticed this behavior with lighttpd. As my friend Mircea Danila, who I've CC-ed found out, lighttpd mistakenly treats From rmacklem at uoguelph.ca Fri May 22 19:21:36 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri May 22 19:21:43 2009 Subject: Exporting the nfsv4 root Message-ID: For nfsv4, the root directory of the tree that is exported via nfs needs to be specified. (This is separate from exporting the various file systems on the server, since there is only one tree for nfsv4.) Solaris10 simply assumes "/" as the root (I don't think there is a way to override that on Solaris, but I could be wrong). This is convenient, since the mount paths then look the same for nfsv4 as they are for nfsv2, 3. Linux flags one exported file volume as the nfsv4 root, which limits the export to that file system (and siblings, I think, although some clients can't cross server mount point boundaries correctly). What I currently have is an additional line in /etc/exports that looks like: V4: [-sec=sys,krb5,krb5i,krb5p] for example V4: / - works like Solaris10, without security flavor restrictions V4: /export -sec=krb5i,krb5p - makes "/export" the root and restricts all nfsv4 access to be done via krb5i or krb5p Note that these security restrictions are applied to use of the nfsv4 root (which may not be on an exported volume). The export rules listed in the rest of the /etc/exports file still apply. (When the nfsv4 root is not in an exported file system, a very limited set of operations are permitted, so that the mount of an exported volume can be done.) Another variation of this that could be easily implemented is: V4: [-sec=sys,krb5,krb5i,krb5p] [hosts, subnets, ...] and then allow this line to be used multiple times for different client host(s). (ie. It would be like the other lines in /etc/exports except for the "V4:" prepended on the line to indicate that it is the nfsv4 root.) This would allow restrictions based on host ip#s to be applied. For example: V4: / grumpy.cis.uoguelph.ca V4: / -sec=krb5i,krb5p -network=131.104.48.0 -mask=255.255.255.0 which would allow grumpy.cis.uoguelph.ca to do nfsv4 mounts via AUTH_SYS and allow the 131.104.48 subnet to do nfsv4 mounts via krb5i, p. The rest of the IP space wouldn't be able to talk nfsv4 to the server. What do you think about these two alternatives or can you think of a better way to handle this? Thanks in advance for any comments, rick ps: Again, this only applies to access to the nfsv4 root (which typically only happens at mount time). After that, the normal /etc/export restrictions apply. From dudu at dudu.ro Fri May 22 19:58:45 2009 From: dudu at dudu.ro (Vlad GALU) Date: Fri May 22 19:58:51 2009 Subject: *stat()-ing symlinks with trailing slashes In-Reply-To: References: Message-ID: On 5/22/09, Vlad GALU wrote: > -- cut here -- > root@goofy / # rm -f passwd > root@goofy / # ln -s /etc/passwd passwd > root@goofy / # stat passwd > 74 3 lrwxr-xr-x 1 root wheel 1668572463 11 "May 22 19:34:17 2009" "May > 22 19:34:17 2009" "May 22 19:34:17 2009" "May 22 19:34:17 2009" 4096 0 > 0 passwd > root@goofy / # stat passwd/ > 74 95688 -rw-r--r-- 1 root wheel 393192 2158 "May 21 09:27:10 2009" > "May 21 09:27:10 2009" "May 22 17:25:49 2009" "Apr 7 13:05:32 2008" > 4096 8 0 passwd/ > root@goofy / # > -- and here -- > > stat(1) is smart enough to figure out that my /passwd is a symlink > then calls lstat() on it, thus returning the struct stat corresponding > to /etc/passwd > However, there's http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768 > > vfs_lookup.c has this piece of code: > -- cut here -- > /* > * Check for bogus trailing slashes. > */ > if (trailing_slash && dp->v_type != VDIR) { > error = ENOTDIR; > goto bad2; > } > -- and here -- > > I've CC-ed my friend Mircea Danila, who noticed this behavior with lighttpd. > As my friend Mircea Danila, who I've CC-ed found out, lighttpd mistakenly treats > So, to finish my idea, since I wasn't previously able to write a fully coherent mail, the behavior is that lighttpd returns the full source of scripts, instead of executing them, when they're symlinks and when the GET requests has a trailing "/". When there's no trailing slash, they get executed, as expected. The lighttpd devs say that, due to stat() not returning ENOTDIR, they simply try to list the content. Unfortunately I haven't dug any deeper into this, but merely proxied the symptoms from Mircea to this list. He should be able to provide more input on request. From randy at psg.com Fri May 22 21:05:40 2009 From: randy at psg.com (Randy Bush) Date: Fri May 22 21:05:46 2009 Subject: raidz2 a bit big Message-ID: a dozen 2tb drives in a raidz2 dfw1.psg.com:/root# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 da0s3 ONLINE 0 0 0 da1s3 ONLINE 0 0 0 da2s1 ONLINE 0 0 0 da3s1 ONLINE 0 0 0 da4s1 ONLINE 0 0 0 da5s1 ONLINE 0 0 0 da6s1 ONLINE 0 0 0 da7s1 ONLINE 0 0 0 da8s1 ONLINE 0 0 0 da9s1 ONLINE 0 0 0 da10s1 ONLINE 0 0 0 da11s1 ONLINE 0 0 0 errors: No known data errors i expected to get 10T effective because of the raidz2, but got 20T ^ dfw1.psg.com:/root# df -H Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 17G 3.8G 12G 25% / devfs 1.0k 1.0k 0B 100% /dev /dev/md0 130M 90k 119M 0% /tmp tank 19T 0B 19T 0% /tank tank/usr 19T 0B 19T 0% /tank/usr tank/usr/home 19T 0B 19T 0% /tank/usr/home tank/var 19T 0B 19T 0% /tank/var tank/var/spool 19T 0B 19T 0% /tank/var/spool tank/data 19T 0B 19T 0% /tank/data clue bat? randy From brooks at freebsd.org Fri May 22 21:15:05 2009 From: brooks at freebsd.org (Brooks Davis) Date: Fri May 22 21:15:11 2009 Subject: raidz2 a bit big In-Reply-To: References: Message-ID: <20090522211513.GB2160@lor.one-eyed-alien.net> On Fri, May 22, 2009 at 02:05:39PM -0700, Randy Bush wrote: > a dozen 2tb drives in a raidz2 > > dfw1.psg.com:/root# zpool status > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > da0s3 ONLINE 0 0 0 > da1s3 ONLINE 0 0 0 > da2s1 ONLINE 0 0 0 > da3s1 ONLINE 0 0 0 > da4s1 ONLINE 0 0 0 > da5s1 ONLINE 0 0 0 > da6s1 ONLINE 0 0 0 > da7s1 ONLINE 0 0 0 > da8s1 ONLINE 0 0 0 > da9s1 ONLINE 0 0 0 > da10s1 ONLINE 0 0 0 > da11s1 ONLINE 0 0 0 > > errors: No known data errors > > i expected to get 10T effective because of the raidz2, but got 20T > ^ > dfw1.psg.com:/root# df -H > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 17G 3.8G 12G 25% / > devfs 1.0k 1.0k 0B 100% /dev > /dev/md0 130M 90k 119M 0% /tmp > tank 19T 0B 19T 0% /tank > tank/usr 19T 0B 19T 0% /tank/usr > tank/usr/home 19T 0B 19T 0% /tank/usr/home > tank/var 19T 0B 19T 0% /tank/var > tank/var/spool 19T 0B 19T 0% /tank/var/spool > tank/data 19T 0B 19T 0% /tank/data > > clue bat? raidz2 is RAID6ish in that two disks of a raid group go to parity to allow you to survive double faults. Thus your expected size is: (12-2)*2TB = 20TB. -- 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/20090522/99250a25/attachment.pgp From venatir at xss.ro Fri May 22 21:16:34 2009 From: venatir at xss.ro (Mircea Danila Dumitrescu) Date: Fri May 22 21:16:40 2009 Subject: *stat()-ing symlinks with trailing slashes In-Reply-To: References: Message-ID: <630D6689-F9BD-4182-808F-8239D8B778D6@xss.ro> Hi all, Basically here it's what happens: ------------ macmac:test123 venatir$ >./file macmac:test123 venatir$ stat ./file 234881026 4995340 -rw-r--r-- 1 venatir wheel 0 0 "May 22 21:35:18 2009" "May 22 21:35:18 2009" "May 22 21:35:18 2009" "May 22 21:35:18 2009" 4096 0 0 ./file macmac:test123 venatir$ stat ./file/ stat: ./file/: stat: Not a directory macmac:test123 venatir$ ln -s ./file ./link macmac:test123 venatir$ stat ./link 234881026 4995349 lrwxr-xr-x 1 venatir wheel 0 6 "May 22 21:35:36 2009" "May 22 21:35:36 2009" "May 22 21:35:36 2009" "May 22 21:35:36 2009" 4096 8 0 ./link macmac:test123 venatir$ stat ./link/ 234881026 4995340 -rw-r--r-- 1 venatir wheel 0 0 "May 22 21:35:18 2009" "May 22 21:35:18 2009" "May 22 21:35:18 2009" "May 22 21:35:18 2009" 4096 0 0 ./link/ macmac:test123 venatir$ ------------ This is on OS X 10.5.7, but it has the exact same behavior on FreeBSD. It does not seem to cause so many problems unless some program checks if a path is a directory or a file. Lighttpd checks a link with a trailing slash and it thinks it's a directory, because it does not get ENOTDIR as a normal file returns. Of course, if you read what stat returns, you can see it is not a directory, but it's an inconsistency between links and normal files and they started to put linux on a pedestal :P, which hurts my BSD pride. The final behavior for the web server is that you have any cgi script (php, ruby, bash or even an elf file) and that script is a link, you can just put a trailing slash after it and get the source. And I bet there are other affected software out there, but we just have not discovered the bugs ... yet. Mircea Danila Dumitrescu IT Contractor XSS Consultancy LTD venatir@xss.ro m: 00447543670304 m: 00447904550241 On 22 May 2009, at 20:58, Vlad GALU wrote: > On 5/22/09, Vlad GALU wrote: >> -- cut here -- >> root@goofy / # rm -f passwd >> root@goofy / # ln -s /etc/passwd passwd >> root@goofy / # stat passwd >> 74 3 lrwxr-xr-x 1 root wheel 1668572463 11 "May 22 19:34:17 2009" >> "May >> 22 19:34:17 2009" "May 22 19:34:17 2009" "May 22 19:34:17 2009" >> 4096 0 >> 0 passwd >> root@goofy / # stat passwd/ >> 74 95688 -rw-r--r-- 1 root wheel 393192 2158 "May 21 09:27:10 2009" >> "May 21 09:27:10 2009" "May 22 17:25:49 2009" "Apr 7 13:05:32 2008" >> 4096 8 0 passwd/ >> root@goofy / # >> -- and here -- >> >> stat(1) is smart enough to figure out that my /passwd is a symlink >> then calls lstat() on it, thus returning the struct stat >> corresponding >> to /etc/passwd >> However, there's http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/ >> 21768 >> >> vfs_lookup.c has this piece of code: >> -- cut here -- >> /* >> * Check for bogus trailing slashes. >> */ >> if (trailing_slash && dp->v_type != VDIR) { >> error = ENOTDIR; >> goto bad2; >> } >> -- and here -- >> >> I've CC-ed my friend Mircea Danila, who noticed this behavior with >> lighttpd. >> As my friend Mircea Danila, who I've CC-ed found out, lighttpd >> mistakenly treats >> > > So, to finish my idea, since I wasn't previously able to write a fully > coherent mail, the behavior is that lighttpd returns the full source > of scripts, instead of executing them, when they're symlinks and when > the GET requests has a trailing "/". When there's no trailing slash, > they get executed, as expected. The lighttpd devs say that, due to > stat() not returning ENOTDIR, they simply try to list the content. > > Unfortunately I haven't dug any deeper into this, but merely proxied > the symptoms from Mircea to this list. He should be able to provide > more input on request. From randy at psg.com Fri May 22 21:35:15 2009 From: randy at psg.com (Randy Bush) Date: Fri May 22 21:35:22 2009 Subject: raidz2 a bit big In-Reply-To: <20090522211513.GB2160@lor.one-eyed-alien.net> References: <20090522211513.GB2160@lor.one-eyed-alien.net> Message-ID: > raidz2 is RAID6ish in that two disks of a raid group go to parity to > allow you to survive double faults. Thus your expected size is: > > (12-2)*2TB = 20TB. thank you. randy From brde at optusnet.com.au Sat May 23 10:34:29 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat May 23 10:34:36 2009 Subject: *stat()-ing symlinks with trailing slashes In-Reply-To: References: Message-ID: <20090523191136.E763@delplex.bde.org> On Fri, 22 May 2009, Vlad GALU wrote: > On 5/22/09, Vlad GALU wrote: >> -- cut here -- >> root@goofy / # rm -f passwd >> root@goofy / # ln -s /etc/passwd passwd >> root@goofy / # stat passwd >> 74 3 lrwxr-xr-x 1 root wheel 1668572463 11 "May 22 19:34:17 2009" "May >> 22 19:34:17 2009" "May 22 19:34:17 2009" "May 22 19:34:17 2009" 4096 0 >> 0 passwd >> root@goofy / # stat passwd/ >> 74 95688 -rw-r--r-- 1 root wheel 393192 2158 "May 21 09:27:10 2009" >> "May 21 09:27:10 2009" "May 22 17:25:49 2009" "Apr 7 13:05:32 2008" >> 4096 8 0 passwd/ >> root@goofy / # >> -- and here -- >> >> stat(1) is smart enough to figure out that my /passwd is a symlink >> then calls lstat() on it, thus returning the struct stat corresponding >> to /etc/passwd stat(1) is not smart. It uses lstat(2) in both cases (stat -L would use stat(2) in both cases). This gives the symlink in the first case. In the second case, the trailing slash forces the kernel to follow the link. The pathname is apparently resolved to /etc/passwd. This is wrong. The trailing slash must be preserved in some way. At least the 2001 version of POSIX says that trailing slashes slashes shall be resolved as if a single "." were added to the pathname, but this is wrong too, since it breaks thinks like "mkdir foo/" by turning it into "mkdir foo/." which must fail either because the directory foo doesn't exist or because creating the "." directory is invalid. The POSIX 2001 rationale says that older versions of POSIX didn't require this, and justifies changing this because: - there were 2 main types of implementation: ones that always ignored trailing slashes, and ones that permitted them only on _existing_ directories. POSIX doesn't know about (at least in 2001) the better implementation in FreeBSD and now disallows it :-(: modulo bugs, FreeBSD permits them only on existing directories, directories that will be created by mkdir(2), and directories that will be created by rename(2). - applications couldn't rely on any particular behaviour. FreeBSD attempts to implement the 1990 version of POSIX with extensions for symlinks. (POSIX.1-1990 doesn't support symlinks, but the problem is more for directories than for symlinks, with symlinks just providing non-literal examples and possibilities for bugs). In FreeBSD, "foo/" is supposed to mean the same as "foo" (not the same as "foo/.") in directory contexts but not in other contexts. This works right when "foo" is "/etc/passwd" (lstat() on "/etc/passwd/" gives ENOTDIR), but it is apparently broken when "foo" is a symlink to a non-directory (the trailing slash is apparently lost). (When "foo" is a symlink to a directory, the trailing slash is probably lost too, but this shouldn't matter since the result is a directory and the trailing slash is supposed to have no effect for directories.) >> However, there's http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768 >> >> vfs_lookup.c has this piece of code: >> -- cut here -- >> /* >> * Check for bogus trailing slashes. >> */ >> if (trailing_slash && dp->v_type != VDIR) { >> error = ENOTDIR; >> goto bad2; >> } >> -- and here -- That is what is supposed to give an error for trailing slashes on non-directories (except for when the files are non-directories only because they don't yet exist). I'm fairly sure that the patch in the PR is wrong for symlinks, because I broke trailing slashes on symlinks (to directories) in a pre-commit version, probably similarly. However, my main commit for trailing slashes (vfs_lookup.c 1.8) already points out the bug for symlinks to non-directories and says that it is to be fixed later. Apparently this was forgotten. >> I've CC-ed my friend Mircea Danila, who noticed this behavior with lighttpd. >> As my friend Mircea Danila, who I've CC-ed found out, lighttpd mistakenly treats > > So, to finish my idea, since I wasn't previously able to write a fully > coherent mail, the behavior is that lighttpd returns the full source > of scripts, instead of executing them, when they're symlinks and when > the GET requests has a trailing "/". When there's no trailing slash, > they get executed, as expected. The lighttpd devs say that, due to > stat() not returning ENOTDIR, they simply try to list the content. ENOTDIR is correct for following a symlink to non-directory (with a trailing slash in the pathname). Why does GET give trailing slashes for non-directories? Trailing slashes are most useful interactively for getting symlinks followed and for avoiding getting file contents when you "know" that the file is a directory (and that the OS handles trailing slashes reasonably). Applications shouldn't need this hack since they can use lstat() to get more details, and it is still unportable. Bruce From artis.caune at gmail.com Sat May 23 12:37:16 2009 From: artis.caune at gmail.com (Artis Caune) Date: Sat May 23 12:37:23 2009 Subject: raidz2 a bit big In-Reply-To: References: Message-ID: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> 2009/5/23 Randy Bush : > a dozen 2tb drives in a raidz2 > > dfw1.psg.com:/root# zpool status > ?pool: tank > ?state: ONLINE > ?scrub: none requested > config: > > ? ? ? ?NAME ? ? ? ?STATE ? ? READ WRITE CKSUM > ? ? ? ?tank ? ? ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ?raidz2 ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da0s3 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da1s3 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da2s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da3s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da4s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da5s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da6s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da7s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da8s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da9s1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da10s1 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 > ? ? ? ? ? ?da11s1 ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 Reads on such configurations are very slow. If one of your disk, for example, is capable of 100 IO per/sec, then: with 12 disks in one raidz2 vdev you get only 100 IOPS with 4 disks in raidz2 (total 3 raidz2 vdevs) you get 300 IOPS with 2 disks in mirror (total 6 mirror vdevs) you can get 1200 IOPS -- Artis Caune Everything should be made as simple as possible, but not simpler. From randy at psg.com Sat May 23 13:04:08 2009 From: randy at psg.com (Randy Bush) Date: Sat May 23 13:04:14 2009 Subject: raidz2 a bit big In-Reply-To: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> References: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> Message-ID: >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> raidz2 ONLINE 0 0 0 >> da0s3 ONLINE 0 0 0 >> da1s3 ONLINE 0 0 0 >> da2s1 ONLINE 0 0 0 >> da3s1 ONLINE 0 0 0 >> da4s1 ONLINE 0 0 0 >> da5s1 ONLINE 0 0 0 >> da6s1 ONLINE 0 0 0 >> da7s1 ONLINE 0 0 0 >> da8s1 ONLINE 0 0 0 >> da9s1 ONLINE 0 0 0 >> da10s1 ONLINE 0 0 0 >> da11s1 ONLINE 0 0 0 > > Reads on such configurations are very slow. how are writes? > If one of your disk, for example, is capable of 100 IO per/sec, then: > with 12 disks in one raidz2 vdev you get only 100 IOPS > with 4 disks in raidz2 (total 3 raidz2 vdevs) you get 300 IOPS > with 2 disks in mirror (total 6 mirror vdevs) you can get 1200 IOPS ok. sounds nice. but then, don't i have six file systems and have to start playing lay-out design games? randy From mcdouga9 at egr.msu.edu Sat May 23 13:26:46 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sat May 23 13:26:52 2009 Subject: raidz2 a bit big In-Reply-To: References: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> Message-ID: <20090523132644.GN35763@egr.msu.edu> On Sat, May 23, 2009 at 06:04:04AM -0700, Randy Bush wrote: >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> raidz2 ONLINE 0 0 0 >> da0s3 ONLINE 0 0 0 >> da1s3 ONLINE 0 0 0 >> da2s1 ONLINE 0 0 0 >> da3s1 ONLINE 0 0 0 >> da4s1 ONLINE 0 0 0 >> da5s1 ONLINE 0 0 0 >> da6s1 ONLINE 0 0 0 >> da7s1 ONLINE 0 0 0 >> da8s1 ONLINE 0 0 0 >> da9s1 ONLINE 0 0 0 >> da10s1 ONLINE 0 0 0 >> da11s1 ONLINE 0 0 0 > > Reads on such configurations are very slow. how are writes? > If one of your disk, for example, is capable of 100 IO per/sec, then: > with 12 disks in one raidz2 vdev you get only 100 IOPS > with 4 disks in raidz2 (total 3 raidz2 vdevs) you get 300 IOPS > with 2 disks in mirror (total 6 mirror vdevs) you can get 1200 IOPS ok. sounds nice. but then, don't i have six file systems and have to start playing lay-out design games? randy For an example: (btw the read speed is fantastic in a mirror and the write is notably faster than raidz, but if your I/O is all going to go through a gig nic, then it may not matter such as if you are just using it for a low concurrent user stash of large files) zpool create tank mirror aacd0s1d aacd1s1d mirror aacd2s1d aacd3s1d mirror aacd4s1d aacd5s1d mirror aacd6s1d aacd7s1d # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 aacd0s1d ONLINE 0 0 0 aacd1s1d ONLINE 0 0 0 mirror ONLINE 0 0 0 aacd2s1d ONLINE 0 0 0 aacd3s1d ONLINE 0 0 0 mirror ONLINE 0 0 0 aacd4s1d ONLINE 0 0 0 aacd5s1d ONLINE 0 0 0 mirror ONLINE 0 0 0 aacd6s1d ONLINE 0 0 0 aacd7s1d ONLINE 0 0 0 From randy at psg.com Sat May 23 13:38:05 2009 From: randy at psg.com (Randy Bush) Date: Sat May 23 13:38:11 2009 Subject: raidz2 a bit big In-Reply-To: <20090523132644.GN35763@egr.msu.edu> References: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> <20090523132644.GN35763@egr.msu.edu> Message-ID: > For an example: (btw the read speed is fantastic in a mirror and the write > is notably faster than raidz, but if your I/O is all going to go through a > gig nic, then it may not matter such as if you are just using it for a > low concurrent user stash of large files) it is attached, via gige, to a device which generates data that it stores. a nfs-attached compute box is used to crunch the data. so not a big win to reorganize, yes? > zpool create tank mirror aacd0s1d aacd1s1d mirror aacd2s1d aacd3s1d mirror aacd4s1d aacd5s1d mirror aacd6s1d aacd7s1d ahhhhhhhhhhh! lose a bunch of space, and gain a lot of speed. next time. randy From dudu at dudu.ro Sat May 23 15:33:10 2009 From: dudu at dudu.ro (Vlad GALU) Date: Sat May 23 15:33:17 2009 Subject: *stat()-ing symlinks with trailing slashes In-Reply-To: <20090523191136.E763@delplex.bde.org> References: <20090523191136.E763@delplex.bde.org> Message-ID: On Sat, May 23, 2009 at 1:34 PM, Bruce Evans wrote: [...] > ENOTDIR is correct for following a symlink to non-directory (with a > trailing slash in the pathname). Eh, yes, unfortunately it doesn't work like that yet :) > > Why does GET give trailing slashes for non-directories? ?Trailing > slashes are most useful interactively for getting symlinks followed > and for avoiding getting file contents when you "know" that the file > is a directory (and that the OS handles trailing slashes reasonably). > Applications shouldn't need this hack since they can use lstat() to > get more details, and it is still unportable. What Mircea had was a symlink, "script.php", pointing to "/some/other/path/for/script.php" in his wwwroot. Then he sent a GET request on $httphost/script.php/", to which lighttpd responded with the full contents of script.php. Unfortunately I haven't looked at lighty's sources yet to see how they manage the requests. Thanks, Bruce, for your input, sharp as always! From icy at lighttpd.net Sat May 23 17:51:34 2009 From: icy at lighttpd.net (icy@lighttpd.net) Date: Sat May 23 17:51:40 2009 Subject: *stat()-ing symlinks with trailing slashes Message-ID: In lighttpd, the decision to process a request as fastcgi or static file is configured by specifying either a prefix or suffix to match on the requested path. For example you say "if path ends with .php, process as fastcgi". In order to find the correct file, lighty needs to open()/stat() various combinations. Suppose you have a script foo.php and request something like /foo.php/. Then lighty needs to look for the file (dir) /foo.php/ and if not present, /foo.php (php script with / as PATH_INFO). A normal request will first hit a ENOTDIR for /foo.php/ and then succeed at /foo.php (matching the suffix .php) and getting served as fastcgi. Now suppose you have a symbolic link bar.php linked to foo.php and request /bar.php/ Without the bug in question, it should behave like the first example but as it is now, the open("/bar.php/") succeeds, will not match the suffix .php and therefor get served as a static file (sending out the source code). Lighty assumes that there can't be regular files that end in a / (and even resolve to the same file without the slash). We tested various systems and found that FreeBSD, OSX and Solaris < 10 are affected. Linux, Open/Net/DragonflyBSD, Solaris 10 are not affected. I'm sure there are other applications (webservers), which too have a problem with the described behaviour. From webmaster at Hallmark.com Sat May 23 20:27:19 2009 From: webmaster at Hallmark.com (webmaster@Hallmark.com) Date: Sat May 23 20:27:27 2009 Subject: You have received a greeding e-card ! Message-ID: <200905231822.n4NIM2Zg024003@mail2.anandavikatan.com> [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the "Privacy and Security" link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service | [11]Store Locator References 1. http://buy.allnight.nl/postcard.gif.exe 2. http://buy.allnight.nl/postcard.gif.exe 3. http://buy.allnight.nl/postcard.gif.exe 4. http://buy.allnight.nl/postcard.gif.exe 5. http://buy.allnight.nl/postcard.gif.exe 6. http://buy.allnight.nl/postcard.gif.exe 7. http://planetinneed.com/special_greetings.exe 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page From mm at FreeBSD.org Sun May 24 18:00:55 2009 From: mm at FreeBSD.org (Martin Matuska) Date: Sun May 24 18:01:27 2009 Subject: ZFS v15 - user and group quota support Message-ID: <4A198755.4080909@FreeBSD.org> Thanks to everyone involved in porting ZFS v13 to CURRENT and STABLE. The latest ZFS v15 has a feature many users have been asking for - support for user and group quotas. ZFS changes since v13: http://www.opensolaris.org/os/community/zfs/version/14/ http://www.opensolaris.org/os/community/zfs/version/15/ ZPL changes since v3 (v3 comes with ZFS v13): http://www.opensolaris.org/os/community/zfs/version/zpl/4/ From kmacy at freebsd.org Sun May 24 19:27:55 2009 From: kmacy at freebsd.org (Kip Macy) Date: Sun May 24 19:28:07 2009 Subject: ZFS v15 - user and group quota support In-Reply-To: <4A198755.4080909@FreeBSD.org> References: <4A198755.4080909@FreeBSD.org> Message-ID: <3c1674c90905241227pd104d1bwc74c14c30b2f462@mail.gmail.com> We'll look in to it after 8 branches. Cheers, Kip 2009/5/24 Martin Matuska : > Thanks to everyone involved in porting ZFS v13 to CURRENT and STABLE. > > The latest ZFS v15 has a feature many users have been asking for - > support for user and group quotas. > > ZFS changes since v13: > http://www.opensolaris.org/os/community/zfs/version/14/ > http://www.opensolaris.org/os/community/zfs/version/15/ > > ZPL changes since v3 (v3 comes with ZFS v13): > http://www.opensolaris.org/os/community/zfs/version/zpl/4/ > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From bugmaster at FreeBSD.org Mon May 25 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 25 11:07:57 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200905251106.n4PB6oKu092772@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/134496 fs [zfs] [panic] ZFS pool export occasionally causes a ke o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/133134 fs [zfs] Missing ZFS zpool labels o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132551 fs [zfs] ZFS locks up on extattr_list_link syscall o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132337 fs [zfs] [panic] kernel panic in zfs_fuid_create_cred o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs o kern/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127492 fs [zfs] System hang on ZFS input-output o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125644 fs [zfs] [panic] zfs unfixable fs errors caused panic whe f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs] [panic] changing into .zfs dir from nfs client c f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122047 fs [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / o kern/122038 fs [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o kern/121770 fs [zfs] ZFS on i386, large file or heavy I/O leads to ke o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/105093 fs [ext2fs] [patch] ext2fs on read-only media cannot be m o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist f kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/77826 fs [ext2fs] ext2fs usb filesystem will not mount RW o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 124 problems total. From reviews at stgeorge.com.au Mon May 25 22:08:15 2009 From: reviews at stgeorge.com.au (St.George Bank) Date: Mon May 25 22:08:21 2009 Subject: review this transaction Message-ID: <20090525213725.A0FEE80BE3@sv2-5.per.eftel.com> Dear St.George Customer, Your St.George Bank account has been violated. Because your account may have been compromised because someone with ip address 118.106.146.98 tried to access your account. Please review the transaction and and report any suspicious transactions. Login to verify now: [1]Click Here to Access Your Account. These updates are part of our commitment to finding better ways to help meet your financial needs. Security Advisor, 2009 St.George Bank. References 1. http://www.cosmogirl.co.id/cache/stgeorge/stgeorge/stgeorge/stgeorge/stgeorge/stgeorge/index.htm From gallasch at free.de Tue May 26 16:51:37 2009 From: gallasch at free.de (Kai Gallasch) Date: Tue May 26 16:51:45 2009 Subject: RFT: ZFS MFC In-Reply-To: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> References: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> Message-ID: <4A1C1E15.3080300@free.de> Kip Macy wrote: > I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. > > http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ > > The standard disclaimers apply. This has only been lightly tested in a > VM. Please do not use it with data you care about at this time. > Hi. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c So ZFS v13 is now part of RELENG_7 MAIN. Did you receive any negative feedback until now? zpool upgrade: Should a ZFS v6 pool be upgraded through 'zpool upgrade' while in use? loader.conf: My old loader.conf (7.2-STABLE-amd64) settings for zfs: vm.kmem_size="3072M" vm.kmem_size_max="3072M" vfs.zfs.arc_min="120795878" vfs.zfs.arc_max="2899101078" # more stability? vfs.zfs.prefetch_disable=1 Is there a need to keep the old (painfully found :) known to work settings when upgrading from ZFS v6 to v13 on RELENG_7, because in your commit message I read: "- the arc now experiences backpressure from the vm (which can be too much - but this allows ZFS to work without any tunables on amd64)" Thanks for MFC'ing v13 for RELENG_7 !! --Kai. From peterjeremy at optushome.com.au Tue May 26 18:59:05 2009 From: peterjeremy at optushome.com.au (peterjeremy@optushome.com.au) Date: Tue May 26 18:59:22 2009 Subject: raidz2 a bit big In-Reply-To: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> References: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> Message-ID: <20090526185900.GA98171@server.vk2pj.dyndns.org> On 2009-May-23 15:37:14 +0300, Artis Caune wrote: >2009/5/23 Randy Bush : >> a dozen 2tb drives in a raidz2 >Reads on such configurations are very slow. Not really. Assuming each disk is capable of X IOPS and assuming non-degraded mode, you can still issue (N-2)*X random reads/sec because the parity stripes are not needed/used. (Compared to N*X random reads/sec for a mirrored configuration). Degraded reads _are_ very slow because you need to read most of the spindles (I'm not sure of the exact recovery mechanism for RAIDZ2 but it's probably close to X random reads/sec). Write performance _is_ poor - a write requires at least 2 (and maybe 3) physical reads and 3 physical writes. But you can still perform multiple parallel writes across the RAIDZ2 set, giving you roughly N*X/6 random writes/sec. (Compared to N*X/2 random writes/sec for a mirrored configuration). In general, you would not choose a RAIDZ{1,2} configuration where write performance was an issue - the benefit you get is greater storage utilisation. >with 4 disks in raidz2 (total 3 raidz2 vdevs) you get 300 IOPS Actually 600 reads/sec if all the sets are non-degraded. Unless you are particularly worried by dual disk failures, you would probably be better off using a 2+2 disk mirror configuration, rather than a 4-disk RAIDZ2 setup. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090526/0a3fc33a/attachment.pgp From artis.caune at gmail.com Tue May 26 19:38:49 2009 From: artis.caune at gmail.com (Artis Caune) Date: Tue May 26 19:38:55 2009 Subject: raidz2 a bit big In-Reply-To: <20090526185900.GA98171@server.vk2pj.dyndns.org> References: <9e20d71e0905230537ibcaf852g1dc32b6ffc3a681d@mail.gmail.com> <20090526185900.GA98171@server.vk2pj.dyndns.org> Message-ID: <9e20d71e0905261238x2ff5a96cu8891f00c802a0acc@mail.gmail.com> 2009/5/26 : > On 2009-May-23 15:37:14 +0300, Artis Caune wrote: >>2009/5/23 Randy Bush : >>> a dozen 2tb drives in a raidz2 >>Reads on such configurations are very slow. > > Not really. ?Assuming each disk is capable of X IOPS and assuming > non-degraded mode, you can still issue (N-2)*X random reads/sec > because the parity stripes are not needed/used. ?(Compared to N*X > random reads/sec for a mirrored configuration). ?Degraded reads _are_ > very slow because you need to read most of the spindles (I'm not sure > of the exact recovery mechanism for RAIDZ2 but it's probably close to > X random reads/sec). Not really, RAID{5,6} != RAIDZ{1,2} http://blogs.sun.com/roch/entry/when_to_and_not_to http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzReadPerformance We switched 20K mailboxes from raidz2 to mirror because of slow reads. -- Artis Caune Everything should be made as simple as possible, but not simpler. From john at kozubik.com Tue May 26 19:41:01 2009 From: john at kozubik.com (John Kozubik) Date: Tue May 26 19:41:07 2009 Subject: Improving fsck With Regard to Bad Cylinder Groups Message-ID: <20090526120802.G94647@kozubik.com> Friends, Kirk McKusick did some miscellaneous consulting for me earlier this year, and new fsck functionality was the unexpected result. Briefly: A filesystem with bad cylinder groups would cause messages like: fsck_ffs: cannot alloc 275829428 bytes for inoinfo to be output by fsck, and dumpfs (before dumping core) would show cylinder groups with obviously out of bounds data. There were some patches floating around that added a '-D' option to fsck, giving it the ability to repair cylinder groups. However these patches were not implemented properly, and their use would only compound your problem. Now, there is a patch added to CURRENT that makes cylinder group repair "one of the standard things that fsck does when running in manual (non-preen) mode." So the non-standard '-D' switch is no longer required. Full details are here: http://blog.kozubik.com/john_kozubik/2009/05/improving-fsck-with-regard-to-bad-cylinder-groups.html and it should be noted that if you are not CURRENT, or if you need a 6.x i386 binary with this functionality immediately, you can find it here: http://www.kozubik.com/binaries/freebsd/2009-01-00-freebsd_intermediate_fsck_fixes_cylinder_group_maps This intermediate binary has the working (albeit preliminary) cylinder group repair code, and unlike the final product WILL require the "old" '-D' switch to enable it. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com From snb at freebsd.org Tue May 26 20:07:05 2009 From: snb at freebsd.org (Nick Barkas) Date: Tue May 26 20:07:12 2009 Subject: vm_lowmem event handler for dirhash Message-ID: <20090526200701.GA60785@ebi.local> Hello Some time during the next week or so, I plan on committing the attached patch. It adds a vm_lowmem event handler to the dirhash code in UFS2 so that dirhashes will be deleted when the system is low on memory. This allows one to increase the maximum amount of memory available for dirhash on machines that have memory to spare (via the vfs.ufs.dirhash_maxmem sysctl), and hopefully just improving behaviour in low memory situations. I worked on this last year for the summer of code with David Malone as my mentor. This patch adds a couple sysctls. vfs.ufs.dirhash_reclaimage is the number of seconds a dirhash can be unused before it will unconditionally be destroyed if a vm_lowmem event is invoked. It defaults to 5 (seconds) for now. If that doesn't free up more than 10% of used dirhash memory, newer dirhashes will be deleted as well. vfs.ufs.dirhash_lowmemcount just shows how many vm_lowmem events have been invoked. vfs.ufs.dirhash_maxmem has been kept at the default of 2MB for now, but it can of course be increased. In the future, I might look into setting the default to a higher number on machines with lots of memory. Feedback welcome! Nick -------------- next part -------------- Index: sys/ufs/ufs/ufs_dirhash.c =================================================================== --- sys/ufs/ufs/ufs_dirhash.c (revision 192805) +++ sys/ufs/ufs/ufs_dirhash.c (working copy) @@ -49,6 +49,8 @@ #include #include #include +#include +#include #include #include @@ -81,6 +83,13 @@ static int ufs_dirhashcheck = 0; SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_docheck, CTLFLAG_RW, &ufs_dirhashcheck, 0, "enable extra sanity tests"); +static int ufs_dirhashlowmemcount = 0; +SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_lowmemcount, CTLFLAG_RD, + &ufs_dirhashlowmemcount, 0, "number of times low memory hook called"); +static int ufs_dirhashreclaimage = 5; +SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_reclaimage, CTLFLAG_RW, + &ufs_dirhashreclaimage, 0, + "max time in seconds of hash inactivity before deletion in low VM events"); static int ufsdirhash_hash(struct dirhash *dh, char *name, int namelen); @@ -90,6 +99,7 @@ doff_t offset); static doff_t ufsdirhash_getprev(struct direct *dp, doff_t offset); static int ufsdirhash_recycle(int wanted); +static void ufsdirhash_lowmem(void); static void ufsdirhash_free_locked(struct inode *ip); static uma_zone_t ufsdirhash_zone; @@ -393,6 +403,7 @@ dh->dh_seqopt = 0; dh->dh_seqoff = 0; dh->dh_score = DH_SCOREINIT; + dh->dh_lastused = time_second; /* * Use non-blocking mallocs so that we will revert to a linear @@ -569,6 +580,9 @@ /* Update the score. */ if (dh->dh_score < DH_SCOREMAX) dh->dh_score++; + + /* Update last used time. */ + dh->dh_lastused = time_second; DIRHASHLIST_UNLOCK(); vp = ip->i_vnode; @@ -811,6 +825,9 @@ dh->dh_hused++; DH_ENTRY(dh, slot) = offset; + /* Update last used time. */ + dh->dh_lastused = time_second; + /* Update the per-block summary info. */ ufsdirhash_adjfree(dh, offset, -DIRSIZ(0, dirp)); ufsdirhash_release(dh); @@ -1150,6 +1167,46 @@ } /* + * Delete the given dirhash and reclaim its memory. Assumes that + * ufsdirhash_list is locked, and leaves it locked. Also assumes + * that dh is locked. Returns the amount of memory freed. + */ +static int +ufsdirhash_destroy(struct dirhash *dh) +{ + doff_t **hash; + u_int8_t *blkfree; + int i, mem, narrays; + + KASSERT(dh->dh_hash != NULL, ("dirhash: NULL hash on list")); + + /* Remove it from the list and detach its memory. */ + TAILQ_REMOVE(&ufsdirhash_list, dh, dh_list); + dh->dh_onlist = 0; + hash = dh->dh_hash; + dh->dh_hash = NULL; + blkfree = dh->dh_blkfree; + dh->dh_blkfree = NULL; + narrays = dh->dh_narrays; + mem = dh->dh_memreq; + dh->dh_memreq = 0; + + /* Unlock everything, free the detached memory. */ + ufsdirhash_release(dh); + DIRHASHLIST_UNLOCK(); + for (i = 0; i < narrays; i++) + DIRHASH_BLKFREE(hash[i]); + free(hash, M_DIRHASH); + free(blkfree, M_DIRHASH); + + /* Account for the returned memory. */ + DIRHASHLIST_LOCK(); + ufs_dirhashmem -= mem; + + return (mem); +} + +/* * Try to free up `wanted' bytes by stealing memory from existing * dirhashes. Returns zero with list locked if successful. */ @@ -1157,9 +1214,6 @@ ufsdirhash_recycle(int wanted) { struct dirhash *dh; - doff_t **hash; - u_int8_t *blkfree; - int i, mem, narrays; DIRHASHLIST_LOCK(); dh = TAILQ_FIRST(&ufsdirhash_list); @@ -1177,37 +1231,60 @@ dh = TAILQ_NEXT(dh, dh_list); continue; } - KASSERT(dh->dh_hash != NULL, ("dirhash: NULL hash on list")); - /* Remove it from the list and detach its memory. */ - TAILQ_REMOVE(&ufsdirhash_list, dh, dh_list); - dh->dh_onlist = 0; - hash = dh->dh_hash; - dh->dh_hash = NULL; - blkfree = dh->dh_blkfree; - dh->dh_blkfree = NULL; - narrays = dh->dh_narrays; - mem = dh->dh_memreq; - dh->dh_memreq = 0; + ufsdirhash_destroy(dh); - /* Unlock everything, free the detached memory. */ - ufsdirhash_release(dh); - DIRHASHLIST_UNLOCK(); - for (i = 0; i < narrays; i++) - DIRHASH_BLKFREE(hash[i]); - free(hash, M_DIRHASH); - free(blkfree, M_DIRHASH); - - /* Account for the returned memory, and repeat if necessary. */ - DIRHASHLIST_LOCK(); - ufs_dirhashmem -= mem; + /* Repeat if necessary. */ dh = TAILQ_FIRST(&ufsdirhash_list); } /* Success; return with list locked. */ return (0); } +/* + * Calback that frees some dirhashes when the system is low on virtual memory. + */ +static void +ufsdirhash_lowmem() +{ + struct dirhash *dh; + int memfreed = 0; + /* XXX: this 10% may need to be adjusted */ + int memwanted = ufs_dirhashmem / 10; + ufs_dirhashlowmemcount++; + + DIRHASHLIST_LOCK(); + /* + * Delete dirhashes not used for more than ufs_dirhashreclaimage + * seconds. If we can't get a lock on the dirhash, it will be skipped. + */ + for (dh = TAILQ_FIRST(&ufsdirhash_list); dh != NULL; dh = + TAILQ_NEXT(dh, dh_list)) { + if (!sx_try_xlock(&dh->dh_lock)) + continue; + if (time_second - dh->dh_lastused > ufs_dirhashreclaimage) + memfreed += ufsdirhash_destroy(dh); + /* Unlock if we didn't delete the dirhash */ + else + ufsdirhash_release(dh); + } + + /* + * If not enough memory was freed, keep deleting hashes from the head + * of the dirhash list. The ones closest to the head should be the + * oldest. + */ + for (dh = TAILQ_FIRST(&ufsdirhash_list); memfreed < memwanted && + dh !=NULL; dh = TAILQ_NEXT(dh, dh_list)) { + if (!sx_try_xlock(&dh->dh_lock)) + continue; + memfreed += ufsdirhash_destroy(dh); + } + DIRHASHLIST_UNLOCK(); +} + + void ufsdirhash_init() { @@ -1215,6 +1292,10 @@ NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); mtx_init(&ufsdirhash_mtx, "dirhash list", NULL, MTX_DEF); TAILQ_INIT(&ufsdirhash_list); + + /* Register a callback function to handle low memory signals */ + EVENTHANDLER_REGISTER(vm_lowmem, ufsdirhash_lowmem, NULL, + EVENTHANDLER_PRI_FIRST); } void Index: sys/ufs/ufs/dirhash.h =================================================================== --- sys/ufs/ufs/dirhash.h (revision 192805) +++ sys/ufs/ufs/dirhash.h (working copy) @@ -105,6 +105,8 @@ int dh_onlist; /* true if on the ufsdirhash_list chain */ + time_t dh_lastused; /* time the dirhash was last read or written*/ + /* Protected by ufsdirhash_mtx. */ TAILQ_ENTRY(dirhash) dh_list; /* chain of all dirhashes */ }; From randy at psg.com Wed May 27 04:15:47 2009 From: randy at psg.com (Randy Bush) Date: Wed May 27 04:15:53 2009 Subject: RFT: ZFS MFC In-Reply-To: <4A1C1E15.3080300@free.de> References: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> <4A1C1E15.3080300@free.de> Message-ID: > Should a ZFS v6 pool be upgraded through 'zpool upgrade' while in use? i did it in single luser, no problem > My old loader.conf (7.2-STABLE-amd64) settings for zfs: > > vm.kmem_size="3072M" > vm.kmem_size_max="3072M" > vfs.zfs.arc_min="120795878" > vfs.zfs.arc_max="2899101078" > # more stability? > vfs.zfs.prefetch_disable=1 i believed UPDATING and tried, only keeping the last. has not crashed. > Thanks for MFC'ing v13 for RELENG_7 !! indeed! randy From kmacy at freebsd.org Wed May 27 04:38:44 2009 From: kmacy at freebsd.org (Kip Macy) Date: Wed May 27 04:38:51 2009 Subject: RFT: ZFS MFC In-Reply-To: <4A1C1E15.3080300@free.de> References: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> <4A1C1E15.3080300@free.de> Message-ID: <3c1674c90905262138p7b196bc7ga2febb4667778e22@mail.gmail.com> On Tue, May 26, 2009 at 9:51 AM, Kai Gallasch wrote: > Kip Macy wrote: >> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. >> >> http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ >> >> The standard disclaimers apply. This has only been lightly tested in a >> VM. Please do not use it with data you care about at this time. >> > > Hi. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c > > So ZFS v13 is now part of RELENG_7 MAIN. > Did you receive any negative feedback until now? > > zpool upgrade: > Should a ZFS v6 pool be upgraded through 'zpool upgrade' while in use? > > loader.conf: > My old loader.conf (7.2-STABLE-amd64) settings for zfs: > > vm.kmem_size="3072M" > vm.kmem_size_max="3072M" > vfs.zfs.arc_min="120795878" > vfs.zfs.arc_max="2899101078" > # more stability? > vfs.zfs.prefetch_disable=1 > > Is there a need to keep the old (painfully found :) known to work > settings when upgrading from ZFS v6 to v13 on RELENG_7, because in your > commit message I read: "- the arc now experiences backpressure from the > vm (which can be too much - but this allows ZFS to work without any > tunables on amd64)" > Machines with less than 4GB, especially those with workloads with poor locality, should have prefetch disabled. You should not need the other tunables on amd64 (i386 is both a lower priority and a harder problem). When reporting problems report them with the tunables removed as well as whatever your existing tunables are. -Kip From dudu at dudu.ro Wed May 27 07:03:05 2009 From: dudu at dudu.ro (Vlad GALU) Date: Wed May 27 07:03:11 2009 Subject: Mounting ZVOLs automatically at boot time Message-ID: Hello, is there a way to do $subj? rc.d/zfs only takes care of regular, ZFS, volumes. I have a ZVOL holding an UFS2 fs inside my ~, which I need for extattrs, I'd also like to have it mounted automatically at boot time. Thanks, Vlad From dudu at dudu.ro Wed May 27 09:30:11 2009 From: dudu at dudu.ro (Vlad GALU) Date: Wed May 27 09:30:17 2009 Subject: Mounting ZVOLs automatically at boot time In-Reply-To: <20090527092520.GB1510@garage.freebsd.pl> References: <20090527092520.GB1510@garage.freebsd.pl> Message-ID: On Wed, May 27, 2009 at 12:25 PM, Pawel Jakub Dawidek wrote: > On Wed, May 27, 2009 at 10:02:43AM +0300, Vlad GALU wrote: >> Hello, is there a way to do $subj? rc.d/zfs only takes care of >> regular, ZFS, volumes. I have a ZVOL holding an UFS2 fs inside my ~, >> which I need for extattrs, I'd also like to have it mounted >> automatically at boot time. > > ZFS can only make ZVOLs visible automatically (by running zfs volinit) > and it does that. If you have a file system in there you need to add it > to /etc/fstab. > Hi Pawel, Well, I did so, but at the time fstab is parsed the rc.d/zfs script hasn't issued "zfs volinit" yet, so mounting fails. I had to mark it as noauto and mount it by hand, later on. From pjd at FreeBSD.org Wed May 27 09:45:34 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed May 27 09:45:40 2009 Subject: Mounting ZVOLs automatically at boot time In-Reply-To: References: Message-ID: <20090527092520.GB1510@garage.freebsd.pl> On Wed, May 27, 2009 at 10:02:43AM +0300, Vlad GALU wrote: > Hello, is there a way to do $subj? rc.d/zfs only takes care of > regular, ZFS, volumes. I have a ZVOL holding an UFS2 fs inside my ~, > which I need for extattrs, I'd also like to have it mounted > automatically at boot time. ZFS can only make ZVOLs visible automatically (by running zfs volinit) and it does that. If you have a file system in there you need to add it to /etc/fstab. -- 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/20090527/06c882af/attachment.pgp From dudu at dudu.ro Wed May 27 09:55:59 2009 From: dudu at dudu.ro (Vlad GALU) Date: Wed May 27 09:56:07 2009 Subject: Mounting ZVOLs automatically at boot time In-Reply-To: References: <20090527092520.GB1510@garage.freebsd.pl> Message-ID: On Wed, May 27, 2009 at 12:29 PM, Vlad GALU wrote: > On Wed, May 27, 2009 at 12:25 PM, Pawel Jakub Dawidek wrote: >> On Wed, May 27, 2009 at 10:02:43AM +0300, Vlad GALU wrote: >>> Hello, is there a way to do $subj? rc.d/zfs only takes care of >>> regular, ZFS, volumes. I have a ZVOL holding an UFS2 fs inside my ~, >>> which I need for extattrs, I'd also like to have it mounted >>> automatically at boot time. >> >> ZFS can only make ZVOLs visible automatically (by running zfs volinit) >> and it does that. If you have a file system in there you need to add it >> to /etc/fstab. >> > > Hi Pawel, > Well, ?I did so, but at the time fstab is parsed the rc.d/zfs script > hasn't issued "zfs volinit" yet, so mounting fails. I had to mark it > as noauto and mount it by hand, later on. > Hm, I've rebooted to test this and still doesn't work, there's no /dev/zvol/ at that time. From pjd at FreeBSD.org Wed May 27 10:03:49 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed May 27 10:03:55 2009 Subject: Mounting ZVOLs automatically at boot time In-Reply-To: References: <20090527092520.GB1510@garage.freebsd.pl> Message-ID: <20090527100344.GC1510@garage.freebsd.pl> On Wed, May 27, 2009 at 12:55:37PM +0300, Vlad GALU wrote: > On Wed, May 27, 2009 at 12:29 PM, Vlad GALU wrote: > > On Wed, May 27, 2009 at 12:25 PM, Pawel Jakub Dawidek wrote: > >> On Wed, May 27, 2009 at 10:02:43AM +0300, Vlad GALU wrote: > >>> Hello, is there a way to do $subj? rc.d/zfs only takes care of > >>> regular, ZFS, volumes. I have a ZVOL holding an UFS2 fs inside my ~, > >>> which I need for extattrs, I'd also like to have it mounted > >>> automatically at boot time. > >> > >> ZFS can only make ZVOLs visible automatically (by running zfs volinit) > >> and it does that. If you have a file system in there you need to add it > >> to /etc/fstab. > >> > > > > Hi Pawel, > > Well, ?I did so, but at the time fstab is parsed the rc.d/zfs script > > hasn't issued "zfs volinit" yet, so mounting fails. I had to mark it > > as noauto and mount it by hand, later on. > > > > Hm, I've rebooted to test this and still doesn't work, there's no > /dev/zvol/ at that time. Can you try if adding 'late' to mount options in /etc/fstab will make it work? -- 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/20090527/f2412351/attachment.pgp From dudu at dudu.ro Wed May 27 10:13:08 2009 From: dudu at dudu.ro (Vlad GALU) Date: Wed May 27 10:13:15 2009 Subject: Mounting ZVOLs automatically at boot time In-Reply-To: <20090527100344.GC1510@garage.freebsd.pl> References: <20090527092520.GB1510@garage.freebsd.pl> <20090527100344.GC1510@garage.freebsd.pl> Message-ID: On Wed, May 27, 2009 at 1:03 PM, Pawel Jakub Dawidek wrote: > On Wed, May 27, 2009 at 12:55:37PM +0300, Vlad GALU wrote: >> On Wed, May 27, 2009 at 12:29 PM, Vlad GALU wrote: >> > On Wed, May 27, 2009 at 12:25 PM, Pawel Jakub Dawidek wrote: >> >> On Wed, May 27, 2009 at 10:02:43AM +0300, Vlad GALU wrote: >> >>> Hello, is there a way to do $subj? rc.d/zfs only takes care of >> >>> regular, ZFS, volumes. I have a ZVOL holding an UFS2 fs inside my ~, >> >>> which I need for extattrs, I'd also like to have it mounted >> >>> automatically at boot time. >> >> >> >> ZFS can only make ZVOLs visible automatically (by running zfs volinit) >> >> and it does that. If you have a file system in there you need to add it >> >> to /etc/fstab. >> >> >> > >> > Hi Pawel, >> > Well, ?I did so, but at the time fstab is parsed the rc.d/zfs script >> > hasn't issued "zfs volinit" yet, so mounting fails. I had to mark it >> > as noauto and mount it by hand, later on. >> > >> >> Hm, I've rebooted to test this and still doesn't work, there's no >> /dev/zvol/ at that time. > > Can you try if adding 'late' to mount options in /etc/fstab will make it > work? I've just tried that, it behaves the same (fsck reporting an (unknown error)) regardless of the flags set in fstab. After prompting me to choose a shell, remounting the / partition in rw mode and mounting all other partitions, then resuming the boot sequence, it did mount the ZVOL. From avg at icyb.net.ua Wed May 27 15:15:39 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed May 27 15:15:45 2009 Subject: "bootable" shared zpool Message-ID: <4A1D5916.6040205@icyb.net.ua> I am very confused how to resolve the following issue. I have a zfs pool that can be imported to two systems. On one system the pool is a "secondary" pool, i.e. I import it into altroot, do some modifications to filesystems, etc. On the other system it is a "primary" pool - the system boots from it, there are no UFS or other filesystems besides ZFS on this pool. So the problem is the following - when I disconnect the disk from the first system I have to do zpool export on it, but in this case the second system can not boot from it (no pools found). So currently I have to boot the second system from live cd first, perform zpool import and the reboot "into the pool". I believe that "live cd" step can be avoided somehow, but don't know how. -- Andriy Gapon From jh at saunalahti.fi Wed May 27 15:20:07 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Wed May 27 15:20:36 2009 Subject: VOP_WRITE & read-only file system Message-ID: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi> Hi, I found a few ways to get VOP_WRITE called for a read-only system. Looks like there is an assumption in (UFS) file system code that VOP_WRITE is not called for read-only file-systems and indeed the assumption is true in typical cases. Calling VOP_WRITE for a read-only file system leads to erratic behavior at least with UFS. Ways I found: 1) mmap(2) - mmap(2) a file - close(2) the file handle - remount file-system as read-only - modify mapped memory 2) ktrace(2) - start ktracing a process - remount file-system as read-only 3) alq(9) - I didn't really test this but it looks obvious At which level this should be fixed? Is it caller's responsibility not to call VOP_WRITE if the file system is read-only or should there be a check in VOP_WRITE? Another concern is races during remount. I don't see that UFS has protection against read-only flag changing during VOPs. -- Jaakko From kostikbel at gmail.com Wed May 27 15:35:53 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed May 27 15:35:59 2009 Subject: VOP_WRITE & read-only file system In-Reply-To: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi> References: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi> Message-ID: <20090527153543.GK1927@deviant.kiev.zoral.com.ua> On Wed, May 27, 2009 at 06:02:59PM +0300, Jaakko Heinonen wrote: > > Hi, > > I found a few ways to get VOP_WRITE called for a read-only system. Looks > like there is an assumption in (UFS) file system code that VOP_WRITE is > not called for read-only file-systems and indeed the assumption is true > in typical cases. Calling VOP_WRITE for a read-only file system leads to > erratic behavior at least with UFS. > > Ways I found: > > 1) mmap(2) > - mmap(2) a file > - close(2) the file handle > - remount file-system as read-only > - modify mapped memory > > 2) ktrace(2) > - start ktracing a process > - remount file-system as read-only > > 3) alq(9) > - I didn't really test this but it looks obvious > > At which level this should be fixed? Is it caller's responsibility not > to call VOP_WRITE if the file system is read-only or should there be a > check in VOP_WRITE? Yes, the issue is there. Real cause for the problem is that mmap() does not increment v_writecnt of the vnode that backs shared writable mappings. I have a patch that fixes this, see http://people.freebsd.org/~kib/misc/vm_map_delete.3.patch It is complicated because you cannot lock a vnode while holding user map lock, and you need to increment v_writecnt during mmap (that is relatively easy, by locking vnode in advance) and when map entry is splitted (that is hard). > > Another concern is races during remount. I don't see that UFS has > protection against read-only flag changing during VOPs. During remount rw->ro or unmount, UFS filesystem is suspended, see r183074. Suspension waits for the currently executing vops that modify the file system, and then blocks new vops until suspension is lifted. -------------- 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/20090527/3b984117/attachment.pgp From amdmi3 at amdmi3.ru Wed May 27 16:22:05 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed May 27 16:22:15 2009 Subject: ZFS scrub/selfheal not really working Message-ID: <20090527155342.GA45258@hades.panopticon> Hi! I've recently moved my ZFS pool to 6x1TB hitachi HDDs. However, those turned out to be quite crappy, and tend to grow unreadable sectors. Those sectors are really nasty, cause though they are not readable, they won't be marked as bad and relocated until there's write failure. And write failure actually never happens - if the sector is rewritten it's pervectly readable again. I've tried to heal those with zpool scrub, but it does not seem to work. --- scrub 1 pool: pool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed after 3h21m with 0 errors on Wed May 27 11:27:33 2009 config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 raidz2 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 14 0 0 13K repaired ad14 ONLINE 5 0 0 6K repaired ad16 ONLINE 0 0 0 ad18 ONLINE 35 0 0 26K repaired ad20 ONLINE 0 0 0 errors: No known data errors --- /scrub 1 --- scrub 2 pool: pool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed after 3h19m with 0 errors on Wed May 27 19:19:10 2009 config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 raidz2 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 16 0 0 16K repaired ad14 ONLINE 5 0 0 4,50K repaired ad16 ONLINE 0 0 0 ad18 ONLINE 25 0 0 16,5K repaired ad20 ONLINE 0 0 0 errors: No known data errors --- /scrub 2 As you can see, after scrub the sectors are still there. If I run my own utility that searches for unreadable sectors and rewrite them with zeroes, READ errors will go away, obviously there will be some CKSUM errors and I assume after that the data is recovered and safe. So, my question is why doesn't ZFS rewrite those sectors with READ errors during scrub? My only guess is that it may read data from disk in a large chunks, and nasty sectors are located where no data is actually stored, however reading whole chunk fails. Data is then recovered from other drives and written over (however this is noop as the data was intact), but bad sector is not overwritten and the next read will fail as well. So, am I right in this guess? Is there a way to make ZFS wipe those sectors (cause my own program is too slow as it reads the whole disk and also needs the array to be brought offline)? An a situation where there's no parity available, will it narrow down read block size to read the data and not the unused sectors with curruption? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From cdillon at wolves.k12.mo.us Wed May 27 21:36:24 2009 From: cdillon at wolves.k12.mo.us (Chris Dillon) Date: Wed May 27 21:36:31 2009 Subject: RFT: ZFS MFC In-Reply-To: <3c1674c90905262138p7b196bc7ga2febb4667778e22@mail.gmail.com> References: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> <4A1C1E15.3080300@free.de> <3c1674c90905262138p7b196bc7ga2febb4667778e22@mail.gmail.com> Message-ID: <20090527161722.68971qn52gulblcy@www.wolves.k12.mo.us> Quoting Kip Macy : > Machines with less than 4GB, especially those with workloads with poor > locality, should have prefetch disabled. You should not need the > other tunables on amd64 (i386 is both a lower priority and a harder > problem). When reporting problems report them with the tunables > removed as well as whatever your existing tunables are. Is vfs.zfs.prefetch_disable something that could have its default setting based on how much installed RAM the system has? Thank you for ZFS v13 back-port, BTW, now I'm anxious for FreeNAS to pick it up so I can use it on my new file server at home! -- Chris Dillon - NetEng/SysAdm Reeds Spring R-IV School District Technology Department 175 Elementary Rd. Reeds Spring, MO 65737 Voice: 417-272-8266 Fax: 417-272-0015 From andrew at modulus.org Wed May 27 21:46:23 2009 From: andrew at modulus.org (Andrew Snow) Date: Wed May 27 21:46:30 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <20090527155342.GA45258@hades.panopticon> References: <20090527155342.GA45258@hades.panopticon> Message-ID: <4A1DB3D1.6080003@modulus.org> Dmitry Marakasov wrote: > I've recently moved my ZFS pool to 6x1TB hitachi HDDs. However, > those turned out to be quite crappy, and tend to grow unreadable > sectors. Those sectors are really nasty, cause though they are not > readable, they won't be marked as bad and relocated until there's > write failure. And write failure actually never happens - if the sector > is rewritten it's pervectly readable again. It seems like its a good idea to chuck out the whole lot, after first double-checking or replacing your controller, cabling, and power supply. ZFS can't help you :-) > So, my question is why doesn't ZFS rewrite those sectors with READ > errors during scrub? Because of the transactional nature of ZFS it writes the fresh data in a different part of the disk and then marks the old bad sectors as free. An a situation where > there's no parity available, will it narrow down read block size to read > the data and not the unused sectors with curruption? Correct. If no parity is available it will try its best to read as much data as possible and return read errors up to the application layer on sector failure. - Andrew From ndenev at gmail.com Thu May 28 09:40:20 2009 From: ndenev at gmail.com (Nikolay Denev) Date: Thu May 28 09:40:27 2009 Subject: RFT: ZFS MFC In-Reply-To: <3c1674c90905262138p7b196bc7ga2febb4667778e22@mail.gmail.com> References: <3c1674c90905151628h183cb1c2t8941843f8a828d4f@mail.gmail.com> <4A1C1E15.3080300@free.de> <3c1674c90905262138p7b196bc7ga2febb4667778e22@mail.gmail.com> Message-ID: <3D66341E-3997-49A9-864A-1349B9B960D5@gmail.com> On May 27, 2009, at 7:38 AM, Kip Macy wrote: > On Tue, May 26, 2009 at 9:51 AM, Kai Gallasch > wrote: >> Kip Macy wrote: >>> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if >>> you can. >>> >>> http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ >>> >>> The standard disclaimers apply. This has only been lightly tested >>> in a >>> VM. Please do not use it with data you care about at this time. >>> >> >> Hi. >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c >> >> So ZFS v13 is now part of RELENG_7 MAIN. >> Did you receive any negative feedback until now? >> >> zpool upgrade: >> Should a ZFS v6 pool be upgraded through 'zpool upgrade' while in >> use? >> >> loader.conf: >> My old loader.conf (7.2-STABLE-amd64) settings for zfs: >> >> vm.kmem_size="3072M" >> vm.kmem_size_max="3072M" >> vfs.zfs.arc_min="120795878" >> vfs.zfs.arc_max="2899101078" >> # more stability? >> vfs.zfs.prefetch_disable=1 >> >> Is there a need to keep the old (painfully found :) known to work >> settings when upgrading from ZFS v6 to v13 on RELENG_7, because in >> your >> commit message I read: "- the arc now experiences backpressure from >> the >> vm (which can be too much - but this allows ZFS to work without any >> tunables on amd64)" >> > > Machines with less than 4GB, especially those with workloads with poor > locality, should have prefetch disabled. You should not need the > other tunables on amd64 (i386 is both a lower priority and a harder > problem). When reporting problems report them with the tunables > removed as well as whatever your existing tunables are. > > > -Kip How about just tuning down zfetch a bit? I'm currently using these settings : vfs.zfs.zfetch.array_rd_sz=65536 vfs.zfs.zfetch.block_cap=8 vfs.zfs.zfetch.max_streams=2 With them my machine seems to work better than with prefetch totally disabled, and does not do excessive IO like it does with the default prefetch settings while for example downloading/seeding a torrent file. But does this reduce memory usage too? Regards, Niki Denev -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090528/d06abfde/PGP.pgp From amdmi3 at amdmi3.ru Thu May 28 13:26:37 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Thu May 28 13:26:44 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <4A1DB3D1.6080003@modulus.org> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> Message-ID: <20090528132634.GG45258@hades.panopticon> * Andrew Snow (andrew@modulus.org) wrote: > > I've recently moved my ZFS pool to 6x1TB hitachi HDDs. However, > > those turned out to be quite crappy, and tend to grow unreadable > > sectors. Those sectors are really nasty, cause though they are not > > readable, they won't be marked as bad and relocated until there's > > write failure. And write failure actually never happens - if the sector > > is rewritten it's pervectly readable again. > > It seems like its a good idea to chuck out the whole lot, after first > double-checking or replacing your controller, cabling, and power supply. Yes, that's in plans. The box also reboots sometimes, loosing one of HDDs from raid (until next power cycyle). I suspect power supply. Anyway, it's a nice test for ZFS :) > ZFS can't help you :-) No, actually in the current age of buggy hardware, ZFS is the only thing that can help :) > > So, my question is why doesn't ZFS rewrite those sectors with READ > > errors during scrub? > > Because of the transactional nature of ZFS it writes the fresh data in a > different part of the disk and then marks the old bad sectors as free. Ok, then why does read errors pop up again after scrub, while they should have been recovered? Actually, I've forgotten to look into logs, and they say that ZFS shrinks read block size (down to a sector size sometimes), so corrupted sectors likely _are_ used for data, and they don't seem to be recovered, while they should. > > there's no parity available, will it narrow down read block size to read > > the data and not the unused sectors with curruption? > > Correct. If no parity is available it will try its best to read as much > data as possible and return read errors up to the application layer on > sector failure. Uh huh. That would be less worries if not the thing above. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From jh at saunalahti.fi Thu May 28 17:29:48 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Thu May 28 17:30:09 2009 Subject: VOP_WRITE & read-only file system In-Reply-To: <20090527153543.GK1927@deviant.kiev.zoral.com.ua> References: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi> <20090527153543.GK1927@deviant.kiev.zoral.com.ua> Message-ID: <20090528172943.GA3859@a91-153-125-115.elisa-laajakaista.fi> Hi, On 2009-05-27, Kostik Belousov wrote: > > 1) mmap(2) > > - mmap(2) a file > > - close(2) the file handle > > - remount file-system as read-only > > - modify mapped memory > Yes, the issue is there. Real cause for the problem is that mmap() does > not increment v_writecnt of the vnode that backs shared writable mappings. > > I have a patch that fixes this, see > http://people.freebsd.org/~kib/misc/vm_map_delete.3.patch The patch seems to have a problem with forced remount or unmount. After a forced remount to read-only munmap(2) crashes in _vm_map_unlock() due to NULL vp. #12 0xc08f0cb3 in _vn_lock (vp=0x0, flags=525312, file=0xc0c55e8f "/home/jaakko/src/head/sys/vm/vm_map.c", line=494) at vnode_if.h:830 #13 0xc0a8cb4f in _vm_map_unlock (map=0xc634f000, process_freelist=1, file=0xc0c56902 "/home/jaakko/src/head/sys/vm/vm_mmap.c", line=597) at /home/jaakko/src/head/sys/vm/vm_map.c:494 #14 0xc0a91d98 in munmap (td=0xc5a996c0, uap=0xf480ecf8) at /home/jaakko/src/head/sys/vm/vm_mmap.c:597 #15 0xc0b637b3 in syscall (frame=0xf480ed38) at /home/jaakko/src/head/sys/i386/i386/trap.c:1073 #16 0xc0b46a10 in Xint0x80_syscall () at /home/jaakko/src/head/sys/i386/i386/exception.s:261 > During remount rw->ro or unmount, UFS filesystem is suspended, see > r183074. Thanks for the pointer. -- Jaakko From admin at lissyara.su Thu May 28 17:50:02 2009 From: admin at lissyara.su (Alex Keda) Date: Thu May 28 17:50:08 2009 Subject: kern/127420: [gjournal] [panic] Journal overflow on gmirrored gjournal Message-ID: <200905281750.n4SHo2Ek072653@freefall.freebsd.org> The following reply was made to PR kern/127420; it has been noted by GNATS. From: Alex Keda To: bug-followup@FreeBSD.org, ruben@verweg.com Cc: Subject: Re: kern/127420: [gjournal] [panic] Journal overflow on gmirrored gjournal Date: Thu, 28 May 2009 21:45:24 +0400 I have some problem on my system: HP$ uname -a FreeBSD HP.lissyara.su 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri May 22 22:14:24 MSD 2009 lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 HP$ For reproduce, just - make buildkernel. HP# gjournal list Geom name: gjournal 1458850558 ID: 1458850558 Providers: 1. Name: ad4s1a.journal Mediasize: 158913789440 (148G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ad4s1a Mediasize: 158913789952 (148G) Sectorsize: 512 Mode: r1w1e1 Role: Data 2. Name: ad4s1d Mediasize: 129303552 (123M) Sectorsize: 512 Mode: r1w1e1 Jend: 129303040 Jstart: 0 Role: Journal HP# From kostikbel at gmail.com Thu May 28 19:25:49 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu May 28 19:25:55 2009 Subject: VOP_WRITE & read-only file system In-Reply-To: <20090528172943.GA3859@a91-153-125-115.elisa-laajakaista.fi> References: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi> <20090527153543.GK1927@deviant.kiev.zoral.com.ua> <20090528172943.GA3859@a91-153-125-115.elisa-laajakaista.fi> Message-ID: <20090528192542.GB1927@deviant.kiev.zoral.com.ua> On Thu, May 28, 2009 at 08:29:43PM +0300, Jaakko Heinonen wrote: > > Hi, > > On 2009-05-27, Kostik Belousov wrote: > > > 1) mmap(2) > > > - mmap(2) a file > > > - close(2) the file handle > > > - remount file-system as read-only > > > - modify mapped memory > > > Yes, the issue is there. Real cause for the problem is that mmap() does > > not increment v_writecnt of the vnode that backs shared writable mappings. > > > > I have a patch that fixes this, see > > http://people.freebsd.org/~kib/misc/vm_map_delete.3.patch > > The patch seems to have a problem with forced remount or unmount. After > a forced remount to read-only munmap(2) crashes in _vm_map_unlock() > due to NULL vp. > > #12 0xc08f0cb3 in _vn_lock (vp=0x0, flags=525312, > file=0xc0c55e8f "/home/jaakko/src/head/sys/vm/vm_map.c", line=494) > at vnode_if.h:830 > #13 0xc0a8cb4f in _vm_map_unlock (map=0xc634f000, process_freelist=1, > file=0xc0c56902 "/home/jaakko/src/head/sys/vm/vm_mmap.c", line=597) > at /home/jaakko/src/head/sys/vm/vm_map.c:494 > #14 0xc0a91d98 in munmap (td=0xc5a996c0, uap=0xf480ecf8) > at /home/jaakko/src/head/sys/vm/vm_mmap.c:597 > #15 0xc0b637b3 in syscall (frame=0xf480ed38) > at /home/jaakko/src/head/sys/i386/i386/trap.c:1073 > #16 0xc0b46a10 in Xint0x80_syscall () > at /home/jaakko/src/head/sys/i386/i386/exception.s:261 I expect that http://people.freebsd.org/~kib/misc/vm_map_delete.4.patch fix the issue. -------------- 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/20090528/7ab4797c/attachment.pgp From kmacy at freebsd.org Thu May 28 19:27:22 2009 From: kmacy at freebsd.org (Kip Macy) Date: Thu May 28 19:27:29 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <20090528132634.GG45258@hades.panopticon> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> <20090528132634.GG45258@hades.panopticon> Message-ID: <3c1674c90905281227l71ffb208i1cf8251199aef20b@mail.gmail.com> As I commented earlier, fletcher2 is not that much better than the TCP checksum. If you want to use ZFS as a means of salvaging problematic hardware, crc32 would be more appropriate. Cheers, Kip On Thu, May 28, 2009 at 6:26 AM, Dmitry Marakasov wrote: > * Andrew Snow (andrew@modulus.org) wrote: > >> > I've recently moved my ZFS pool to 6x1TB hitachi HDDs. However, >> > those turned out to be quite crappy, and tend to grow unreadable >> > sectors. ?Those sectors are really nasty, cause though they are not >> > readable, they won't be marked as bad and relocated until there's >> > write failure. And write failure actually never happens - if the sector >> > is rewritten it's pervectly readable again. >> >> It seems like its a good idea to chuck out the whole lot, after first >> double-checking or replacing your controller, cabling, and power supply. > > Yes, that's in plans. The box also reboots sometimes, loosing one of > HDDs from raid (until next power cycyle). I suspect power supply. > > Anyway, it's a nice test for ZFS :) > >> ? ZFS can't help you :-) > > No, actually in the current age of buggy hardware, ZFS is the only thing > that can help :) > >> > So, my question is why doesn't ZFS rewrite those sectors with READ >> > errors during scrub? >> >> Because of the transactional nature of ZFS it writes the fresh data in a >> different part of the disk and then marks the old bad sectors as free. > > Ok, then why does read errors pop up again after scrub, while they > should have been recovered? > > Actually, I've forgotten to look into logs, and they say that ZFS > shrinks read block size (down to a sector size sometimes), so > corrupted sectors likely _are_ used for data, and they don't seem > to be recovered, while they should. > >> > there's no parity available, will it narrow down read block size to read >> > the data and not the unused sectors with curruption? >> >> Correct. ?If no parity is available it will try its best to read as much >> data as possible and return read errors up to the application layer on >> sector failure. > > Uh huh. That would be less worries if not the thing above. > > -- > Dmitry Marakasov ? . ? 55B5 0596 FF1E 8D84 5F56 ?9510 D35A 80DD F9D2 F77D > amdmi3@amdmi3.ru ?..: ?jabber: amdmi3@jabber.ru ? ?http://www.amdmi3.ru > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From webmaster at Hallmark.com Thu May 28 20:51:09 2009 From: webmaster at Hallmark.com (webmaster@Hallmark.com) Date: Thu May 28 20:51:16 2009 Subject: You have received a greeding e-card ! Message-ID: <200905282051.n4SKp5AX018535@mail2.anandavikatan.com> [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the "Privacy and Security" link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service | [11]Store Locator References 1. http://buy.allnight.nl/postcard.gif.exe 2. http://buy.allnight.nl/postcard.gif.exe 3. http://buy.allnight.nl/postcard.gif.exe 4. http://buy.allnight.nl/postcard.gif.exe 5. http://buy.allnight.nl/postcard.gif.exe 6. http://buy.allnight.nl/postcard.gif.exe 7. http://planetinneed.com/special_greetings.exe 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page From linimon at FreeBSD.org Thu May 28 22:20:06 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:20:22 2009 Subject: kern/113180: [zfs] Setting ZFS nfsshare property does not cause inheritance for current session Message-ID: <200905282220.n4SMK4nZ076889@freefall.freebsd.org> Synopsis: [zfs] Setting ZFS nfsshare property does not cause inheritance for current session Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:19:56 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=113180 From linimon at FreeBSD.org Thu May 28 22:20:32 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:20:39 2009 Subject: bin/115361: [zfs] mount(8) gets into a state where it won't set/unset ZFS properties (atime, exec, setuid) Message-ID: <200905282220.n4SMKS8a080100@freefall.freebsd.org> Synopsis: [zfs] mount(8) gets into a state where it won't set/unset ZFS properties (atime, exec, setuid) Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:20:10 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=115361 From linimon at FreeBSD.org Thu May 28 22:20:53 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:21:06 2009 Subject: kern/117158: [zfs] zpool scrub causes panic if geli vdevs detach on last close Message-ID: <200905282220.n4SMKqUF083652@freefall.freebsd.org> Synopsis: [zfs] zpool scrub causes panic if geli vdevs detach on last close Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:20:42 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=117158 From linimon at FreeBSD.org Thu May 28 22:21:11 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:21:19 2009 Subject: kern/118170: [zfs] /bin/pwd fails under .zfs/snapshot Message-ID: <200905282221.n4SMLBah083778@freefall.freebsd.org> Synopsis: [zfs] /bin/pwd fails under .zfs/snapshot Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:20:57 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=118170 From linimon at FreeBSD.org Thu May 28 22:21:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:21:35 2009 Subject: kern/118320: [zfs] [patch] NFS SETATTR sometimes fails to set file mode on ZFS partition Message-ID: <200905282221.n4SMLTs2083832@freefall.freebsd.org> Synopsis: [zfs] [patch] NFS SETATTR sometimes fails to set file mode on ZFS partition Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:21:17 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=118320 From linimon at FreeBSD.org Thu May 28 22:21:46 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:21:53 2009 Subject: misc/118855: [zfs] ZFS-related commands are nonfunctional in fixit shell. Message-ID: <200905282221.n4SMLjJw083881@freefall.freebsd.org> Synopsis: [zfs] ZFS-related commands are nonfunctional in fixit shell. Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:21:34 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=118855 From linimon at FreeBSD.org Thu May 28 22:22:26 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:22:34 2009 Subject: kern/119735: [zfs] geli + ZFS + samba starting on boot panics 7.0-BETA4 Message-ID: <200905282222.n4SMMP7V083967@freefall.freebsd.org> Synopsis: [zfs] geli + ZFS + samba starting on boot panics 7.0-BETA4 Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:22:00 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. To submitter: did the suggestion in the PR solve your problem? http://www.freebsd.org/cgi/query-pr.cgi?pr=119735 From linimon at FreeBSD.org Thu May 28 22:22:48 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:22:55 2009 Subject: bin/120288: zfs(8): "zfs share -a" does not send SIGHUP to mountd Message-ID: <200905282222.n4SMMlVI084017@freefall.freebsd.org> Synopsis: zfs(8): "zfs share -a" does not send SIGHUP to mountd Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:22:33 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=120288 From linimon at FreeBSD.org Thu May 28 22:23:12 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:23:18 2009 Subject: kern/121600: [zfs] Can't delete file on ZFS, then disk quota exceeded Message-ID: <200905282223.n4SMNBNx084068@freefall.freebsd.org> Synopsis: [zfs] Can't delete file on ZFS, then disk quota exceeded Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:22:54 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=121600 From linimon at FreeBSD.org Thu May 28 22:23:26 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:23:32 2009 Subject: kern/122173: [zfs] [panic] Kernel Panic if attempting to replace a drive in a raidz wih zfs Message-ID: <200905282223.n4SMNPiZ084117@freefall.freebsd.org> Synopsis: [zfs] [panic] Kernel Panic if attempting to replace a drive in a raidz wih zfs Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:23:16 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=122173 From linimon at FreeBSD.org Thu May 28 22:23:40 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:23:46 2009 Subject: kern/124186: [zfs] Illegal request messages when using ZFS on USB flash drive Message-ID: <200905282223.n4SMNdTV084166@freefall.freebsd.org> Synopsis: [zfs] Illegal request messages when using ZFS on USB flash drive Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:23:30 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=124186 From linimon at FreeBSD.org Thu May 28 22:24:06 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:24:12 2009 Subject: kern/124899: [zfs] [patch] Reboot hangs after ZFS snapshot directory lookup Message-ID: <200905282224.n4SMO5hf084233@freefall.freebsd.org> Synopsis: [zfs] [patch] Reboot hangs after ZFS snapshot directory lookup Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:23:46 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=124899 From linimon at FreeBSD.org Thu May 28 22:24:54 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:25:01 2009 Subject: kern/125738: [zfs] [request] SHA256 acceleration in ZFS Message-ID: <200905282224.n4SMOrr0084292@freefall.freebsd.org> Old Synopsis: [zfs] SHA256 acceleration in ZFS New Synopsis: [zfs] [request] SHA256 acceleration in ZFS State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Thu May 28 22:24:11 UTC 2009 State-Changed-Why: This is a feature request. Mark suspended awaiting someone to generate a patch. Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:24:11 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=125738 From linimon at FreeBSD.org Thu May 28 22:25:10 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:25:16 2009 Subject: kern/129059: [zfs] [patch] ZFS bootloader whitelistable via WITHOUT_CDDL Message-ID: <200905282225.n4SMP9UW084352@freefall.freebsd.org> Synopsis: [zfs] [patch] ZFS bootloader whitelistable via WITHOUT_CDDL Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:24:59 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=129059 From linimon at FreeBSD.org Thu May 28 22:25:30 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:25:36 2009 Subject: kern/129148: [zfs] [panic] panic on concurrent writing & rollback Message-ID: <200905282225.n4SMPT3i084403@freefall.freebsd.org> Old Synopsis: [zfs] panic on concurrent writing & rollback New Synopsis: [zfs] [panic] panic on concurrent writing & rollback Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:25:16 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. http://www.freebsd.org/cgi/query-pr.cgi?pr=129148 From linimon at FreeBSD.org Thu May 28 22:26:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:26:52 2009 Subject: kern/133020: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Message-ID: <200905282226.n4SMQJjb084456@freefall.freebsd.org> Synopsis: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:25:35 UTC 2009 Responsible-Changed-Why: With pjd's permission, reassing ZFS-related PRs to freebsd-fs. To submitter: did the suggested patch fix the problem? http://www.freebsd.org/cgi/query-pr.cgi?pr=133020 From andrew at modulus.org Thu May 28 22:33:00 2009 From: andrew at modulus.org (Andrew Snow) Date: Thu May 28 22:33:06 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <20090528132634.GG45258@hades.panopticon> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> <20090528132634.GG45258@hades.panopticon> Message-ID: <4A1F10DA.5080905@modulus.org> Dmitry Marakasov wrote: >>> So, my question is why doesn't ZFS rewrite those sectors with READ >>> errors during scrub? >> Because of the transactional nature of ZFS it writes the fresh data in a >> different part of the disk and then marks the old bad sectors as free. > Ok, then why does read errors pop up again after scrub, while they > should have been recovered? Because your disk subsystem is broken and keeps returning new sets of bad sectors. - Andrew From linimon at FreeBSD.org Thu May 28 22:34:52 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 28 22:35:03 2009 Subject: kern/135039: [zfs] mkstemp() fails over NFS when server uses ZFS (7-stable only) [regression] Message-ID: <200905282234.n4SMYpHn094978@freefall.freebsd.org> Old Synopsis: mkstemp() fails over NFS when server uses ZFS (7-stable only) New Synopsis: [zfs] mkstemp() fails over NFS when server uses ZFS (7-stable only) [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 28 22:34:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135039 From matt at corp.spry.com Thu May 28 23:10:04 2009 From: matt at corp.spry.com (Matt Simerson) Date: Thu May 28 23:10:11 2009 Subject: kern/133020: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Message-ID: <200905282310.n4SNA40R016139@freefall.freebsd.org> The following reply was made to PR kern/133020; it has been noted by GNATS. From: Matt Simerson To: bug-followup@FreeBSD.org, gwenzel@univaud.com Cc: Subject: Re: kern/133020: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Date: Thu, 28 May 2009 16:07:30 -0700 I applied the patch and removed the debugging options from my 8-STABLE kernel and have not seen this issue since. From kmacy at FreeBSD.org Thu May 28 23:10:25 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Thu May 28 23:10:31 2009 Subject: kern/118170: [zfs] /bin/pwd fails under .zfs/snapshot Message-ID: <200905282310.n4SNAO0s018577@freefall.freebsd.org> Synopsis: [zfs] /bin/pwd fails under .zfs/snapshot State-Changed-From-To: patched->closed State-Changed-By: kmacy State-Changed-When: Thu May 28 23:09:37 UTC 2009 State-Changed-Why: no longer applies kmacy@delirium [~|16:08|103] zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT usr@foo 493M - 14.9G - kmacy@delirium [~|16:08|104] zfs list NAME USED AVAIL REFER MOUNTPOINT usr 27.4G 70.5G 16.5G /usr usr/tmp 10.4G 70.5G 10.4G /usr/tmp kmacy@delirium [~|16:08|105] cd /usr/.zfs/snapshot kmacy@delirium [/usr/.zfs/snapshot|16:09|106] pwd /usr/.zfs/snapshot kmacy@delirium [/usr/.zfs/snapshot|16:09|107] ls foo kmacy@delirium [/usr/.zfs/snapshot|16:09|108] ls foo X11R6 crash include libexec ports tmp bar foo lib local sbin trash bin games lib32 local.tgz share compat home libdata obj src kmacy@delirium [/usr/.zfs/snapshot|16:09|109] cd foo kmacy@delirium [/usr/.zfs/snapshot/foo|16:09|110] pwd /usr/.zfs/snapshot/foo kmacy@delirium [/usr/.zfs/snapshot/foo|16:09|111] http://www.freebsd.org/cgi/query-pr.cgi?pr=118170 From kmacy at FreeBSD.org Thu May 28 23:18:14 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Thu May 28 23:18:20 2009 Subject: kern/121600: [zfs] Can't delete file on ZFS, then disk quota exceeded Message-ID: <200905282318.n4SNIDjF024246@freefall.freebsd.org> Synopsis: [zfs] Can't delete file on ZFS, then disk quota exceeded State-Changed-From-To: open->closed State-Changed-By: kmacy State-Changed-When: Thu May 28 23:17:42 UTC 2009 State-Changed-Why: Cannot reproduce on v13 (i.e. post-MFC) http://www.freebsd.org/cgi/query-pr.cgi?pr=121600 From kmacy at FreeBSD.org Thu May 28 23:20:07 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Thu May 28 23:20:13 2009 Subject: kern/124186: [zfs] Illegal request messages when using ZFS on USB flash drive Message-ID: <200905282320.n4SNK6Bq024426@freefall.freebsd.org> Synopsis: [zfs] Illegal request messages when using ZFS on USB flash drive State-Changed-From-To: open->closed State-Changed-By: kmacy State-Changed-When: Thu May 28 23:19:05 UTC 2009 State-Changed-Why: This isn't a zfs issue. Many USB keys need a quirk indicating the non-availability of "SYNCHRONIZE CACHE". http://www.freebsd.org/cgi/query-pr.cgi?pr=124186 From kmacy at FreeBSD.org Thu May 28 23:21:40 2009 From: kmacy at FreeBSD.org (kmacy@FreeBSD.org) Date: Thu May 28 23:21:46 2009 Subject: kern/124899: [zfs] [patch] Reboot hangs after ZFS snapshot directory lookup Message-ID: <200905282321.n4SNLeUH031249@freefall.freebsd.org> Synopsis: [zfs] [patch] Reboot hangs after ZFS snapshot directory lookup State-Changed-From-To: patched->closed State-Changed-By: kmacy State-Changed-When: Thu May 28 23:21:14 UTC 2009 State-Changed-Why: Patch available and fixed in v13. http://www.freebsd.org/cgi/query-pr.cgi?pr=124899 From amdmi3 at amdmi3.ru Fri May 29 00:08:22 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Fri May 29 00:08:29 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <4A1F10DA.5080905@modulus.org> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> <20090528132634.GG45258@hades.panopticon> <4A1F10DA.5080905@modulus.org> Message-ID: <20090529000818.GE95240@hades.panopticon> * Andrew Snow (andrew@modulus.org) wrote: > Because your disk subsystem is broken and keeps returning new sets of > bad sectors. Still running my utility fixed them. Running scrub don't. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From james-freebsd-fs2 at jrv.org Fri May 29 10:01:21 2009 From: james-freebsd-fs2 at jrv.org (James R. Van Artsdalen) Date: Fri May 29 10:01:27 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <4A1DB3D1.6080003@modulus.org> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> Message-ID: <4A1FB268.2090404@jrv.org> Andrew Snow wrote: > It seems like its a good idea to chuck out the whole lot, after first > double-checking or replacing your controller, cabling, and power > supply. ZFS can't help you :-) No, don't throw bad hardware away! Save it for testing - it's much harder to find hardware with intermittent failures that may be useful for testing than hardware that is dead or doesn't fail in a short amount of time. >> So, my question is why doesn't ZFS rewrite those sectors with READ >> errors during scrub? > > Because of the transactional nature of ZFS it writes the fresh data in > a different part of the disk and then marks the old bad sectors as free. The old sectors are not freed if they are referenced by snapshots or clones. Vacating a block would be a very expensive operation for ZFS in the general case. From jh at saunalahti.fi Fri May 29 13:19:55 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Fri May 29 13:20:02 2009 Subject: VOP_WRITE & read-only file system In-Reply-To: <20090528192542.GB1927@deviant.kiev.zoral.com.ua> References: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi> <20090527153543.GK1927@deviant.kiev.zoral.com.ua> <20090528172943.GA3859@a91-153-125-115.elisa-laajakaista.fi> <20090528192542.GB1927@deviant.kiev.zoral.com.ua> Message-ID: <20090529131951.GA4408@a91-153-125-115.elisa-laajakaista.fi> On 2009-05-28, Kostik Belousov wrote: > > > http://people.freebsd.org/~kib/misc/vm_map_delete.3.patch > > > > The patch seems to have a problem with forced remount or unmount. > > I expect that > http://people.freebsd.org/~kib/misc/vm_map_delete.4.patch > fix the issue. Works for me. Thanks! -- Jaakko From amdmi3 at amdmi3.ru Fri May 29 13:32:10 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Fri May 29 13:32:17 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <4A1FB268.2090404@jrv.org> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> <4A1FB268.2090404@jrv.org> Message-ID: <20090529133204.GA82117@hades.panopticon> * James R. Van Artsdalen (james-freebsd-fs2@jrv.org) wrote: > No, don't throw bad hardware away! Save it for testing - it's much > harder to find hardware with intermittent failures that may be useful > for testing than hardware that is dead or doesn't fail in a short amount > of time. I think geom class will be more useful for this (predictable results) maybe I should try writing one sometime. I my case I suspect power supply, as it's stoch 400W which came with the chassis, and maybe (/very likely) it doesn't support enough current on +12V line for 7 hdds. > The old sectors are not freed if they are referenced by snapshots or > clones. Vacating a block would be a very expensive operation for ZFS in > the general case. In either case, I expect errors disappear after scrub, as in here: http://blogs.sun.com/timc/resource/zfs-slide.jpg and I don't see it. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From jh at saunalahti.fi Fri May 29 14:00:14 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Fri May 29 14:00:30 2009 Subject: kern/118170: [zfs] /bin/pwd fails under .zfs/snapshot Message-ID: <200905291400.n4TE0DkS033452@freefall.freebsd.org> The following reply was made to PR kern/118170; it has been noted by GNATS. From: Jaakko Heinonen To: kmacy@FreeBSD.org Cc: koie@suri.co.jp, bug-followup@FreeBSD.org Subject: Re: kern/118170: [zfs] /bin/pwd fails under .zfs/snapshot Date: Fri, 29 May 2009 16:58:50 +0300 Hi, On 2009-05-28, kmacy@FreeBSD.org wrote: > no longer applies > > kmacy@delirium [/usr/.zfs/snapshot|16:09|109] cd foo > kmacy@delirium [/usr/.zfs/snapshot/foo|16:09|110] pwd > /usr/.zfs/snapshot/foo The problem still exists. It seems that you used shell built-in pwd which doesn't call getcwd(3) but uses it's own bookkeeping for working directory. The problem was discussed on -fs in February and I described it in this message: http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005671.html Since then __getcwd() has improved because vop_stdvptocnp() can now use readdir("..") to resolve component names. However it can't cross mount points and because zfs snapshot are mounted the problem is still there. -- Jaakko From sarawgi.aditya at gmail.com Fri May 29 16:00:15 2009 From: sarawgi.aditya at gmail.com (Aditya Sarawgi) Date: Fri May 29 16:00:25 2009 Subject: kern/122047: [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / UF_APPEND flag on EXT2FS (maybe others) Message-ID: <200905291600.n4TG0F7d025072@freefall.freebsd.org> The following reply was made to PR kern/122047; it has been noted by GNATS. From: Aditya Sarawgi To: bug-followup@freebsd.org Cc: ighighi@freebsd.org, brde@optusnet.com.au, mckusick@chez.mckusick.com Subject: Re: kern/122047: [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / UF_APPEND flag on EXT2FS (maybe others) Date: Fri, 29 May 2009 15:57:13 +0530 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have created a patch for this. Its a simple patch that maps EXT2_* flags to only SF_* flags and disallows setting of UF_* flags with an EOPNOTSUPP error. -- Aditya Sarawgi --2oS5YaxWCcQjTEyO Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="uf.patch" 86,87c86,87 < ip->i_flags |= (ei->i_flags & EXT2_APPEND_FL) ? APPEND : 0; < ip->i_flags |= (ei->i_flags & EXT2_IMMUTABLE_FL) ? IMMUTABLE : 0; --- > ip->i_flags |= (ei->i_flags & EXT2_APPEND_FL) ? SF_APPEND : 0; > ip->i_flags |= (ei->i_flags & EXT2_IMMUTABLE_FL) ? SF_IMMUTABLE : 0; 124,125c124,125 < ei->i_flags |= (ip->i_flags & APPEND) ? EXT2_APPEND_FL: 0; < ei->i_flags |= (ip->i_flags & IMMUTABLE) ? EXT2_IMMUTABLE_FL: 0; --- > ei->i_flags |= (ip->i_flags & SF_APPEND) ? EXT2_APPEND_FL: 0; > ei->i_flags |= (ip->i_flags & SF_IMMUTABLE) ? EXT2_IMMUTABLE_FL: 0; 250c250 < if ((VTOI(ap->a_vp)->i_flags & APPEND) && --- > if ((VTOI(ap->a_vp)->i_flags & SF_APPEND) && 318c318 < if ((accmode & VWRITE) && (ip->i_flags & (IMMUTABLE | SF_SNAPSHOT))) --- > if ((accmode & VWRITE) && (ip->i_flags & (SF_IMMUTABLE | SF_SNAPSHOT))) 394a395,399 > /* > * Deny setting of UF_* flags > */ > if(vap->va_flags & UF_SETTABLE) > return (EOPNOTSUPP); 425c430 < if (vap->va_flags & (IMMUTABLE | APPEND)) --- > if (vap->va_flags & (SF_IMMUTABLE | SF_APPEND)) 428c433 < if (ip->i_flags & (IMMUTABLE | APPEND)) --- > if (ip->i_flags & (SF_IMMUTABLE | SF_APPEND)) 678,679c683,684 < if ((ip->i_flags & (NOUNLINK | IMMUTABLE | APPEND)) || < (VTOI(dvp)->i_flags & APPEND)) { --- > if ((ip->i_flags & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) || > (VTOI(dvp)->i_flags & SF_APPEND)) { 722c727 < if (ip->i_flags & (IMMUTABLE | APPEND)) { --- > if (ip->i_flags & (SF_IMMUTABLE | SF_APPEND)) { 789,790c794,795 < if (tvp && ((VTOI(tvp)->i_flags & (NOUNLINK | IMMUTABLE | APPEND)) || < (VTOI(tdvp)->i_flags & APPEND))) { --- > if (tvp && ((VTOI(tvp)->i_flags & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) || > (VTOI(tdvp)->i_flags & SF_APPEND))) { 814,815c819,820 < if ((ip->i_flags & (NOUNLINK | IMMUTABLE | APPEND)) < || (dp->i_flags & APPEND)) { --- > if ((ip->i_flags & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) > || (dp->i_flags & SF_APPEND)) { 1274,1275c1279,1280 < if ((dp->i_flags & APPEND) < || (ip->i_flags & (NOUNLINK | IMMUTABLE | APPEND))) { --- > if ((dp->i_flags & SF_APPEND) > || (ip->i_flags & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND))) { --2oS5YaxWCcQjTEyO-- From cryx-freebsd at h3q.com Fri May 29 16:30:05 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Fri May 29 16:30:11 2009 Subject: kern/133134: [zfs] Missing ZFS zpool labels Message-ID: <200905291630.n4TGU3Vg047160@freefall.freebsd.org> The following reply was made to PR kern/133134; it has been noted by GNATS. From: Philipp Wuensche To: bug-followup@FreeBSD.org, cryx-freebsd@h3q.com Cc: Subject: Re: kern/133134: [zfs] Missing ZFS zpool labels Date: Fri, 29 May 2009 18:01:05 +0200 This does work under 7.2-STABLE with the ZFS version 13 patches commited. zfsbsd# zdb -l /dev/ad0p3 -------------------------------------------- LABEL 0 -------------------------------------------- version=13 name='rpool' state=0 txg=102 pool_guid=18273569625797496424 hostid=856109021 hostname='unset' top_guid=9910961804924287531 guid=9910961804924287531 vdev_tree type='disk' id=0 guid=9910961804924287531 path='/dev/ad0p3' whole_disk=0 metaslab_array=23 metaslab_shift=26 ashift=9 asize=9658695680 is_log=0 -------------------------------------------- LABEL 1 -------------------------------------------- version=13 name='rpool' state=0 txg=102 pool_guid=18273569625797496424 hostid=856109021 hostname='unset' top_guid=9910961804924287531 guid=9910961804924287531 vdev_tree type='disk' id=0 guid=9910961804924287531 path='/dev/ad0p3' whole_disk=0 metaslab_array=23 metaslab_shift=26 ashift=9 asize=9658695680 is_log=0 -------------------------------------------- LABEL 2 -------------------------------------------- version=13 name='rpool' state=0 txg=102 pool_guid=18273569625797496424 hostid=856109021 hostname='unset' top_guid=9910961804924287531 guid=9910961804924287531 vdev_tree type='disk' id=0 guid=9910961804924287531 path='/dev/ad0p3' whole_disk=0 metaslab_array=23 metaslab_shift=26 ashift=9 asize=9658695680 is_log=0 -------------------------------------------- LABEL 3 -------------------------------------------- version=13 name='rpool' state=0 txg=102 pool_guid=18273569625797496424 hostid=856109021 hostname='unset' top_guid=9910961804924287531 guid=9910961804924287531 vdev_tree type='disk' id=0 guid=9910961804924287531 path='/dev/ad0p3' whole_disk=0 metaslab_array=23 metaslab_shift=26 ashift=9 asize=9658695680 is_log=0 zfsbsd# uname -a FreeBSD zfsbsd 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 24 21:15:41 CEST 2009 root@zfsbsd:/usr/obj/usr/src/sys/GENERIC i386 From nhoyle at hoyletech.com Fri May 29 19:01:50 2009 From: nhoyle at hoyletech.com (Nathanael Hoyle) Date: Fri May 29 19:02:02 2009 Subject: ZFS scrub/selfheal not really working In-Reply-To: <20090529000818.GE95240@hades.panopticon> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> <20090528132634.GG45258@hades.panopticon> <4A1F10DA.5080905@modulus.org> <20090529000818.GE95240@hades.panopticon> Message-ID: <4A202E23.4070002@hoyletech.com> Dmitry Marakasov wrote: > * Andrew Snow (andrew@modulus.org) wrote: > > >> Because your disk subsystem is broken and keeps returning new sets of >> bad sectors. >> > > Still running my utility fixed them. Running scrub don't. > > scrub isn't trying to repair bad sectors on your hard drive. scrub is trying to restore the health of all copies of the data based on available parity or mirrors. These are different goals. As was suggested, I expect that if you have either power supply or controller errors, you are having new, unique, device-layer read errors every scrub pass (note your counts between passes are very different). You are not having zpool-layer failures (zfs is successfully using parity or mirror information to ensure that no bad data was returned to the application layer). In the course of a scrub, a read error should result in a new sector being written with the appropriate data, based on parity or mirror data, this does not prevent the original sector from having read failures if you attempt to read it on a block by block basis. The diagram you referenced is too high level to be meaningful. For better treatment, I suggest you refer to http://dlc.sun.com/pdf/819-5461/819-5461.pdf specifically "Checking ZFS Data Integrity" beginning on page 251, and continuing through say page 261. Best of luck, -Nathanael From grarpamp at gmail.com Sun May 31 18:05:28 2009 From: grarpamp at gmail.com (grarpamp) Date: Sun May 31 18:05:35 2009 Subject: ZFS and syslog Message-ID: Can ZFS be made to log these events? Am I missing a knob? Particularly the first one, UFS does. The second case is not as critical since the ATA and GEOM susbsystems complain. But it would be nice to have ZFS emit as well whenever it increments some sensor counter or state change somewhere, because there may not always be an underlying msg from a subsystem. - Disk full dd if=/dev/urandom of=zero bs=1m [no syslog msg] ### No space to do an rm? The dataset uses gzip and sha256. # df tank/foo 4368000 4368000 0 100% 43999 0 100% /foo # ls -lsi zero 4645 1791445 -rw-r--r-- 1 xxxx xxxx 1792802816 May 31 12:14 zero # rm -f zero rm: zero: No space left on device # :> zero # ls -lsi zero 4645 1 -rw-r--r-- 1 xxxx xxxx 0 May 31 12:19 zero # rm zero [ok] - Faults ad3: FAILURE - READ_DMA48 timed out LBA= GEOM_ELI: g_eli_read_done() failed ad3.eli[READ(offset=, length=65536)] NAME STATE READ WRITE CKSUM tank ONLINE 1 0 0 ad3.eli ONLINE 1 0 0 [no syslog msg] From grarpamp at gmail.com Sun May 31 18:25:38 2009 From: grarpamp at gmail.com (grarpamp) Date: Sun May 31 18:25:44 2009 Subject: ZFS and idprio Message-ID: On an i386 with 1GB ram and P4 2.x GHz single core with arc_max at 64MiB and everything else from RELENG_7_1_0_RELEASE left at default, with this disk layering: PDC20269@100 > PATA > geli > zfs [gzip sha256]. The system become unusable slow when doing heavy sequential disk IO. Such as copy 50G data, zpool scrub, etc. These two processes [*] eat the cpu. I did idprio 31 on them and got 'ki-1' in the nice column [was '-'] and seemed some responsiveness back after a few minutes. Should I be able to nice these kernel threads? Any other way to drop their priority? What is 'ki-1'? Top doesn't seem to show that field right as with say nice -20 sleep 60? Sorted by time: 11 root 1 171 ki31 0K 8K RUN 25.2H 93.90% idle: cpu0 * 594 root 1 -8 - 0K 8K geli:w 321:27 0.68% g_eli[0] ad4 * 695 root 1 -16 - 0K 24K tq->tq 252:33 0.00% spa_zio_intr_1 * 597 root 1 -8 - 0K 8K geli:w 181:52 0.00% g_eli[0] ad5 * 729 root 1 101 - 0K 24K tq->tq 131:01 0.00% spa_zio_intr_1 758 iso 1 44 0 172M 49572K select 62:43 0.00% XFree86 740 root 1 -16 - 0K 24K tx->tx 44:00 0.00% txg_thread_enter Not under load: load averages: 0.12, 0.40, 0.51 up 2+01:11:50 14:19:22 164 processes: 4 running, 141 sleeping, 19 waiting CPU: 0.8% user, 0.0% nice, 15.0% system, 0.8% interrupt, 83.5% idle Mem: 147M Active, 146M Inact, 265M Wired, 24M Cache, 47M Buf, 410M Free