From james-freebsd-fs2 at jrv.org Sun Mar 1 01:07:05 2009 From: james-freebsd-fs2 at jrv.org (James R. Van Artsdalen) Date: Sun Mar 1 01:07:11 2009 Subject: zfs send -R dumps core on -CURRENT In-Reply-To: <49A9DEC2.90701@jrv.org> References: <49A9DEC2.90701@jrv.org> Message-ID: <49AA5029.3080200@jrv.org> James R. Van Artsdalen wrote: > svn r189099, amd64 > > /# zfs send -Rv bigtex@now > x > Segmentation fault: 11 (core dumped) > /# > This one is over my head. It crashes almost immediately while traversing the properties for the first element to be sent, presumably "bigtex" and not yet a child filesystem. These properties are processed by zfs_name_to_prop OK: "mountpoint","used","quota","reservation","compressratio","usedbysnapshots","usedbydataset","usedbyrefreservation","usedbychildren","available","referenced","creation" Then send_iterate_prop() does zfs_name_to_prop("createtxg") which returns ZPROP_INVAL (-1). zfs_prop_readonly crashes on the arg of -1. while ((elem = nvlist_next_nvpair(zhp->zfs_props, elem)) != NULL) { char *propname = nvpair_name(elem); => zfs_prop_t prop = zfs_name_to_prop(propname); nvlist_t *propnv; => if (!zfs_prop_user(propname) && zfs_prop_readonly(prop)) From rwatson at FreeBSD.org Sun Mar 1 11:10:03 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Mar 1 11:10:09 2009 Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load Message-ID: <200903011910.n21JA2K5077082@freefall.freebsd.org> The following reply was made to PR kern/131360; it has been noted by GNATS. From: Robert Watson To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/131360: [nfs] poor scaling behavior of the NFS server under load Date: Sun, 1 Mar 2009 19:06:25 +0000 (GMT) On Wed, 4 Feb 2009, Martin Birgmeier wrote: > [Please note that the email address given is not valid due > to security reasons. Just reply to the gnats entry, and > I'll follow it via the web interface.] > > Between FreeBSD 6.3 and 7.1, the behavior of the NFS server > changed for the worse. Under 6.3, the load generated by the > nfsd's would never exceed their number (I am using > nfs_server_flags="-u -t -n 8"). With 7.1, when the client > generates a lot of requests, it seems that the load on the > NFS server can grow nearly without bounds, rendering the > server all but unusable. Hi Martin: Could I ask you to clarify a few things about the NFS server configuration: - What device/device driver is on the server? - Is the mount over TCP or UDP? There are a number of changes between 7.0, one of the potential changes to look at is the increased UDP parallelism support due to read-locking in the UDP stack overwhelming the capabilities of some device/device drivers. We've had a couple of reports of this specifically with the bge driver. If you're using UDP, converting to TCP would be interesting; if it's bge, then we could give you a patch to locally revert the read-locking changes to see if that helps manage contention better (i.e., more contention higher on a sec of locks moves the contention off the single device driver lock). Robert N M Watson Computer Laboratory University of Cambridge From bugmaster at FreeBSD.org Mon Mar 2 03:07:33 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 2 03:11:09 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200903021106.n22B6pZG057281@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/132145 fs [panic] File System Hard Crashes o 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/131353 fs gjournal kernel lock 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] 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/129174 fs [nfs] [zfs] [panic] NFS v3 Panic when under high load o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129084 fs [udf] [panic] [lor] udf panic: getblk: size(67584) > M 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po 45 problems total. From hartzell at alerce.com Mon Mar 2 09:29:58 2009 From: hartzell at alerce.com (George Hartzell) Date: Mon Mar 2 09:30:05 2009 Subject: zfs send -R dumps core on -CURRENT In-Reply-To: <20090301025446.GA1078@darklight.homeunix.org> References: <49A9DEC2.90701@jrv.org> <20090301025446.GA1078@darklight.homeunix.org> Message-ID: <18860.6038.42835.645788@almost.alerce.com> Yuri Pankov writes: > On Sat, Feb 28, 2009 at 07:02:58PM -0600, James R. Van Artsdalen wrote: > > svn r189099, amd64 > > > > I'm trying to duplicate pool "bigtex" to pool "newtex". > > > > /# zfs snapsnot -r bigtex@now > > /# zfs send -Rv bigtex@now | zfs recv newtex > > cannot receive: failed to read from stream > > /# zfs send -Rv bigtex@now > x > > Segmentation fault: 11 (core dumped) > > /# > > > > Is there a way to tell make buildworld to just build everything with -g > > and not strip anything? > > DEBUG_FLAGS=-g in /etc/src.conf I've attached a patch that fixes this problem (for me) to PR #130105. g. From c-h at mail.ru Mon Mar 2 13:55:50 2009 From: c-h at mail.ru (Cache) Date: Mon Mar 2 13:56:21 2009 Subject: Help! zpool corrupted! Message-ID: I have FreeBSD 8.0-CURRENT r188913M (amd64) on notebook with dual core Turion and 4G of RAM. Disk controller is AMD SB600. Single HDD - SATA-150 250G WD2500BEVS, ad4 at ata2, formatted with one ufs root partition 256M (ad4s1a) and ZFS pool (ver. 6 from FreeBSD 7-STABLE, ad4s1d) on rest of the disk. On ZFS pool I have about ten datasets: /root /usr /home /usr/src etc. Now I have zpool status "One or more devices has experienced an error...". When I run scrubing, I see many errors in pool. Every scrub after reboot displays different amount of errors: 47, 176 - or ~24000. Disk and disk controller seems to be OK, checked with mhdd, but with hw.ata.ata_dma=1 there are error messages in console sometimes (something like 'DMA error'. Sorry, I can't explain its. I don't save its last time and now trying to reproduce). When I set hw.ata.ata_dma=0 in loader.conf, there are no errors in console. With 'zfs mount -a' command terminal not returns command prompt, but system not freezes - any typing echoed to display and ctrl-alt-del reboots system as expected. I tried to mound datasets manually - system became thinking on /home and /usr. Does anybody know, how can I restore those two datasets or just make its temporary accessible for retrieving data? Any HOWTOs? I have some important data and many polished app configs on /home and just not want one more time installing of ~1000 ports... And yes, I stupid, because last backup was long time ago... :( From army.of.root at googlemail.com Mon Mar 2 16:44:54 2009 From: army.of.root at googlemail.com (army.of.root) Date: Mon Mar 2 16:45:00 2009 Subject: Help! zpool corrupted! In-Reply-To: References: Message-ID: <49AC773E.8030601@googlemail.com> Cache wrote: > I have FreeBSD 8.0-CURRENT r188913M (amd64) on notebook with dual core Turion and 4G of RAM. Disk controller is AMD SB600. Single HDD - SATA-150 250G WD2500BEVS, ad4 at ata2, formatted with one ufs root partition 256M (ad4s1a) and ZFS pool (ver. 6 from FreeBSD 7-STABLE, ad4s1d) on rest of the disk. On ZFS pool I have about ten datasets: /root /usr /home /usr/src etc. > > Now I have zpool status "One or more devices has experienced an error...". When I run scrubing, I see many errors in pool. Every scrub after reboot displays different amount of errors: 47, 176 - or ~24000. > Disk and disk controller seems to be OK, checked with mhdd, but with hw.ata.ata_dma=1 there are error messages in console sometimes (something like 'DMA error'. Sorry, I can't explain its. I don't save its last time and now trying to reproduce). > > When I set hw.ata.ata_dma=0 in loader.conf, there are no errors in console. > > With 'zfs mount -a' command terminal not returns command prompt, but system not freezes - any typing echoed to display and ctrl-alt-del reboots system as expected. I tried to mound datasets manually - system became thinking on /home and /usr. > > Does anybody know, how can I restore those two datasets or just make its temporary accessible for retrieving data? Any HOWTOs? I have some important data and many polished app configs on /home and just not want one more time installing of ~1000 ports... And yes, I stupid, because last backup was long time ago... :( Hi, this isnt very nice to say, but you knew you were running experimental code, that is supposed do do RAIDs, on a single HDD. ZFS can't really do its magic without redundancy. You could try to make a dd copy of the partition to another Harddrive to remove the possible hardware failure from the equation and try different stuff on that image. But i wouldnt trust a currupted filesystem, so the ports may be reinstalld anyway. If you're successful, please report here. regards From andrew at modulus.org Mon Mar 2 16:53:14 2009 From: andrew at modulus.org (Andrew Snow) Date: Mon Mar 2 16:53:20 2009 Subject: Help! zpool corrupted! In-Reply-To: References: Message-ID: <49AC7EF4.4010809@modulus.org> It sounds like your superblocks got corrupted. There might still be good file data in there but you've lost the top level directory structure. There is a dearth of tools for recovering data from ZFS pools. Its a very good idea to use something like copies=2 or copies=3 if you are using ZFS on a single disk system like a laptop!! - Andrew From randy at psg.com Mon Mar 2 19:12:25 2009 From: randy at psg.com (Randy Bush) Date: Mon Mar 2 19:12:31 2009 Subject: .zfs/snapshot: Bad file descriptor Message-ID: moo.edu:/usr# rm -rf .zfs rm: .zfs/snapshot: Bad file descriptor rm: .zfs: File exists moo.edu:/usr# ls -l .zfs ls: snapshot: Bad file descriptor total 0 and old trusty emacs dired did not help (file-error Removing old name operation not supported /usr/.zfs/snapshot) what do i whack? randy From dimitar.vassilev at gmail.com Mon Mar 2 22:07:31 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Mon Mar 2 22:07:38 2009 Subject: .zfs/snapshot: Bad file descriptor In-Reply-To: References: Message-ID: <59adc1a0903022207s34028ed4n8d93c935da47b14b@mail.gmail.com> 2009/3/3 Randy Bush : > moo.edu:/usr# rm -rf .zfs > rm: .zfs/snapshot: Bad file descriptor > rm: .zfs: File exists > > moo.edu:/usr# ls -l .zfs > ls: snapshot: Bad file descriptor > total 0 > > and old trusty emacs dired did not help > ?(file-error Removing old name operation not supported /usr/.zfs/snapshot) > > what do i whack? > > randy try rebooting the system if possible - current freebsd implementation has this feature from RELENG_7. From randy at psg.com Tue Mar 3 01:08:05 2009 From: randy at psg.com (Randy Bush) Date: Tue Mar 3 01:08:12 2009 Subject: .zfs/snapshot: Bad file descriptor In-Reply-To: <59adc1a0903022207s34028ed4n8d93c935da47b14b@mail.gmail.com> References: <59adc1a0903022207s34028ed4n8d93c935da47b14b@mail.gmail.com> Message-ID: >> moo.edu:/usr# rm -rf .zfs >> rm: .zfs/snapshot: Bad file descriptor >> rm: .zfs: File exists >> >> moo.edu:/usr# ls -l .zfs >> ls: snapshot: Bad file descriptor >> total 0 >> >> and old trusty emacs dired did not help >> ?(file-error Removing old name operation not supported /usr/.zfs/snapshot) > try rebooting the system if possible - current freebsd implementation > has this feature from RELENG_7. that worked. but yuchh. it's a kernel cvsupped 2009.01.09. should i cvsup and rebuild? randy From dimitar.vassilev at gmail.com Tue Mar 3 01:16:59 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Tue Mar 3 01:17:05 2009 Subject: .zfs/snapshot: Bad file descriptor In-Reply-To: References: <59adc1a0903022207s34028ed4n8d93c935da47b14b@mail.gmail.com> Message-ID: <59adc1a0903030116o60af7d86v60aee1c2e22cc6e1@mail.gmail.com> >>> and old trusty emacs dired did not help >>> ?(file-error Removing old name operation not supported /usr/.zfs/snapshot) >> try rebooting the system if possible ?- current freebsd implementation >> has this feature from RELENG_7. > > that worked. ?but yuchh. > > it's a kernel cvsupped 2009.01.09. ?should i cvsup and rebuild? > > randy > well, I have no idea. This issue persists for me over 1.5 years. If you want file a PR with all the stuff. I've mailed couple of times this list with pjd in copy, to no avail. Regards, dimitar From paul at fletchermoorland.co.uk Tue Mar 3 02:07:25 2009 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Tue Mar 3 02:07:31 2009 Subject: Help! zpool corrupted! In-Reply-To: References: Message-ID: <200903030941.41226.paul@fletchermoorland.co.uk> On Monday 02 March 2009 21:45:35 Cache wrote: > I have FreeBSD 8.0-CURRENT r188913M (amd64) on notebook with dual core > Turion and 4G of RAM. Disk controller is AMD SB600. Single HDD - SATA-150 > 250G WD2500BEVS, ad4 at ata2, formatted with one ufs root partition 256M > (ad4s1a) and ZFS pool (ver. 6 from FreeBSD 7-STABLE, ad4s1d) on rest of the > disk. On ZFS pool I have about ten datasets: /root /usr /home /usr/src etc. > > Now I have zpool status "One or more devices has experienced an error...". > When I run scrubing, I see many errors in pool. Every scrub after reboot > displays different amount of errors: 47, 176 - or ~24000. Disk and disk > controller seems to be OK, checked with mhdd, but with hw.ata.ata_dma=1 > there are error messages in console sometimes (something like 'DMA error'. > Sorry, I can't explain its. I don't save its last time and now trying to > reproduce). > > When I set hw.ata.ata_dma=0 in loader.conf, there are no errors in console. > > With 'zfs mount -a' command terminal not returns command prompt, but system > not freezes - any typing echoed to display and ctrl-alt-del reboots system > as expected. I tried to mound datasets manually - system became thinking on > /home and /usr. > > Does anybody know, how can I restore those two datasets or just make its > temporary accessible for retrieving data? Any HOWTOs? I have some important > data and many polished app configs on /home and just not want one more time > installing of ~1000 ports... And yes, I stupid, because last backup was > long time ago... :( > Hi, I had a similar issue a while back, but with a AMD SB700 chipset. I was running CURRENT with GPT and ZFS boot on a SATA mirrored setup. What I noticed was that every time I booted I had silent data corruption on either of the disks, usually at the start or end of the disk (GPT partition tables would get screwed up). There might have been other data corruption but I just destroyed the GPT tables and re-added the partition back in to the mirror I know that there are issues with the Silicon Image SATA chipsets and I wonder if the AMD chipset is based on the Silicon Image ones. The only solution I found was to use a non Silicon Image based SATA controller (in my case I went for a JMicron) If the SMART data from the drive does not show bad then I would probably agree that the drive ok. As for data recovery, I dont know but CURRENT should not really be used in production environments or to store critical or important data. While CURRENT has been very stable for me (for the most) you really do have your hands on the FreeBSD gods and I have been bitten a few times... but its CURRENT so I cant complain Even with FreeBSD 7, you still get a warning saying "WARNING: ZFS is considered to be an experimental feature in FreeBSD." Paul From peter.schuller at infidyne.com Tue Mar 3 06:54:54 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Tue Mar 3 06:55:07 2009 Subject: Help! zpool corrupted! In-Reply-To: References: Message-ID: <20090303145451.GA76327@hyperion.scode.org> > With 'zfs mount -a' command terminal not returns command prompt, but system not freezes - any typing echoed to display and ctrl-alt-del reboots system as expected. I tried to mound datasets manually - system became thinking on /home and /usr. Can you run "iostat -x 1" while while youre zfs mount -a hangs? It will probably indicate that there is 100% disk utilization on the disk in question, indicating there is one or more I/O request(s) outstanding to the device, indicating a driver/controller/cabling/drive problem. If on the other hand 'zfs mount -a' hangs but there is no ongoing attempts at disk I/O according to iostat, there may be a software problem with zfs or something else, although since you have confirmed disk-related issues it might have been triggered by actual on-disk corruption. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090303/e4bc2838/attachment.pgp From peter.schuller at infidyne.com Tue Mar 3 06:58:17 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Tue Mar 3 06:58:23 2009 Subject: .zfs/snapshot: Bad file descriptor In-Reply-To: <59adc1a0903030116o60af7d86v60aee1c2e22cc6e1@mail.gmail.com> References: <59adc1a0903022207s34028ed4n8d93c935da47b14b@mail.gmail.com> <59adc1a0903030116o60af7d86v60aee1c2e22cc6e1@mail.gmail.com> Message-ID: <20090303145814.GB76327@hyperion.scode.org> > well, I have no idea. This issue persists for me over 1.5 years. > If you want file a PR with all the stuff. I've mailed couple of times > this list with pjd in copy, to no avail. Sorry if I'm missing something, but why is this even expected to work? If you don't want the .zfs directories, should you not turn off its use by setting the appropriate option on the fs? What is the expected result of rm -rf:ing the .zfs directory? -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090303/ff0de5c3/attachment.pgp From stb at lassitu.de Tue Mar 3 07:48:15 2009 From: stb at lassitu.de (Stefan Bethke) Date: Tue Mar 3 07:48:22 2009 Subject: .zfs/snapshot: Bad file descriptor In-Reply-To: <20090303145814.GB76327@hyperion.scode.org> References: <59adc1a0903022207s34028ed4n8d93c935da47b14b@mail.gmail.com> <59adc1a0903030116o60af7d86v60aee1c2e22cc6e1@mail.gmail.com> <20090303145814.GB76327@hyperion.scode.org> Message-ID: <307EA4FE-5053-4D8F-B45F-6711FCDCF467@lassitu.de> Am 03.03.2009 um 15:58 schrieb Peter Schuller: >> well, I have no idea. This issue persists for me over 1.5 years. >> If you want file a PR with all the stuff. I've mailed couple of times >> this list with pjd in copy, to no avail. > > Sorry if I'm missing something, but why is this even expected to work? > If you don't want the .zfs directories, should you not turn off its > use by setting the appropriate option on the fs? > > What is the expected result of rm -rf:ing the .zfs directory? No idea (I personally would expect a permission denied or similar, since it's a virtual dir), but the main issue is that snapshot is no longer accessible. Trying to ls .zfs you usually get the same error message Randy posted; cf. my thread here on -fs and on -current from a couple weeks back. Interestingly enough, there doesn't seem to be a PR yet, or at least I can't find it. My guess is that the automounting code is getting confused sometimes, and nixes some part of the snapshot vnode while unmounting a snapshot. This in turn leads to a panic on unmounting the containg ZFS. Stefan -- Stefan Bethke Fon +49 151 14070811 From gavin at FreeBSD.org Tue Mar 3 08:04:53 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Mar 3 08:04:59 2009 Subject: Help! zpool corrupted! In-Reply-To: References: Message-ID: <1236094585.46497.1.camel@buffy.york.ac.uk> On Tue, 2009-03-03 at 00:45 +0300, Cache wrote: > I have FreeBSD 8.0-CURRENT r188913M (amd64) on notebook with dual core > Turion and 4G of RAM. Disk controller is AMD SB600. Single HDD - > SATA-150 250G WD2500BEVS, ad4 at ata2, formatted with one ufs root > partition 256M (ad4s1a) and ZFS pool (ver. 6 from FreeBSD 7-STABLE, > ad4s1d) on rest of the disk. On ZFS pool I have about ten > datasets: /root /usr /home /usr/src etc. > > Now I have zpool status "One or more devices has experienced an > error...". When I run scrubing, I see many errors in pool. Every scrub > after reboot displays different amount of errors: 47, 176 - or ~24000. > Disk and disk controller seems to be OK, checked with mhdd, but with > hw.ata.ata_dma=1 there are error messages in console sometimes > (something like 'DMA error'. Sorry, I can't explain its. I don't save > its last time and now trying to reproduce). > > When I set hw.ata.ata_dma=0 in loader.conf, there are no errors in > console. > > With 'zfs mount -a' command terminal not returns command prompt, but > system not freezes - any typing echoed to display and ctrl-alt-del > reboots system as expected. I tried to mound datasets manually - > system became thinking on /home and /usr. > > Does anybody know, how can I restore those two datasets or just make > its temporary accessible for retrieving data? Any HOWTOs? I have some > important data and many polished app configs on /home and just not > want one more time installing of ~1000 ports... And yes, I stupid, > because last backup was long time ago... :( Can you reboot with your last kernel and see if that fixes things? There was apparently a window where ATA drives could return data that was corrupted - but the on-disk data was untouched. This only happened for particular controllers, but r188913 is inside the window where there were problems. If reverting the kernel fixes things for you, I believe you should be fine just updating again to the code as of today. Gavin From stef-list at memberwebs.com Tue Mar 3 15:00:30 2009 From: stef-list at memberwebs.com (Stef) Date: Tue Mar 3 15:00:37 2009 Subject: Help! zpool corrupted! References: <200903030941.41226.paul@fletchermoorland.co.uk> Message-ID: <20090303223810.8E51DEFB6DA@mx.npubs.com> Paul Wootton wrote: > If the SMART data from the drive does not show bad then I would probably agree > that the drive ok. I've seen many drives with unreadable blocks, that don't show any problems in the SMART error logs. The SMART statistics on those drives are slightly different, but nothing that distinguishes it from an okay drive that has remapped a few sectors. I think that FreeBSD's timeouts are usually much higher than that of many 'desktop' drives. The drive will keep trying to read the sector long after FreeBSD has given up. Eventually the drive semi-succeeds and then doesn't consider it a failure. Ergo no SMART error log. Cheers, Stef From info at mschuette.name Tue Mar 3 18:10:03 2009 From: info at mschuette.name (=?UTF-8?B?TWFydGluIFNjaMO8dHRl?=) Date: Tue Mar 3 18:10:10 2009 Subject: kern/114676: [ufs] snapshot creation panics: snapacct_ufs2: bad block Message-ID: <200903040210.n242A2Kx055336@freefall.freebsd.org> The following reply was made to PR kern/114676; it has been noted by GNATS. From: =?UTF-8?B?TWFydGluIFNjaMO8dHRl?= To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/114676: [ufs] snapshot creation panics: snapacct_ufs2: bad block Date: Wed, 04 Mar 2009 02:46:03 +0100 This is a multi-part message in MIME format. --------------000007020408070003050200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I encounter the same problem since updating from 6.0 to 7.1-RELEASE. The system is a Pentium4 with a 500 Gb RAID1 (twe). The filesystems are clean, in case of the appended dumps the panics happened just after a complete fsck in single-user mode. The panics are not completely reproducable as they happen quite often but not on every single snapshot. -- Martin --------------000007020408070003050200 Content-Type: text/plain; name="114676-kgdb1.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="114676-kgdb1.txt" W3Jvb3RAcGFwcmlrYV0gL3Vzci9vYmovdXNyL3NyYy9zeXMvVVAjIGtnZGIgLW4gOCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFsxMDddCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNvcHlyaWdodCAyMDA0IEZy ZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBzb2Z0d2FyZSwgY292 ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5b3UgYXJlCndl bGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRl ciBjZXJ0YWluIGNvbmRpdGlvbnMuClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBj b25kaXRpb25zLgpUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBU eXBlICJzaG93IHdhcnJhbnR5IiBmb3IgZGV0YWlscy4KVGhpcyBHREIgd2FzIGNvbmZpZ3Vy ZWQgYXMgImkzODYtbWFyY2VsLWZyZWVic2QiLi4uCgpVbnJlYWQgcG9ydGlvbiBvZiB0aGUg a2VybmVsIG1lc3NhZ2UgYnVmZmVyOgpwYW5pYzogc25hcGFjY3RfdWZzMjogYmFkIGJsb2Nr ClVwdGltZTogNG0xM3MKUGh5c2ljYWwgbWVtb3J5OiAxMDE0IE1CCkR1bXBpbmcgMTU1IE1C OiAxNDAgMTI0IDEwOCA5MiA3NiA2MCA0NCAyOCAxMgoKUmVhZGluZyBzeW1ib2xzIGZyb20g L2Jvb3Qva2VybmVsL2FjcGkua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu ZWwvYWNwaS5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9i b290L2tlcm5lbC9hY3BpLmtvCmIjMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTk2CjE5NiAg ICAgICAgICAgICBfX2FzbSBfX3ZvbGF0aWxlKCJtb3ZsICUlZnM6MCwlMCIgOiAiPXIiICh0 ZCkpOwooa2dkYikgYnQKIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE5NgojMSAgMHhjMDU3 MWExYSBpbiBib290IChob3d0bz0yNjApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1 dGRvd24uYzo0MTgKIzIgIDB4YzA1NzFjNTQgaW4gcGFuaWMgKGZtdD1WYXJpYWJsZSAiZm10 IiBpcyBub3QgYXZhaWxhYmxlLgopIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRv d24uYzo1NzQKIzMgIDB4YzA2YzAwN2EgaW4gc25hcGFjY3RfdWZzMiAodnA9MHhjNDNhZjc4 Yywgb2xkYmxrcD0weGM0M2M0ZjQ4LCBsYXN0YmxrcD0weGM0M2M3MDAwLCBmcz0weGMzZTIz ODAwLCBsYmxrbm89MjAwNzA1MiwKICAgIGV4cHVuZ2V0eXBlPTIpIGF0IC91c3Ivc3JjL3N5 cy91ZnMvZmZzL2Zmc19zbmFwc2hvdC5jOjE0ODEKIzQgIDB4YzA2YmY2YWIgaW4gaW5kaXJh Y2N0X3VmczIgKHNuYXB2cD0weGM0M2FmNzhjLCBjYW5jZWx2cD0weGMzZTI5ZTA0LCBsZXZl bD0wLCBibGtubz0xMTI5NDY5NiwgbGJuPS0yMDA3MDUyLAogICAgcmxibj0yMDA3MDUyLCBy ZW1ibGtzPTkyNzMsIGJsa3NwZXJpbmRpcj0xLCBmcz0weGMzZTIzODAwLCBhY2N0ZnVuYz0w eGMwNmJmZjMxIDxzbmFwYWNjdF91ZnMyPiwgZXhwdW5nZXR5cGU9MikKICAgIGF0IC91c3Iv c3JjL3N5cy91ZnMvZmZzL2Zmc19zbmFwc2hvdC5jOjEzOTYKIzUgIDB4YzA2YmY1ZmMgaW4g aW5kaXJhY2N0X3VmczIgKHNuYXB2cD0weGM0M2FmNzhjLCBjYW5jZWx2cD0weGMzZTI5ZTA0 LCBsZXZlbD0wLCBibGtubz0xMTY3MDc3NiwgbGJuPVVuaGFuZGxlZCBkd2FyZiBleHByZXNz aW9uIG9wY29kZSAweDkzCikKICAgIGF0IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zbmFw c2hvdC5jOjE0MDYKIzYgIDB4YzA2YzA1YTMgaW4gZXhwdW5nZV91ZnMyIChzbmFwdnA9MHhj NDNhZjc4YywgY2FuY2VsaXA9MHhjM2UxNGI4MCwgZnM9MHhjM2UyMzgwMCwKICAgIGFjY3Rm dW5jPTB4YzA2YmZmMzEgPHNuYXBhY2N0X3VmczI+LCBleHB1bmdldHlwZT0yKSBhdCAvdXNy L3NyYy9zeXMvdWZzL2Zmcy9mZnNfc25hcHNob3QuYzoxMzI4CiM3ICAweGMwNmMzYzJhIGlu IGZmc19zbmFwc2hvdCAobXA9MHhjM2RkOTg2NCwgc25hcGZpbGU9MHhjNDEyYTBhMCAiL2ph aWwvYmVuZGVyLy5zbmFwL3Rlc3QiKQogICAgYXQgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZz X3NuYXBzaG90LmM6NzExCiM4ICAweGMwNmQzYmZhIGluIGZmc19tb3VudCAobXA9MHhjM2Rk OTg2NCwgdGQ9MHhjM2RiYWFmMCkgYXQgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zmc29w cy5jOjMzNwojOSAgMHhjMDVlMWEwNCBpbiB2ZnNfZG9ubW91bnQgKHRkPTB4YzNkYmFhZjAs IGZzZmxhZ3M9NjU1MzYsIGZzb3B0aW9ucz0weGM0MzY5MzAwKQogICAgYXQgL3Vzci9zcmMv c3lzL2tlcm4vdmZzX21vdW50LmM6MTAxNAojMTAgMHhjMDVlMmMwNyBpbiBubW91bnQgKHRk PTB4YzNkYmFhZjAsIHVhcD0weGU2NTY4Y2ZjKSBhdCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf bW91bnQuYzo0MTUKIzExIDB4YzA3MzQwOGIgaW4gc3lzY2FsbCAoZnJhbWU9MHhlNjU2OGQz OCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6MTA5MAojMTIgMHhjMDcyMzdm MCBpbiBYaW50MHg4MF9zeXNjYWxsICgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhj ZXB0aW9uLnM6MjU1CiMxMyAweDAwMDAwMDMzIGluID8/ICgpClByZXZpb3VzIGZyYW1lIGlu bmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQooa2dkYikgICAgICAgICAg --------------000007020408070003050200 Content-Type: text/plain; name="114676-kgdb2.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="114676-kgdb2.txt" W3Jvb3RAcGFwcmlrYV0gL3Vzci9vYmovdXNyL3NyYy9zeXMvVVAjIGtnZGIgLW4gOSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFsxMDJdCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNvcHlyaWdodCAyMDA0IEZy ZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBzb2Z0d2FyZSwgY292 ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5b3UgYXJlCndl bGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRl ciBjZXJ0YWluIGNvbmRpdGlvbnMuClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBj b25kaXRpb25zLgpUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBU eXBlICJzaG93IHdhcnJhbnR5IiBmb3IgZGV0YWlscy4KVGhpcyBHREIgd2FzIGNvbmZpZ3Vy ZWQgYXMgImkzODYtbWFyY2VsLWZyZWVic2QiLi4uCgpVbnJlYWQgcG9ydGlvbiBvZiB0aGUg a2VybmVsIG1lc3NhZ2UgYnVmZmVyOgpwYW5pYzogc25hcGFjY3RfdWZzMjogYmFkIGJsb2Nr ClVwdGltZTogMTVtNDNzClBoeXNpY2FsIG1lbW9yeTogMTAxNCBNQgpEdW1waW5nIDk5IE1C OiA4NCA2OCA1MiAzNiAyMCA0CgpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwv YWNwaS5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9hY3BpLmtvLnN5 bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2Fj cGkua28KIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE5NgoxOTYgICAgICAgICAgICAgX19h c20gX192b2xhdGlsZSgibW92bCAlJWZzOjAsJTAiIDogIj1yIiAodGQpKTsKKGtnZGIpIGJ0 CiMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDoxOTYKIzEgIDB4YzA1NzFhMWEgaW4gYm9vdCAo aG93dG89MjYwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDE4CiMy ICAweGMwNTcxYzU0IGluIHBhbmljIChmbXQ9VmFyaWFibGUgImZtdCIgaXMgbm90IGF2YWls YWJsZS4KKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NTc0CiMzICAw eGMwNmMwMDdhIGluIHNuYXBhY2N0X3VmczIgKHZwPTB4YzQzODhjZjAsIG9sZGJsa3A9MHhj NDNlYmY0OCwgbGFzdGJsa3A9MHhjNDNlZTAwMCwgZnM9MHhjM2UyMzgwMCwgbGJsa25vPTIw MDcwNTIsCiAgICBleHB1bmdldHlwZT0yKSBhdCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNf c25hcHNob3QuYzoxNDgxCiM0ICAweGMwNmJmNmFiIGluIGluZGlyYWNjdF91ZnMyIChzbmFw dnA9MHhjNDM4OGNmMCwgY2FuY2VsdnA9MHhjM2UyOWUwNCwgbGV2ZWw9MCwgYmxrbm89MTEy OTQ2OTYsIGxibj0tMjAwNzA1MiwKICAgIHJsYm49MjAwNzA1MiwgcmVtYmxrcz05MjczLCBi bGtzcGVyaW5kaXI9MSwgZnM9MHhjM2UyMzgwMCwgYWNjdGZ1bmM9MHhjMDZiZmYzMSA8c25h cGFjY3RfdWZzMj4sIGV4cHVuZ2V0eXBlPTIpCiAgICBhdCAvdXNyL3NyYy9zeXMvdWZzL2Zm cy9mZnNfc25hcHNob3QuYzoxMzk2CiM1ICAweGMwNmJmNWZjIGluIGluZGlyYWNjdF91ZnMy IChzbmFwdnA9MHhjNDM4OGNmMCwgY2FuY2VsdnA9MHhjM2UyOWUwNCwgbGV2ZWw9MCwgYmxr bm89MTE2NzA3NzYsIGxibj1VbmhhbmRsZWQgZHdhcmYgZXhwcmVzc2lvbiBvcGNvZGUgMHg5 MwopCiAgICBhdCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc25hcHNob3QuYzoxNDA2CiM2 ICAweGMwNmMwNWEzIGluIGV4cHVuZ2VfdWZzMiAoc25hcHZwPTB4YzQzODhjZjAsIGNhbmNl bGlwPTB4YzNlMTRiODAsIGZzPTB4YzNlMjM4MDAsCiAgICBhY2N0ZnVuYz0weGMwNmJmZjMx IDxzbmFwYWNjdF91ZnMyPiwgZXhwdW5nZXR5cGU9MikgYXQgL3Vzci9zcmMvc3lzL3Vmcy9m ZnMvZmZzX3NuYXBzaG90LmM6MTMyOAojNyAgMHhjMDZjM2MyYSBpbiBmZnNfc25hcHNob3Qg KG1wPTB4YzNkZDk4NjQsIHNuYXBmaWxlPTB4YzQxNmJiNDAgIi9qYWlsL2JlbmRlci8uc25h cC9mc2NrX3NuYXBzaG90IikKICAgIGF0IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zbmFw c2hvdC5jOjcxMQojOCAgMHhjMDZkM2JmYSBpbiBmZnNfbW91bnQgKG1wPTB4YzNkZDk4NjQs IHRkPTB4YzQzN2UwMDApIGF0IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoz MzcKIzkgIDB4YzA1ZTFhMDQgaW4gdmZzX2Rvbm1vdW50ICh0ZD0weGM0MzdlMDAwLCBmc2Zs YWdzPTE4OTQ0MDAwLCBmc29wdGlvbnM9MHhjM2UzMzE4MCkKICAgIGF0IC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19tb3VudC5jOjEwMTQKIzEwIDB4YzA1ZTJjMDcgaW4gbm1vdW50ICh0ZD0w eGM0MzdlMDAwLCB1YXA9MHhlNjViNGNmYykgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX21v dW50LmM6NDE1CiMxMSAweGMwNzM0MDhiIGluIHN5c2NhbGwgKGZyYW1lPTB4ZTY1YjRkMzgp IGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjEwOTAKIzEyIDB4YzA3MjM3ZjAg aW4gWGludDB4ODBfc3lzY2FsbCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2Vw dGlvbi5zOjI1NQojMTMgMHgwMDAwMDAzMyBpbiA/PyAoKQpQcmV2aW91cyBmcmFtZSBpbm5l ciB0byB0aGlzIGZyYW1lIChjb3JydXB0IHN0YWNrPykKKGtnZGIpCg== --------------000007020408070003050200 Content-Type: text/plain; name="114676-dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="114676-dmesg.txt" W3Jvb3RAcGFwcmlrYV0gL3Vzci9vYmovdXNyL3NyYy9zeXMvVVAjIGRtZXNnICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFsxMDNdCkNvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRoZSBGcmVlQlNEIFByb2pl Y3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwg MTk5MSwgMTk5MiwgMTk5MywgMTk5NAogICAgICAgIFRoZSBSZWdlbnRzIG9mIHRoZSBVbml2 ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMg YSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVl QlNEIDcuMS1SRUxFQVNFLXAzICMyOiBUdWUgTWFyICAzIDAxOjE0OjQ2IENFVCAyMDA5CiAg ICByb290QHBhcHJpa2EuYXN0YS51bmktcG90c2RhbS5kZTovdXNyL29iai91c3Ivc3JjL3N5 cy9VUApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBw ZXJmb3JtYW5jZS4KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDAKQ1BVOiBJbnRlbChSKSBQZW50aXVtKFIpIDQgQ1BVIDIuNjBHSHogKDI2MDUu OTItTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0g MHhmMjkgIFN0ZXBwaW5nID0gOQogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQ U0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQs UFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJF PgogIEZlYXR1cmVzMj0weDQ0MDA8Q05YVC1JRCx4VFBSPgogIExvZ2ljYWwgQ1BVcyBwZXIg Y29yZTogMgpyZWFsIG1lbW9yeSAgPSAxMDcyNTYyMTc2ICgxMDIyIE1CKQphdmFpbCBtZW1v cnkgPSAxMDQwNDAwMzg0ICg5OTIgTUIpCldJVE5FU1M6IHNwaW4gbG9jayBjcHVzZXQgbm90 IGluIG9yZGVyIGxpc3QKV0lUTkVTUzogc3BpbiBsb2NrIGludHJjbnQgbm90IGluIG9yZGVy IGxpc3QKa2JkMSBhdCBrYmRtdXgwCmFjcGkwOiA8SW50ZWxSIEFXUkRBQ1BJPiBvbiBtb3Ro ZXJib2FyZAphY3BpMDogW0lUSFJFQURdCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQph Y3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2 YXRpb24gb2YgMTAwMDAwLCAzZmRlMDAwMCAoMykgZmFpbGVkClRpbWVjb3VudGVyICJBQ1BJ LWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDog PDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3Bp MAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBI b3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjAKYWdwMDogPEludGVsIDgyODc1UCBob3N0IHRvIEFHUCBicmlk Z2U+IG9uIGhvc3RiMApwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9u IHBjaTAKcGNpMTogPFBDSSBidXM+IG9uIHBjaWIxCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJy aWRnZT4gYXQgZGV2aWNlIDMuMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIyCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuNj4g cG9ydCAweGMwMDAtMHhjMDFmIG1lbSAweGYyMDAwMDAwLTB4ZjIwMWZmZmYgaXJxIDExIGF0 IGRldmljZSAxLjAgb24gcGNpMgplbTA6IFtGSUxURVJdCmVtMDogRXRoZXJuZXQgYWRkcmVz czogMDA6ZTA6ODE6MmE6NWI6MTEKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnR3ZTA6 IDwzd2FyZSBTdG9yYWdlIENvbnRyb2xsZXIuIERyaXZlciB2ZXJzaW9uIDEuNTAuMDEuMDAy PiBwb3J0IDB4ZDAwMC0weGQwMGYgbWVtIDB4ZjE4NjIwMDAtMHhmMTg2MjAwZiwweGYxMDAw MDAwLTB4ZjE3ZmZmZmYgaXJxIDEwIGF0IGRldmljZSAwLjAgb24gcGNpMwp0d2UwOiBbR0lB TlQtTE9DS0VEXQp0d2UwOiBbSVRIUkVBRF0KdHdlMDogNCBwb3J0cywgRmlybXdhcmUgRkU4 UyAxLjA1LjAwLjA2OCwgQklPUyBCRTdYIDEuMDguMDAuMDQ4CmVtMTogPEludGVsKFIpIFBS Ty8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuNj4gcG9ydCAweGQxMDAtMHhkMTNmIG1l bSAweGYxODIwMDAwLTB4ZjE4M2ZmZmYsMHhmMTgwMDAwMC0weGYxODFmZmZmIGlycSA1IGF0 IGRldmljZSAyLjAgb24gcGNpMwplbTE6IFtGSUxURVJdCmVtMTogRXRoZXJuZXQgYWRkcmVz czogMDA6ZTA6ODE6MmE6NWI6MTIKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+ IHBvcnQgMHhkMjAwLTB4ZDJmZiBtZW0gMHhmMDAwMDAwMC0weGYwZmZmZmZmLDB4ZjE4NjAw MDAtMHhmMTg2MGZmZiBpcnEgMTAgYXQgZGV2aWNlIDcuMCBvbiBwY2kzCmZ4cDA6IDxJbnRl bCA4MjU2MkVUIChJQ0g1L0lDSDVSKSBQcm8vMTAwIFZFIEV0aGVybmV0PiBwb3J0IDB4ZDMw MC0weGQzM2YgbWVtIDB4ZjE4NjEwMDAtMHhmMTg2MWZmZiBpcnEgMTIgYXQgZGV2aWNlIDgu MCBvbiBwY2kzCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBmeHAwCmlucGh5MDogPGk4MjU2MkVN IDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKaW5waHkwOiAgMTBi YXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpmeHAw OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDplMDo4MToyYTo1YjoxMwpmeHAwOiBbSVRIUkVBRF0K aXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8 SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVsIElDSDUgVURNQTEwMCBjb250cm9s bGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZjAwMC0w eGYwMGYgYXQgZGV2aWNlIDMxLjEgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMAphdGEwOiBbSVRIUkVBRF0KYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBj aTAKYXRhMTogW0lUSFJFQURdCmF0YXBjaTE6IDxJbnRlbCBJQ0g1IFNBVEExNTAgY29udHJv bGxlcj4gcG9ydCAweGU0MDAtMHhlNDA3LDB4ZTUwMC0weGU1MDMsMHhlNjAwLTB4ZTYwNyww eGU3MDAtMHhlNzAzLDB4ZTgwMC0weGU4MGYgaXJxIDExIGF0IGRldmljZSAzMS4yIG9uIHBj aTAKYXRhcGNpMTogW0lUSFJFQURdCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kx CmF0YTI6IFtJVEhSRUFEXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQphdGEz OiBbSVRIUkVBRF0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAo bm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAK ZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3 IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IFtGSUxURVJdCmZkMDogPDE0NDAtS0IgMy41 IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00g cG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6 IHR5cGUgMTY1NTBBCnNpbzA6IFtGSUxURVJdCnNpbzE6IDwxNjU1MEEtY29tcGF0aWJsZSBD T00gcG9ydD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBhY3BpMApzaW8xOiB0eXBlIDE2 NTUwQQpzaW8xOiBbRklMVEVSXQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw NDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2Fy ZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NL RURdCmF0a2JkMDogW0lUSFJFQURdCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKcDR0Y2Mw OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKcG10aW1lcjAgb24g aXNhMApvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzdmZmYs MHhjODAwMC0weGM4ZmZmIHBucGlkIE9STTAwMDAgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29u c29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25z b2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgz YzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKVGltZWNvdW50ZXIgIlRT QyIgZnJlcXVlbmN5IDI2MDU5MjIxMjQgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMS4wMDAgbXNlYwphY2QwOiBEVkRST00gPFRPU0hJQkEgT0RELURWRCBTRC1N MTgwMi8xMDMxPiBhdCBhdGExLW1hc3RlciBVRE1BMzMKdHdlZDA6IDxVbml0IDEsIFR3aW5T dG9yLCBOb3JtYWw+IG9uIHR3ZTAKdHdlZDA6IDQ3NjkzOU1CICg5NzY3NzExMjAgc2VjdG9y cykKdHdlZDE6IDxVbml0IDMsIEpCT0QsIE5vcm1hbD4gb24gdHdlMAp0d2VkMTogMTk0NDgx TUIgKDM5ODI5NzA4OCBzZWN0b3JzKQpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVk LCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJv bSB1ZnM6L2Rldi90d2VkMHMxYQo= --------------000007020408070003050200 Content-Type: text/plain; name="114676-kernelconf.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="114676-kernelconf.txt" YWRkaXRpb25hbCBub3RlOgovZXRjL21ha2UuY29uZiBjb250YWlucyB0aGUgbGluZSAiQ1BV VFlQRT1wZW50aXVtNCIsCm5vIG90aGVyIGdjYyBvcHRpb25zCgpbcm9vdEBwYXByaWthXSAv dXNyL29iai91c3Ivc3JjL3N5cy9VUCMgY2F0IC91c3Ivc3JjL3N5cy9pMzg2L2NvbmYvVVAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzEwNF0KY3B1 ICAgICAgICAgICAgIEk2ODZfQ1BVCmlkZW50ICAgICAgICAgICBHRU5FUklDVVAKCm1ha2Vv cHRpb25zICAgICBERUJVRz0tZyAgICAgICAgICAgICAgICAjIEJ1aWxkIGtlcm5lbCB3aXRo IGdkYigxKSBkZWJ1ZyBzeW1ib2xzCgpvcHRpb25zIElOVkFSSUFOVFMKb3B0aW9ucyBJTlZB UklBTlRfU1VQUE9SVApvcHRpb25zIFdJVE5FU1MKCm9wdGlvbnMgICAgICAgICBTQ0hFRF9V TEUgICAgICAgICAgICAgICAjIFVMRSBzY2hlZHVsZXIKb3B0aW9ucyAgICAgICAgIFBSRUVN UFRJT04gICAgICAgICAgICAgICMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlvbgpv cHRpb25zICAgICAgICAgSU5FVCAgICAgICAgICAgICAgICAgICAgIyBJbnRlck5FVHdvcmtp bmcKb3B0aW9ucyAgICAgICAgIElORVQ2ICAgICAgICAgICAgICAgICAgICMgSVB2NiBjb21t dW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0aW9ucyAgICAgICAgIEZGUyAgICAgICAgICAgICAg ICAgICAgICMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtCm9wdGlvbnMgICAgICAgICBTT0ZU VVBEQVRFUyAgICAgICAgICAgICAjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQK b3B0aW9ucyAgICAgICAgIFVGU19BQ0wgICAgICAgICAgICAgICAgICMgU3VwcG9ydCBmb3Ig YWNjZXNzIGNvbnRyb2wgbGlzdHMKb3B0aW9ucyAgICAgICAgIFVGU19ESVJIQVNIICAgICAg ICAgICAgICMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0aW9u cyAgICAgICAgIFVGU19HSk9VUk5BTCAgICAgICAgICAgICMgRW5hYmxlIGdqb3VybmFsLWJh c2VkIFVGUyBqb3VybmFsaW5nCm9wdGlvbnMgICAgICAgICBNRF9ST09UICAgICAgICAgICAg ICAgICAjIE1EIGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2aWNlCm9wdGlvbnMgICAgICAgICBO RlNDTElFTlQgICAgICAgICAgICAgICAjIE5ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQKb3B0 aW9ucyAgICAgICAgIE5GU1NFUlZFUiAgICAgICAgICAgICAgICMgTmV0d29yayBGaWxlc3lz dGVtIFNlcnZlcgpvcHRpb25zICAgICAgICAgTkZTTE9DS0QgICAgICAgICAgICAgICAgIyBO ZXR3b3JrIExvY2sgTWFuYWdlcgpvcHRpb25zICAgICAgICAgTkZTX1JPT1QgICAgICAgICAg ICAgICAgIyBORlMgdXNhYmxlIGFzIC8sIHJlcXVpcmVzIE5GU0NMSUVOVApvcHRpb25zICAg ICAgICAgTVNET1NGUyAgICAgICAgICAgICAgICAgIyBNU0RPUyBGaWxlc3lzdGVtCm9wdGlv bnMgICAgICAgICBDRDk2NjAgICAgICAgICAgICAgICAgICAjIElTTyA5NjYwIEZpbGVzeXN0 ZW0Kb3B0aW9ucyAgICAgICAgIFBST0NGUyAgICAgICAgICAgICAgICAgICMgUHJvY2VzcyBm aWxlc3lzdGVtIChyZXF1aXJlcyBQU0VVRE9GUykKb3B0aW9ucyAgICAgICAgIFBTRVVET0ZT ICAgICAgICAgICAgICAgICMgUHNldWRvLWZpbGVzeXN0ZW0gZnJhbWV3b3JrCm9wdGlvbnMg ICAgICAgICBHRU9NX1BBUlRfR1BUICAgICAgICAgICAjIEdVSUQgUGFydGl0aW9uIFRhYmxl cy4Kb3B0aW9ucyAgICAgICAgIEdFT01fTEFCRUwgICAgICAgICAgICAgICMgUHJvdmlkZXMg bGFiZWxpemF0aW9uCm9wdGlvbnMgICAgICAgICBDT01QQVRfNDNUVFkgICAgICAgICAgICAj IEJTRCA0LjMgVFRZIGNvbXBhdCBbS0VFUCBUSElTIV0Kb3B0aW9ucyAgICAgICAgIENPTVBB VF9GUkVFQlNENCAgICAgICAgICMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q0Cm9wdGlvbnMg ICAgICAgICBDT01QQVRfRlJFRUJTRDUgICAgICAgICAjIENvbXBhdGlibGUgd2l0aCBGcmVl QlNENQpvcHRpb25zICAgICAgICAgQ09NUEFUX0ZSRUVCU0Q2ICAgICAgICAgIyBDb21wYXRp YmxlIHdpdGggRnJlZUJTRDYKb3B0aW9ucyAgICAgICAgIFNDU0lfREVMQVk9NTAwMCAgICAg ICAgICMgRGVsYXkgKGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlvbnMgICAgICAg ICBLVFJBQ0UgICAgICAgICAgICAgICAgICAjIGt0cmFjZSgxKSBzdXBwb3J0Cm9wdGlvbnMg ICAgICAgICBTVEFDSyAgICAgICAgICAgICAgICAgICAjIHN0YWNrKDkpIHN1cHBvcnQKb3B0 aW9ucyAgICAgICAgIFNZU1ZTSE0gICAgICAgICAgICAgICAgICMgU1lTVi1zdHlsZSBzaGFy ZWQgbWVtb3J5Cm9wdGlvbnMgICAgICAgICBTWVNWTVNHICAgICAgICAgICAgICAgICAjIFNZ U1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9ucyAgICAgICAgIFNZU1ZTRU0gICAgICAg ICAgICAgICAgICMgU1lTVi1zdHlsZSBzZW1hcGhvcmVzCm9wdGlvbnMgICAgICAgICBfS1BP U0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcgIyBQT1NJWCBQMTAwM18xQiByZWFsLXRpbWUgZXh0 ZW5zaW9ucwpvcHRpb25zICAgICAgICAgS0JEX0lOU1RBTExfQ0RFViAgICAgICAgIyBpbnN0 YWxsIGEgQ0RFViBlbnRyeSBpbiAvZGV2Cm9wdGlvbnMgICAgICAgICBBREFQVElWRV9HSUFO VCAgICAgICAgICAjIEdpYW50IG11dGV4IGlzIGFkYXB0aXZlLgpvcHRpb25zICAgICAgICAg U1RPUF9OTUkgICAgICAgICAgICAgICAgIyBTdG9wIENQVVMgdXNpbmcgTk1JIGluc3RlYWQg b2YgSVBJCm9wdGlvbnMgICAgICAgICBBVURJVCAgICAgICAgICAgICAgICAgICAjIFNlY3Vy aXR5IGV2ZW50IGF1ZGl0aW5nCgojIENQVSBmcmVxdWVuY3kgY29udHJvbApkZXZpY2UgICAg ICAgICAgY3B1ZnJlcQoKIyBCdXMgc3VwcG9ydC4KZGV2aWNlICAgICAgICAgIGVpc2EKZGV2 aWNlICAgICAgICAgIHBjaQoKIyBGbG9wcHkgZHJpdmVzCmRldmljZSAgICAgICAgICBmZGMK CiMgQVRBIGFuZCBBVEFQSSBkZXZpY2VzCmRldmljZSAgICAgICAgICBhdGEKZGV2aWNlICAg ICAgICAgIGF0YWRpc2sgICAgICAgICAjIEFUQSBkaXNrIGRyaXZlcwpkZXZpY2UgICAgICAg ICAgYXRhcmFpZCAgICAgICAgICMgQVRBIFJBSUQgZHJpdmVzCmRldmljZSAgICAgICAgICBh dGFwaWNkICAgICAgICAgIyBBVEFQSSBDRFJPTSBkcml2ZXMKZGV2aWNlICAgICAgICAgIGF0 YXBpZmQgICAgICAgICAjIEFUQVBJIGZsb3BweSBkcml2ZXMKZGV2aWNlICAgICAgICAgIGF0 YXBpc3QgICAgICAgICAjIEFUQVBJIHRhcGUgZHJpdmVzCm9wdGlvbnMgICAgICAgICBBVEFf U1RBVElDX0lEICAgIyBTdGF0aWMgZGV2aWNlIG51bWJlcmluZwoKIyBTQ1NJIHBlcmlwaGVy YWxzCmRldmljZSAgICAgICAgICBzY2J1cyAgICAgICAgICAgIyBTQ1NJIGJ1cyAocmVxdWly ZWQgZm9yIFNDU0kpCmRldmljZSAgICAgICAgICBjaCAgICAgICAgICAgICAgIyBTQ1NJIG1l ZGlhIGNoYW5nZXJzCmRldmljZSAgICAgICAgICBkYSAgICAgICAgICAgICAgIyBEaXJlY3Qg QWNjZXNzIChkaXNrcykKZGV2aWNlICAgICAgICAgIHNhICAgICAgICAgICAgICAjIFNlcXVl bnRpYWwgQWNjZXNzICh0YXBlIGV0YykKZGV2aWNlICAgICAgICAgIGNkICAgICAgICAgICAg ICAjIENECmRldmljZSAgICAgICAgICBwYXNzICAgICAgICAgICAgIyBQYXNzdGhyb3VnaCBk ZXZpY2UgKGRpcmVjdCBTQ1NJIGFjY2VzcykKZGV2aWNlICAgICAgICAgIHNlcyAgICAgICAg ICAgICAjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5kIFNBRi1URSkKCiMgUkFJ RCBjb250cm9sbGVycwpkZXZpY2UgICAgICAgICAgdHdlICAgICAgICAgICAgICMgM3dhcmUg QVRBIFJBSUQKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhl IFBTLzIgbW91c2UKZGV2aWNlICAgICAgICAgIGF0a2JkYyAgICAgICAgICAjIEFUIGtleWJv YXJkIGNvbnRyb2xsZXIKZGV2aWNlICAgICAgICAgIGF0a2JkICAgICAgICAgICAjIEFUIGtl eWJvYXJkCmRldmljZSAgICAgICAgICBwc20gICAgICAgICAgICAgIyBQUy8yIG1vdXNlCgpk ZXZpY2UgICAgICAgICAga2JkbXV4ICAgICAgICAgICMga2V5Ym9hcmQgbXVsdGlwbGV4ZXIK CmRldmljZSAgICAgICAgICB2Z2EgICAgICAgICAgICAgIyBWR0EgdmlkZW8gY2FyZCBkcml2 ZXIKCmRldmljZSAgICAgICAgICBzcGxhc2ggICAgICAgICAgIyBTcGxhc2ggc2NyZWVuIGFu ZCBzY3JlZW4gc2F2ZXIgc3VwcG9ydAoKIyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNv bGUgZHJpdmVyLCByZXNlbWJsaW5nIGFuIFNDTyBjb25zb2xlCmRldmljZSAgICAgICAgICBz YwoKZGV2aWNlICAgICAgICAgIGFncCAgICAgICAgICAgICAjIHN1cHBvcnQgc2V2ZXJhbCBB R1AgY2hpcHNldHMKCiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1cHBvcnQgZm9yIHRoZSBpODI1 NC4KZGV2aWNlICAgICAgICAgIHBtdGltZXIKCiMgU2VyaWFsIChDT00pIHBvcnRzCmRldmlj ZSAgICAgICAgICBzaW8gICAgICAgICAgICAgIyA4MjUwLCAxNls0NV01MCBiYXNlZCBzZXJp YWwgcG9ydHMKZGV2aWNlICAgICAgICAgIHVhcnQgICAgICAgICAgICAjIEdlbmVyaWMgVUFS VCBkcml2ZXIKCiMgUENJIEV0aGVybmV0IE5JQ3MuCmRldmljZSAgICAgICAgICBlbSAgICAg ICAgICAgICAgIyBJbnRlbCBQUk8vMTAwMCBHaWdhYml0IEV0aGVybmV0IEZhbWlseQoKIyBQ Q0kgRXRoZXJuZXQgTklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJvbGxl ciBjb2RlLgojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxp bmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIE5JQ3MhCmRldmljZSAgICAgICAgICBtaWlidXMg ICAgICAgICAgIyBNSUkgYnVzIHN1cHBvcnQKZGV2aWNlICAgICAgICAgIGZ4cCAgICAgICAg ICAgICAjIEludGVsIEV0aGVyRXhwcmVzcyBQUk8vMTAwQiAoODI1NTcsIDgyNTU4KQoKIyBQ c2V1ZG8gZGV2aWNlcy4KZGV2aWNlICAgICAgICAgIGxvb3AgICAgICAgICAgICAjIE5ldHdv cmsgbG9vcGJhY2sKZGV2aWNlICAgICAgICAgIHJhbmRvbSAgICAgICAgICAjIEVudHJvcHkg ZGV2aWNlCmRldmljZSAgICAgICAgICBldGhlciAgICAgICAgICAgIyBFdGhlcm5ldCBzdXBw b3J0CmRldmljZSAgICAgICAgICBzbCAgICAgICAgICAgICAgIyBLZXJuZWwgU0xJUApkZXZp Y2UgICAgICAgICAgcHBwICAgICAgICAgICAgICMgS2VybmVsIFBQUApkZXZpY2UgICAgICAg ICAgdHVuICAgICAgICAgICAgICMgUGFja2V0IHR1bm5lbC4KZGV2aWNlICAgICAgICAgIHB0 eSAgICAgICAgICAgICAjIFBzZXVkby10dHlzICh0ZWxuZXQgZXRjKQpkZXZpY2UgICAgICAg ICAgbWQgICAgICAgICAgICAgICMgTWVtb3J5ICJkaXNrcyIKZGV2aWNlICAgICAgICAgIGdp ZiAgICAgICAgICAgICAjIElQdjYgYW5kIElQdjQgdHVubmVsaW5nCmRldmljZSAgICAgICAg ICBmYWl0aCAgICAgICAgICAgIyBJUHY2LXRvLUlQdjQgcmVsYXlpbmcgKHRyYW5zbGF0aW9u KQpkZXZpY2UgICAgICAgICAgZmlybXdhcmUgICAgICAgICMgZmlybXdhcmUgYXNzaXN0IG1v ZHVsZQoKIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBhY2tldCBG aWx0ZXIuCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVlbmNlcyBv ZiBlbmFibGluZyB0aGlzIQojIE5vdGUgdGhhdCAnYnBmJyBpcyByZXF1aXJlZCBmb3IgREhD UC4KZGV2aWNlICAgICAgICAgIGJwZiAgICAgICAgICAgICAjIEJlcmtlbGV5IHBhY2tldCBm aWx0ZXIKCiMgVVNCIHN1cHBvcnQKZGV2aWNlICAgICAgICAgIHVoY2kgICAgICAgICAgICAj IFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlCmRldmljZSAgICAgICAgICBvaGNpICAgICAgICAg ICAgIyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZpY2UgICAgICAgICAgZWhjaSAgICAg ICAgICAgICMgRUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UgKFVTQiAyLjApCmRldmljZSAgICAg ICAgICB1c2IgICAgICAgICAgICAgIyBVU0IgQnVzIChyZXF1aXJlZCkKI2RldmljZSAgICAg ICAgIHVkYnAgICAgICAgICAgICAjIFVTQiBEb3VibGUgQnVsayBQaXBlIGRldmljZXMKZGV2 aWNlICAgICAgICAgIHVnZW4gICAgICAgICAgICAjIEdlbmVyaWMKZGV2aWNlICAgICAgICAg IHVoaWQgICAgICAgICAgICAjICJIdW1hbiBJbnRlcmZhY2UgRGV2aWNlcyIKZGV2aWNlICAg ICAgICAgIHVrYmQgICAgICAgICAgICAjIEtleWJvYXJkCmRldmljZSAgICAgICAgICB1bHB0 ICAgICAgICAgICAgIyBQcmludGVyCmRldmljZSAgICAgICAgICB1bWFzcyAgICAgICAgICAg IyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGEKZGV2aWNlICAg ICAgICAgIHVtcyAgICAgICAgICAgICAjIE1vdXNlCg== --------------000007020408070003050200-- From c-h at mail.ru Wed Mar 4 04:40:00 2009 From: c-h at mail.ru (Cache) Date: Wed Mar 4 04:40:08 2009 Subject: Help! zpool corrupted! In-Reply-To: <20090303145451.GA76327@hyperion.scode.org> References: <20090303145451.GA76327@hyperion.scode.org> Message-ID: Hello, Peter. I tried to run 'zfs mount main/usr &' and then 'zpool iostat 1'. Read and write operations are all zero. System works as usual, except that 'zfs mount' not done. I can do disk operations such as 'ls' or 'cat /COPYRIGHT' normally. Also I can do 'zfs list' or 'zpool status' without any oddity. In 'ps wwaux' output many spa_zio and USBPROC processes with DL status - I don't know what it means. I attached some info - outputs of 'dmesg', 'ps wwaux', 'zpool status -v', 'zfs list' after starting 'zfs mount main/usr &'. I think (just assume after reading Sun's ZFS admin manual) that :<0x5b> error prevents datasets mounting. Any ideas how to correct this problem? -----Original Message----- From: Peter Schuller To: Cache Date: Tue, 3 Mar 2009 15:54:51 +0100 Subject: Re: Help! zpool corrupted! > Can you run "iostat -x 1" while while youre zfs mount -a hangs? It > will probably indicate that there is 100% disk utilization on the disk > in question, indicating there is one or more I/O request(s) > outstanding to the device, indicating a > driver/controller/cabling/drive problem. > > If on the other hand 'zfs mount -a' hangs but there is no ongoing > attempts at disk I/O according to iostat, there may be a software > problem with zfs or something else, although since you have confirmed > disk-related issues it might have been triggered by actual on-disk > corruption. > > -- > / Peter Schuller > > PGP userID: 0xE9758B7D or 'Peter Schuller ' > Key retrieval: Send an E-Mail to getpgpkey@scode.org > E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org > > > ATTACHMENT: application/pgp-signature > -------------- next part -------------- pool: main state: ONLINE status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'. see: http://www.sun.com/msg/ZFS-8000-JQ scrub: none requested config: NAME STATE READ WRITE CKSUM main ONLINE 0 0 1 ad4s1d ONLINE 0 0 6 errors: Permanent errors have been detected in the following files: :<0x5b> main/var:/db/pkg/libgnomeprintui-2.18.3/+CONTENTS main/var:/db/pkg/libpurple-2.5.4/+CONTENTS main/var:/db/pkg/foomatic-db-engine-20070124,1/+REQUIRED_BY main/var:/log/debug.log main/var:/db/pkg/gsfonts-8.11_4/+REQUIRED_BY main/var:/db/pkg/omegaT-1.7.3.4/+CONTENTS main/var:/db/pkg/orage-4.4.3/+CONTENTS main/var:/db/pkg/p5-Gtk2-1.200_1/+CONTENTS main/var:/db/pkg/freealut-1.1.0_1/+REQUIRED_BY main/var:/db/pkg/pcb-20080202_3/+CONTENTS main/var:/log/messages.4 main/var:/db/pkg/XaraLX-0.7r1692_6/+CONTENTS main/var:/db/pkg/apache-ant-1.7.0_2/+CONTENTS main/var:/db/pkg/iceauth-1.0.2/+REQUIRED_BY main/var:/db/pkg/brlcad-7.12.6/+CONTENTS main/var:/db/pkg/dia-gnome-0.96.1_6,1/+CONTENTS main/var:/db/pkg/py25-opengl-3.0.0.b8_1/+CONTENTS main/var:/db/pkg/gucharmap-2.24.3/+REQUIRED_BY main/var:/db/pkg/firefox-3.0.6,1/+CONTENTS main/var:/db/pkg/qt-3.3.8_9/+CONTENTS main/var:/db/pkg/ru-openoffice.org-3.0.1/+CONTENTS main/var:/db/pkg/graphviz-2.20.3_2/+REQUIRED_BY main/var:/db/pkg/fontsproto-2.0.2/+REQUIRED_BY main/var:/db/pkg/pkgdb.db main/var:/db/pkg/thunderbird-2.0.0.19_1/+CONTENTS main/var:/db/pkg/transmission-gtk2-1.42/+CONTENTS main/var:/db/pkg/gnome-icon-theme-2.24.0_2/+CONTENTS main/var:/db/pkg/gnome-libs-1.4.2_12/+CONTENTS main/var:/db/pkg/gnumeric-1.9.3_2/+CONTENTS main/var:/db/pkg/goffice-0.4.3_5/+CONTENTS main/var:/db/pkg/foomatic-db-20070124_2/+REQUIRED_BY main/var:/db/pkg/gqview-2.0.4_5/+CONTENTS main/var:/db/pkg/graphviz-2.20.3_2/+CONTENTS main/var:/db/pkg/xfce4-mcs-plugins-4.4.3/+CONTENTS main/var:/db/pkg/hal-0.5.11_17/+REQUIRED_BY main/var:/db/pkg/cups-base-1.3.9_3/+CONTENTS main/var:/db/pkg/gnome_subr-1.0/+REQUIRED_BY main/var:/db/pkg/gtkmathview-0.8.0/+CONTENTS main/var:/db/pkg/hicolor-icon-theme-0.10_2/+REQUIRED_BY main/var:/db/pkg/gtksourceview2-2.4.2/+CONTENTS main/var:/db/pkg/xfce4-taskmanager-0.4.0.r2_8/+CONTENTS main/var:/db/pkg/gsm-1.0.12_1/+REQUIRED_BY main/var:/log/messages main/var:/db/pkg/xfce4-wm-4.4.3/+CONTENTS main/var:/db/pkg/gstreamer-0.10.22_1/+REQUIRED_BY main/var:/db/pkg/kicad-20080825/+CONTENTS main/var:/db/pkg/kompozer-0.7.10_3/+CONTENTS main/var:/db/pkg/fontconfig-2.6.0,1/+REQUIRED_BY main/usr:<0x2a36> main/usr:/obj/usr/src/rescue/rescue/usr/src/bin/sh main/usr:/local/share/sgml/docbook/4.4/dbpoolx.mod main/usr/ports:/misc/shared-mime-info/work/shared-mime-info-0.60/po/fi.po main/usr/ports:/misc/shared-mime-info/work/shared-mime-info-0.60/configure main/usr/ports:/devel/py-gobject/work/pygobject-2.16.1/gio/pygio-utils.h main/usr/ports:/devel/py-gobject/work/pygobject-2.16.1/gio/unix.defs main/usr/ports:/sysutils/hal/work/gnome-libtool.bak main/usr/ports:/misc/shared-mime-info/work/shared-mime-info-0.60/freedesktop.org.xml main/usr/ports/distfiles:/shared-mime-info-0.60.tar.bz2 main/usr/ports/distfiles:/xorg/lib/libXi-1.2.1.tar.bz2 main/usr/ports/distfiles:/gnome2/pygobject-2.16.1.tar.bz2 main/usr/home:/cache/.mozilla/firefox/5sp68nv8.default/places.sqlite main/usr/home:/cache/.mozilla/firefox/5sp68nv8.default/urlclassifier3.sqlite main/usr/home:/cache/.mozilla/firefox/5sp68nv8.default/prefs.js main/usr/home:/cache/.mozilla/firefox/5sp68nv8.default/Cache/_CACHE_003_ -------------- next part -------------- USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11 100.0 0.0 0 32 ?? RL 5:31PM 11:07.03 [idle] root 0 0.0 0.0 0 144 ?? DLs 5:31PM 0:00.03 [kernel] root 1 0.0 0.0 2176 412 ?? ILs 5:31PM 0:00.00 /sbin/init -s root 2 0.0 0.0 0 16 ?? DL 5:31PM 0:00.02 [g_event] root 3 0.0 0.0 0 16 ?? DL 5:31PM 0:00.02 [g_up] root 4 0.0 0.0 0 16 ?? DL 5:31PM 0:00.02 [g_down] root 5 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [xpt_thrd] root 6 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [cbb0 event thread] root 7 0.0 0.0 0 16 ?? IL 5:31PM 0:00.00 [fw0_probe] root 8 0.0 0.0 0 24 ?? DL 5:31PM 0:00.00 [sctp_iterator] root 9 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [pagedaemon] root 10 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [audit] root 12 0.0 0.0 0 272 ?? WL 5:31PM 0:00.36 [intr] root 13 0.0 0.0 0 32 ?? DL 5:31PM 0:00.00 [ng_queue] root 14 0.0 0.0 0 16 ?? DL 5:31PM 0:00.02 [yarrow] root 15 0.0 0.0 0 16 ?? DL 5:31PM 0:00.03 [acpi_thermal] root 16 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 17 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 18 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 19 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 20 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 21 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 22 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 23 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 24 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 25 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 26 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 27 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 28 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 29 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 30 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 31 0.0 0.0 0 16 ?? DL 5:31PM 0:00.01 [USBPROC] root 32 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 33 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 34 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 35 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 36 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [USBPROC] root 37 0.0 0.0 0 16 ?? DL 5:31PM 0:00.02 [USBPROC] root 38 0.0 0.0 0 16 ?? DL 5:31PM 0:00.01 [USBPROC] root 39 0.0 0.0 0 16 ?? DL 5:31PM 0:00.01 [USBPROC] root 40 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [vmdaemon] root 41 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [pagezero] root 42 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [bufdaemon] root 43 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [syncer] root 44 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [vnlru] root 45 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [softdepflush] root 48 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [system_taskq] root 49 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [system_taskq] root 50 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [arc_reclaim_thread] root 51 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [l2arc_feed_thread] root 80 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 81 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 82 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 83 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 84 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 85 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 86 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 87 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 88 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 89 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 90 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 91 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 92 0.0 0.0 0 16 ?? DL 5:31PM 0:00.01 [spa_zio] root 93 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 94 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 95 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 96 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 97 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 98 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 99 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 100 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 101 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 102 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 103 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 104 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 105 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [spa_zio] root 106 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [vdev:worker ad4s1d] root 107 0.0 0.0 0 16 ?? DL 5:31PM 0:00.00 [txg_thread_enter] root 108 0.0 0.0 0 28 ?? DL 5:31PM 0:00.00 [txg_thread_enter] root 46 0.0 0.0 7140 1472 v0 Ss 5:31PM 0:00.02 -sh (sh) root 109 0.0 0.0 13500 1940 v0 D 5:32PM 0:00.00 zfs mount main/usr root 139 0.0 0.0 6884 1400 v0 R+ 5:46PM 0:00.00 ps wwaux -------------- next part -------------- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Wed Jan 28 02:57:14 MSK 2009 cache@cache:/usr/obj/usr/src/sys/GX710.8 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (798.00-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f81 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 4284018688 (4085 MB) avail memory = 4120371200 (3929 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001690400) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001690400) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001690400) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001690400) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001690400) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001690400) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001690400) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff0001691760), AE_NOT_EXIST acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb0ff mem 0xd0000000-0xdfffffff,0xfd6f0000-0xfd6fffff irq 18 at device 0.0 on pci1 acpi_video0: on vgapci0 hdac0: mem 0xfd6ec000-0xfd6effff irq 19 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20090126_0126 hdac0: [ITHREAD] pcib2: at device 4.0 on pci0 pci2: on pcib2 ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 on pci2 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 14.2 phy 7.0 radio 10.2 pcib3: at device 6.0 on pci0 pci3: on pcib3 pcib4: at device 7.0 on pci0 pci5: on pcib4 re0: port 0xc800-0xc8ff mem 0xfe2ff000-0xfe2fffff irq 19 at device 0.0 on pci5 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:4b:18:11 re0: [FILTER] atapci0: port 0xa000-0xa007,0x9000-0x9003,0x8000-0x8007,0x7000-0x7003,0x6000-0x600f mem 0xfd5ff800-0xfd5ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfd5fe000-0xfd5fefff irq 16 at device 19.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfd5fd000-0xfd5fdfff irq 17 at device 19.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xfd5fc000-0xfd5fcfff irq 18 at device 19.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ohci3: mem 0xfd5fb000-0xfd5fbfff irq 17 at device 19.3 on pci0 ohci3: [ITHREAD] usbus3: on ohci3 ohci4: mem 0xfd5fa000-0xfd5fafff irq 18 at device 19.4 on pci0 ohci4: [ITHREAD] usbus4: on ohci4 ehci0: mem 0xfd5ff000-0xfd5ff0ff irq 19 at device 19.5 on pci0 ehci0: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci0 ichsmb0: port 0xb00-0xb0f at device 20.0 on pci0 ichsmb0: can't map I/O device_attach: ichsmb0 attach returned 6 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac1: mem 0xfd5f4000-0xfd5f7fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20090126_0126 hdac1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci6: on pcib5 cbb0: irq 20 at device 4.0 on pci6 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] pci6: at device 4.2 (no driver attached) pci6: at device 4.3 (no driver attached) fwohci0: <1394 Open Host Controller Interface> mem 0xfe3fd000-0xfe3fdfff,0xfe3ff000-0xfe3ff7ff irq 20 at device 4.4 on pci6 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:dc:10:00:af:43:34:01 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x160c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:dc:10:43:34:01 fwe0: Ethernet address: 02:dc:10:43:34:01 fwip0: on firewire0 fwip0: Firewire address: 00:dc:10:00:af:43:34:01 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode k8temp0: on hostb4 acpi_button0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 orm0: at iomem 0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 ugen4.1: at usbus4 ushub0: on usbus4 ugen5.1: at usbus5 ushub1: on usbus5 ugen0.1: at usbus0 ushub2: on usbus0 ugen1.1: at usbus1 ushub3: on usbus1 ugen2.1: at usbus2 ushub4: on usbus2 ugen3.1: at usbus3 ushub5: on usbus3 acd0: DVDR at ata0-master UDMA33 ad4: 238475MB at ata2-master SATA150 ushub0: 2 ports with 2 removable, self powered ushub2: 2 ports with 2 removable, self powered ushub3: 2 ports with 2 removable, self powered ushub4: 2 ports with 2 removable, self powered ushub5: 2 ports with 2 removable, self powered hdac0: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC888 hdac1: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a ushub1: 10 ports with 10 removable, self powered usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_alloc_device:1401: set address 2 failed (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen5.2: <> at usbus5 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_alloc_device:1401: set address 2 failed (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen3.2: <> at usbus3 (disconnected) uhub_reattach_port:413: could not allocate new device! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_alloc_device:1401: set address 2 failed (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_alloc_device:1436: getting device descriptor at addr 2 failed! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1366: addr=2, set address failed! (ignored) usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_req_re_enumerate:1379: getting device descriptor at addr 2 failed! ugen3.2: <> at usbus3 (disconnected) uhub_reattach_port:413: could not allocate new device! This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 -------------- next part -------------- NAME USED AVAIL REFER MOUNTPOINT main 199G 25.3G 18K /main main/cache 26.0G 25.3G 26.0G none main/root 82.5M 25.3G 82.5M /root main/tmp 2.25G 25.3G 2.25G none main/usr 171G 25.3G 6.05G /usr main/usr/home 158G 25.3G 158G /test main/usr/ports 6.95G 25.3G 2.88G /usr/ports main/usr/ports/distfiles 3.46G 25.3G 3.46G /usr/ports/distfiles main/usr/ports/packages 626M 25.3G 626M /usr/ports/packages main/usr/src 144K 25.3G 144K /usr/src main/var 210M 25.3G 210M /var From linimon at FreeBSD.org Wed Mar 4 17:38:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 4 17:38:46 2009 Subject: kern/131353: [geom] gjournal(8) kernel lock Message-ID: <200903050138.n251cYuG053483@freefall.freebsd.org> Synopsis: [geom] gjournal(8) kernel lock Responsible-Changed-From-To: freebsd-fs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 5 01:38:19 UTC 2009 Responsible-Changed-Why: Probably a more appropriate assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=131353 From linimon at FreeBSD.org Wed Mar 4 23:29:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 4 23:29:11 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903050729.n257T3J2046353@freefall.freebsd.org> Synopsis: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Thu Mar 5 07:28:23 UTC 2009 State-Changed-Why: To submitter: can you test the patch on 8-CURRENT? http://www.freebsd.org/cgi/query-pr.cgi?pr=132068 From linimon at lonesome.com Thu Mar 5 02:30:07 2009 From: linimon at lonesome.com (Mark Linimon) Date: Thu Mar 5 02:30:13 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903051030.n25AU6jU094492@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: Mark Linimon To: linimon@FreeBSD.org Cc: 7ogcg7g02@sneakemail.com, bug-followup@FreeBSD.org Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: Thu, 5 Mar 2009 04:27:38 -0600 On Thu, Mar 05, 2009 at 07:29:03AM +0000, linimon@FreeBSD.org wrote: > To submitter: can you test the patch on 8-CURRENT? Er, what I *should* have said is: can you either test the patch, or try 8-CURRENT, which has the patch in it? mcl From 7ogcg7g02 at sneakemail.com Thu Mar 5 03:50:04 2009 From: 7ogcg7g02 at sneakemail.com (Edward Fisk) Date: Thu Mar 5 03:50:16 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903051150.n25Bo4K2056407@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: "Edward Fisk" <7ogcg7g02@sneakemail.com> To: bug-followup@freebsd.org Cc: Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: 5 Mar 2009 11:46:25 -0000 I've tried the patch kindly supplied by Jaakko, but the machine still deadlocks (no panic though). I then did a source upgrade to 8.0-CURRENT (20090227). The machine would still deadlock every 1-2 hours under the same load. I've now added the following deadlock debugging options: options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC Unfortunately, the machine has now been running for over 48 hours without a crash, while still being under the same load/usage pattern. -Ed From 7ogcg7g02 at sneakemail.com Thu Mar 5 03:50:06 2009 From: 7ogcg7g02 at sneakemail.com (Edward Fisk) Date: Thu Mar 5 03:50:17 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903051150.n25Bo6Vn056440@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: "Edward Fisk" <7ogcg7g02@sneakemail.com> To: bug-followup@freebsd.org Cc: Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: 5 Mar 2009 11:47:54 -0000 kern/129174 looks like a similar problem just to clarify, the clients using my system use both NFS2 and NFS3 From 7ogcg7g02 at sneakemail.com Thu Mar 5 04:00:16 2009 From: 7ogcg7g02 at sneakemail.com (Edward Fisk) Date: Thu Mar 5 04:00:23 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903051200.n25C0GN7063361@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: "Edward Fisk" <7ogcg7g02@sneakemail.com> To: bug-followup@freebsd.org Cc: Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: 5 Mar 2009 11:50:41 -0000 The machine did a panic earlier, but was unfortunately unable to do a dump. ------ panic: Bad link elm 0xffffff014f3e2400 prev->next != elm cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 xprt_unregister_locked() at xprt_unregister_locked+0xad xprt_unregister() at xprt_unregister+0x2c svc_run_internal() at svc_run_internal+0x42f svc_run() at svc_run+0x94 nfssvc_nfsd() at nfssvc_nfsd+0xa2 nfssvc() at nfssvc+0x12d syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xab --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x800695c4c, rsp = 0x7fffffffe8e8, rbp = 0 --- Uptime: 3d4h21m8s Physical memory: 16368 MB Dumping 3849 MB: 3834 3818 3802 3786 3770 3754 3738 3722 3706 3690Error dumping block 0x0 ** DUMP FAILED (ERROR 5) ** aac0: shutting down controller...FAILED. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ------ Any idea as to why it was unable to complete the crash dump? From linimon at lonesome.com Thu Mar 5 07:30:06 2009 From: linimon at lonesome.com (Mark Linimon) Date: Thu Mar 5 07:30:21 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903051530.n25FU5Qh022885@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: Thu, 5 Mar 2009 09:29:11 -0600 ----- Forwarded message from Edward Fisk <7ogcg7g02@sneakemail.com> ----- To: freebsd-bugs@FreeBSD.org From: Edward Fisk <7ogcg7g02@sneakemail.com> Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 I tried with the patch kindly provided by Jaakko. The machine would no longer panic, but would instead deadlock every 1-2 hours when in use. I then did a source upgrade to 8-CURRENT (27022008) with a GENERIC kernel, which had the same result: a deadlock every 1 to 2 hours when in use. The machine is now running a GENERIC kernel with the following options added: options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC Unfortunately, I've yet to be able to get it to deadlock, despite the workload on the machine not having changed. ----- End forwarded message ----- From linimon at lonesome.com Thu Mar 5 07:30:09 2009 From: linimon at lonesome.com (Mark Linimon) Date: Thu Mar 5 07:30:21 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903051530.n25FU87g023142@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: Thu, 5 Mar 2009 09:29:39 -0600 ----- Forwarded message from Edward Fisk <7ogcg7g02@sneakemail.com> ----- To: freebsd-bugs@FreeBSD.org From: Edward Fisk <7ogcg7g02@sneakemail.com> Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 kern/129174 looks like a similar problem, altohugh there's not much useful information there ----- End forwarded message ----- From linimon at FreeBSD.org Thu Mar 5 07:32:14 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Mar 5 07:32:26 2009 Subject: kern/132331: [ufs] [lor] LOR ufs and syncer Message-ID: <200903051532.n25FWDpC030695@freefall.freebsd.org> Old Synopsis: LOR ufs and syncer New Synopsis: [ufs] [lor] LOR ufs and syncer Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 5 15:31:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132331 From linimon at FreeBSD.org Thu Mar 5 07:33:55 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Mar 5 07:34:06 2009 Subject: kern/132337: [zfs] [panic] kernel panic in zfs_fuid_create_cred Message-ID: <200903051533.n25FXovU031535@freefall.freebsd.org> Old Synopsis: kernel panic in zfs_fuid_create_cred New Synopsis: [zfs] [panic] kernel panic in zfs_fuid_create_cred Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 5 15:33:31 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132337 From weldon at excelsus.com Thu Mar 5 08:10:30 2009 From: weldon at excelsus.com (Weldon S Godfrey 3) Date: Thu Mar 5 08:10:37 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 In-Reply-To: <200903051530.n25FU87g023142@freefall.freebsd.org> References: <200903051530.n25FU87g023142@freefall.freebsd.org> Message-ID: <20090305103355.B17525@emmett.excelsus.com> If memory serves me right, sometime around 3:30pm, Mark Linimon told me: > The following reply was made to PR kern/132068; it has been noted by GNATS. > > From: Mark Linimon > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on > 7.1-RELEASE/amd64 > Date: Thu, 5 Mar 2009 09:29:39 -0600 > > ----- Forwarded message from Edward Fisk <7ogcg7g02@sneakemail.com> ----- > > To: freebsd-bugs@FreeBSD.org > From: Edward Fisk <7ogcg7g02@sneakemail.com> > Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on > 7.1-RELEASE/amd64 > > kern/129174 looks like a similar problem, altohugh there's not much > useful information there > > ----- End forwarded message ----- > _______________________________________________ Are you using v3 NFS or v2? Switching to v2 has made things MUCH more stable for me, however, I still loose stability with ZIL enabled (even if prefetch is disabled)(and ZIL disabled is NOT desirable as I know the potential client side corruption with that, but so far I haven't run into that). I currently have ZIL and prefetch disabled. I currently limit ARC to 2GB as well and set kmem to 4GB (I currently am using FreeBSD 8) I am up to about 1.5 weeks without a panic now. The system does a constant 80-120Mb/s in read and 30Mb/s write/s during the day and has 9 NFS clients. Weldon From pluknet at gmail.com Thu Mar 5 09:00:08 2009 From: pluknet at gmail.com (pluknet) Date: Thu Mar 5 09:00:14 2009 Subject: kern/132337: [zfs] [panic] kernel panic in zfs_fuid_create_cred In-Reply-To: <200903051533.n25FXovU031535@freefall.freebsd.org> References: <200903051533.n25FXovU031535@freefall.freebsd.org> Message-ID: 2009/3/5 : > Old Synopsis: kernel panic in zfs_fuid_create_cred > New Synopsis: [zfs] [panic] kernel panic in zfs_fuid_create_cred > > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > Responsible-Changed-By: linimon > Responsible-Changed-When: Thu Mar 5 15:33:31 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=132337 > _______________________________________________ > 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" > btw, something was changed there in opensolaris (per bug_id=6754013). 477,480c477,485 < if (type == ZFS_OWNER) < id = crgetuid(cr); < else < id = crgetgid(cr); --- > ksid = crgetsid(cr, (type == ZFS_OWNER) ? KSID_OWNER : KSID_GROUP); > if (ksid) { > id = ksid_getid(ksid); > } else { > if (type == ZFS_OWNER) > id = crgetuid(cr); > else > id = crgetgid(cr); > } 482c487 < if (!zfsvfs->z_use_fuids || !IS_EPHEMERAL(id)) --- > if (!zfsvfs->z_use_fuids || (!IS_EPHEMERAL(id))) 485,487d489 < ksid = crgetsid(cr, (type == ZFS_OWNER) ? KSID_OWNER : KSID_GROUP); < < VERIFY(ksid != NULL); -- wbr, pluknet From linimon at lonesome.com Thu Mar 5 11:30:05 2009 From: linimon at lonesome.com (Mark Linimon) Date: Thu Mar 5 11:30:11 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903051930.n25JU4OV005620@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: Thu, 5 Mar 2009 13:26:45 -0600 ----- Forwarded message from Weldon S Godfrey 3 ----- From: Weldon S Godfrey 3 To: Mark Linimon cc: freebsd-fs@FreeBSD.org Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Are you using v3 NFS or v2? Switching to v2 has made things MUCH more stable for me, however, I still loose stability with ZIL enabled (even if prefetch is disabled)(and ZIL disabled is NOT desirable as I know the potential client side corruption with that, but so far I haven't run into that). I currently have ZIL and prefetch disabled. I currently limit ARC to 2GB as well and set kmem to 4GB (I currently am using FreeBSD 8) I am up to about 1.5 weeks without a panic now. The system does a constant 80-120Mb/s in read and 30Mb/s write/s during the day and has 9 NFS clients. Weldon ----- End forwarded message ----- From martin at email.aon.at Sat Mar 7 01:30:07 2009 From: martin at email.aon.at (Martin Birgmeier) Date: Sat Mar 7 01:30:13 2009 Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load Message-ID: <200903070930.n279U6QH033309@freefall.freebsd.org> The following reply was made to PR kern/131360; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131360: [nfs] poor scaling behavior of the NFS server under load Date: Sat, 7 Mar 2009 10:23:54 +0100 (CET) Robert, Thanks for taking this. First off, the previous message I wrote (about similar problems with samba) might in fact also be caused by NFS - samba is running on this server, but it was configured to serve a directory which itself is served by amd(8) on this server. Now to your questions: device/driver (grep sis /var/run/dmesg.boot): sis0: port 0xa400-0xa4ff mem 0xd5800000-0xd5800fff irq 9 at device 9.0 on pci0 sis0: Silicon Revision: DP83815D miibus0: on sis0 sis0: Ethernet address: 00:40:f4:1a:42:ba sis0: [ITHREAD] sis0: Applying short cable fix (reg=f4) sis0: Applying short cable fix (reg=f5) mount: It is what amd(8) instructs it to be, and from running tcpdump I believe it is over TCP. From ktk at netlabs.org Mon Mar 9 03:00:11 2009 From: ktk at netlabs.org (Adrian Gschwend) Date: Mon Mar 9 03:00:45 2009 Subject: kernel panic while writing to a ZFS volume on iSCSI LUN In-Reply-To: <20090224150217.GA15114@carrot> References: <660f28ee8aa9c3a76b7d736e5ae3c229.squirrel@mail.netlabs.org> <20090224150217.GA15114@carrot> Message-ID: Ulf Lilleengen wrote: > This is a problem with ZFS due to exhaustion of the kernel memory address > space (ZFS is quite hungry for memory). This can be solved by finely tuning > the different limits specified here: > > http://wiki.freebsd.org/ZFSTuningGuide > > You might have to do some try and fail to get it to work, but my experience > is that the problems is usually solveable if you invest enough time in the > tuning. thanks looks like I found the correct settings for the moment. Performance is pretty bad though but at least it doesn't crash anymore :) cu Adrian -- Adrian Gschwend @ netlabs.org ktk [a t] netlabs.org ------- Open Source Project http://www.netlabs.org From jh at saunalahti.fi Mon Mar 9 08:14:03 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Mon Mar 9 08:14:09 2009 Subject: [patch] invalidate NFS attribute cache if setattr fails with ESTALE In-Reply-To: <200902192210.n1JMAddn009074@svn.freebsd.org> References: <200902192210.n1JMAddn009074@svn.freebsd.org> Message-ID: <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> Hi, Here is a patch which changes nfs_setattrrpc() to invalidate the NFS attribute cache in case the RPC failed with ESTALE. The issue was originally reported by Timo Sirainen in PR kern/123755: > NFS client: open() a file > NFS server: unlink() the file > NFS client: fchown() the file -> ESTALE (as expected) > NFS client: fstat() the file -> success (not expected) %%% Index: sys/nfsclient/nfs_vnops.c =================================================================== --- sys/nfsclient/nfs_vnops.c (revision 188842) +++ sys/nfsclient/nfs_vnops.c (working copy) @@ -838,6 +838,10 @@ nfs_setattrrpc(struct vnode *vp, struct nfsm_loadattr(vp, NULL); m_freem(mrep); nfsmout: + /* Invalidate the attribute cache if the NFS file handle is stale. */ + if (error == ESTALE) + np->n_attrstamp = 0; + return (error); } %%% Could someone take a look if this could be committed? -- Jaakko From rmacklem at uoguelph.ca Mon Mar 9 09:29:38 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Mar 9 09:29:45 2009 Subject: [patch] invalidate NFS attribute cache if setattr fails with ESTALE In-Reply-To: <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> References: <200902192210.n1JMAddn009074@svn.freebsd.org> <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> Message-ID: On Mon, 9 Mar 2009, Jaakko Heinonen wrote: > > Hi, > > Here is a patch which changes nfs_setattrrpc() to invalidate the NFS > attribute cache in case the RPC failed with ESTALE. > > The issue was originally reported by Timo Sirainen in PR kern/123755: > >> NFS client: open() a file >> NFS server: unlink() the file >> NFS client: fchown() the file -> ESTALE (as expected) >> NFS client: fstat() the file -> success (not expected) > > %%% > Index: sys/nfsclient/nfs_vnops.c > =================================================================== > --- sys/nfsclient/nfs_vnops.c (revision 188842) > +++ sys/nfsclient/nfs_vnops.c (working copy) > @@ -838,6 +838,10 @@ nfs_setattrrpc(struct vnode *vp, struct > nfsm_loadattr(vp, NULL); > m_freem(mrep); > nfsmout: > + /* Invalidate the attribute cache if the NFS file handle is stale. */ > + if (error == ESTALE) > + np->n_attrstamp = 0; > + > return (error); > } > > %%% > > Could someone take a look if this could be committed? > I'm not a committer, but I think that it might be appropriate to invalidate the attribute cache for any ESTALE reply from a server. (Since ESTALE implies that the file no linger exists on the server, I can't think why the attribute cache should remain valid for anything.) There is already code in nfs_request() that purges the name cache for ESTALE and I think that invalidating the cache there too, might make sense? For example, a patch something like... *** nfs_krpc.c.sav Sun Mar 8 23:45:35 2009 --- nfs_krpc.c Sun Mar 8 23:47:12 2009 *************** *** 520,527 **** * If the File Handle was stale, invalidate the lookup * cache, just in case. */ ! if (error == ESTALE) cache_purge(vp); /* * Skip wcc data on NFS errors for now. NetApp filers * return corrupt postop attrs in the wcc data for NFS --- 520,529 ---- * If the File Handle was stale, invalidate the lookup * cache, just in case. */ ! if (error == ESTALE) { cache_purge(vp); + VTONFS(vp)->n_attrstamp = 0; + } /* * Skip wcc data on NFS errors for now. NetApp filers * return corrupt postop attrs in the wcc data for NFS *** nfs_socket.c.sav Mon Mar 9 00:11:51 2009 --- nfs_socket.c Mon Mar 9 00:12:32 2009 *************** *** 1363,1370 **** * If the File Handle was stale, invalidate the * lookup cache, just in case. */ ! if (error == ESTALE) cache_purge(vp); /* * Skip wcc data on NFS errors for now. NetApp filers return corrupt * postop attrs in the wcc data for NFS err EROFS. Not sure if they --- 1363,1372 ---- * If the File Handle was stale, invalidate the * lookup cache, just in case. */ ! if (error == ESTALE) { cache_purge(vp); + VTONFS(vp)->n_attrstamp = 0; + } /* * Skip wcc data on NFS errors for now. NetApp filers return corrupt * postop attrs in the wcc data for NFS err EROFS. Not sure if they rick From bugmaster at FreeBSD.org Mon Mar 9 10:15:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 9 10:15:59 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200903091715.n29HF3W2045226@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/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] 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/129174 fs [nfs] [zfs] [panic] NFS v3 Panic when under high load o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129084 fs [udf] [panic] [lor] udf panic: getblk: size(67584) > M 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po 46 problems total. From gavin at FreeBSD.org Mon Mar 9 13:36:27 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Mar 9 13:36:33 2009 Subject: kern/132397: reboot causes filesystem corruption (failure to sync buffers/vnodes) Message-ID: <200903092036.n29KaQSk009748@freefall.freebsd.org> Old Synopsis: reboot causes filesystem corruption New Synopsis: reboot causes filesystem corruption (failure to sync buffers/vnodes) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Mon Mar 9 20:29:53 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) who may be able to at least answer some of these questions. http://www.freebsd.org/cgi/query-pr.cgi?pr=132397 From mike at reifenberger.com Tue Mar 10 04:49:40 2009 From: mike at reifenberger.com (Michael Reifenberger) Date: Tue Mar 10 04:49:56 2009 Subject: speedup "zpool scrub" under current. Message-ID: Hi, is there a way to speed up `zpool scrub` under current. It needs ages for scrubbing... It looks like: (ws3)(root) # zpool iostat 1 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- r 39,5G 95,5G 21 5 1,49M 22,4K r 39,5G 95,5G 106 56 13,0M 173K r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 19 23 1,92M 113K r 39,5G 95,5G 479 0 30,8M 0 r 39,5G 95,5G 204 112 11,7M 841K r 39,5G 95,5G 252 0 15,1M 0 r 39,5G 95,5G 108 62 5,58M 181K r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 ... Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From dudu at dudu.ro Tue Mar 10 18:11:39 2009 From: dudu at dudu.ro (Vlad GALU) Date: Tue Mar 10 18:11:46 2009 Subject: Fwd: Can't create files on sshfs mount In-Reply-To: References: Message-ID: Hi, I'm trying my luck with the below issue. Sorry for the noise. ---------- Forwarded message ---------- From: Vlad GALU Date: Wed, Mar 11, 2009 at 2:41 AM Subject: Can't create files on sshfs mount To: fuse4bsd-devel@creo.hu Hi. I've just installed the latest FUSE/sshfs ports on my RELENG_7, and I mounted a remote directory. Creating directories on the remote volume succeeds, but issuing an open() with O_CREAT yields EBADF (which shouldn't really happen). open()ing already existing files also succeeds. Any ideas? -- ~/.signature: no such file or directory From freebsd at discordia.ch Wed Mar 11 09:10:04 2009 From: freebsd at discordia.ch (Peter Keel) Date: Wed Mar 11 09:10:11 2009 Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load Message-ID: <200903111610.n2BGA3V5056747@freefall.freebsd.org> The following reply was made to PR kern/131360; it has been noted by GNATS. From: Peter Keel To: bug-followup@FreeBSD.org, martin@email.aon.at Cc: Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load Date: Wed, 11 Mar 2009 17:03:36 +0100 Addendum: - Changing the scheduler yielded nothing, as you expected. - This was over TCP, we never used UDP. We mounted the systems with these options: rw,nfsv3,tcp,intr,nolockd,bg - The ethernet-device drivers are "em" on all machines. em0: Regards Peter -- "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin "It's also true that those who would give up privacy for security are likely to end up with neither." -- Bruce Schneier From guido at gvr.org Wed Mar 11 15:15:27 2009 From: guido at gvr.org (Guido van Rooij) Date: Wed Mar 11 15:15:33 2009 Subject: RFC: geli+gmirror problem + solution Message-ID: <20090311215518.GA25410@gvr.gvr.org> We have a setup where we have two disks in a gmirror with GELI on top of it. We boot from it (using a small unencrypted USB stick). We this have the G_ELI_FLAG_BOOT set. Anyway, when rebooting, geli does not detach and this the gmirror is never destroyed resulting in a rebuild each time. I just commited a fix for this (set the G_ELI_FLAG_WO_DETACH in g_eli_taste(). However, this seems to break zfs as zfs might actually close the geli device and later opening it (but it is then no longer there). We must therefor make this configurable. I thus propose to be able to set the G_ELI_FLAG_WO_DETACH in the geli- metadata, just like the G_ELI_FLAG_BOOT flag. This would mean an extra option to geli init, say the -d flag. Any objections? -Guido From linimon at FreeBSD.org Wed Mar 11 23:22:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 11 23:22:56 2009 Subject: kern/132551: [zfs] ZFS locks up on extattr_list_link syscall Message-ID: <200903120622.n2C6MmRE070010@freefall.freebsd.org> Old Synopsis: ZFS locks up on extattr_list_link syscall New Synopsis: [zfs] ZFS locks up on extattr_list_link syscall Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 12 06:22:35 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132551 From jhb at freebsd.org Thu Mar 12 06:58:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Mar 12 06:58:46 2009 Subject: [patch] invalidate NFS attribute cache if setattr fails with ESTALE In-Reply-To: References: <200902192210.n1JMAddn009074@svn.freebsd.org> <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> Message-ID: <200903120837.08170.jhb@freebsd.org> On Monday 09 March 2009 12:34:33 pm Rick Macklem wrote: > > On Mon, 9 Mar 2009, Jaakko Heinonen wrote: > > > > > Hi, > > > > Here is a patch which changes nfs_setattrrpc() to invalidate the NFS > > attribute cache in case the RPC failed with ESTALE. > > > > The issue was originally reported by Timo Sirainen in PR kern/123755: > > > >> NFS client: open() a file > >> NFS server: unlink() the file > >> NFS client: fchown() the file -> ESTALE (as expected) > >> NFS client: fstat() the file -> success (not expected) > > > > %%% > > Index: sys/nfsclient/nfs_vnops.c > > =================================================================== > > --- sys/nfsclient/nfs_vnops.c (revision 188842) > > +++ sys/nfsclient/nfs_vnops.c (working copy) > > @@ -838,6 +838,10 @@ nfs_setattrrpc(struct vnode *vp, struct > > nfsm_loadattr(vp, NULL); > > m_freem(mrep); > > nfsmout: > > + /* Invalidate the attribute cache if the NFS file handle is stale. */ > > + if (error == ESTALE) > > + np->n_attrstamp = 0; > > + > > return (error); > > } > > > > %%% > > > > Could someone take a look if this could be committed? > > > I'm not a committer, but I think that it might be appropriate to > invalidate the attribute cache for any ESTALE reply from a server. > (Since ESTALE implies that the file no linger exists on the server, > I can't think why the attribute cache should remain valid for anything.) > > There is already code in nfs_request() that purges the name cache for > ESTALE and I think that invalidating the cache there too, might make > sense? I think we should purge the access cache too? I just put this in my p4 branch yesterday (it also has a merge of your changes to expand the per-node access cache, so the access cache clearing is a bit larger than it would be otherwise): --- //depot/projects/smpng/sys/nfs4client/nfs4_socket.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfs4client/nfs4_socket.c 2009/03/11 22:15:03 @@ -259,7 +259,7 @@ ** lookup cache, just in case. **/ if (error == ESTALE) - cache_purge(vp); + nfs_purgecache(vp); return (error); } --- //depot/projects/smpng/sys/nfsclient/nfs.h 2008/11/18 23:25:45 +++ //depot/user/jhb/lock/nfsclient/nfs.h 2009/03/11 22:15:03 @@ -319,6 +322,7 @@ #endif /* ! NFS4_USE_RPCCLNT */ #endif +void nfs_purgecache(struct vnode *); int nfs_vinvalbuf(struct vnode *, int, struct thread *, int); int nfs_readrpc(struct vnode *, struct uio *, struct ucred *); int nfs_writerpc(struct vnode *, struct uio *, struct ucred *, int *, --- //depot/projects/smpng/sys/nfsclient/nfs_krpc.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfsclient/nfs_krpc.c 2009/03/11 22:15:03 @@ -521,7 +521,7 @@ * cache, just in case. */ if (error == ESTALE) - cache_purge(vp); + nfs_purgecache(vp); /* * Skip wcc data on NFS errors for now. NetApp filers * return corrupt postop attrs in the wcc data for NFS --- //depot/projects/smpng/sys/nfsclient/nfs_socket.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfsclient/nfs_socket.c 2009/03/11 22:15:03 @@ -1364,7 +1364,7 @@ * lookup cache, just in case. */ if (error == ESTALE) - cache_purge(vp); + nfs_purgecache(vp); /* * Skip wcc data on NFS errors for now. NetApp filers return corrupt * postop attrs in the wcc data for NFS err EROFS. Not sure if they --- //depot/projects/smpng/sys/nfsclient/nfs_subs.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfsclient/nfs_subs.c 2009/03/11 22:15:03 @@ -826,6 +826,27 @@ return (0); } +/* + * Purge all cached information about an NFS vnode including name + * cache entries, the attribute cache, and the access cache. This is + * called when an NFS request for a node fails with a stale + * filehandle. + */ +void +nfs_purgecache(struct vnode *vp) +{ + struct nfsnode *np; + int i; + + np = VTONFS(vp); + cache_purge(vp); + mtx_lock(&np->n_mtx); + np->n_attrstamp = 0; + for (i = 0; i < NFS_ACCESSCACHESIZE; i++) + np->n_accesscache[i].stamp = 0; + mtx_unlock(&np->n_mtx); +} + static nfsuint64 nfs_nullcookie = { { 0, 0 } }; /* * This function finds the directory cookie that corresponds to the -- John Baldwin From pjd at FreeBSD.org Thu Mar 12 12:58:39 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Mar 12 12:58:46 2009 Subject: RFC: geli+gmirror problem + solution In-Reply-To: <20090311215518.GA25410@gvr.gvr.org> References: <20090311215518.GA25410@gvr.gvr.org> Message-ID: <20090312195904.GA1786@garage.freebsd.pl> On Wed, Mar 11, 2009 at 10:55:18PM +0100, Guido van Rooij wrote: > We have a setup where we have two disks in a gmirror with GELI on top > of it. We boot from it (using a small unencrypted USB stick). > We this have the G_ELI_FLAG_BOOT set. > > Anyway, when rebooting, geli does not detach and this the gmirror is > never destroyed resulting in a rebuild each time. > > I just commited a fix for this (set the G_ELI_FLAG_WO_DETACH in g_eli_taste(). > However, this seems to break zfs as zfs might actually close the geli device > and later opening it (but it is then no longer there). > > We must therefor make this configurable. > > I thus propose to be able to set the G_ELI_FLAG_WO_DETACH in the geli- > metadata, just like the G_ELI_FLAG_BOOT flag. This would mean an > extra option to geli init, say the -d flag. > > Any objections? I'd suggest not to do it. Maybe you could implement detaching on reboot for geli providers? You can find example of how to do this in three last functions in sys/geom/mirror/g_mirror.c. Could you send me patches to review before committing? -- 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/20090312/ef3dd2c6/attachment.pgp From ssrbarry at comcast.net Thu Mar 12 16:19:28 2009 From: ssrbarry at comcast.net (Sean Barry) Date: Thu Mar 12 16:19:34 2009 Subject: UFS Configuration Question Message-ID: <00ba01c9a367$2aa0a5a0$7fe1f0e0$@net> Hello, Is it possible to configure the file system driver to Not record the time and date stamp metadata? I will be starting a personal project of setting up a NAS server using FreeNas. This will be a file storage and I do not have a need for extra metadata information. Thank you, Sean Barry From ticso at cicely7.cicely.de Thu Mar 12 16:47:23 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Mar 12 16:47:34 2009 Subject: UFS Configuration Question In-Reply-To: <00ba01c9a367$2aa0a5a0$7fe1f0e0$@net> References: <00ba01c9a367$2aa0a5a0$7fe1f0e0$@net> Message-ID: <20090312234710.GZ63112@cicely7.cicely.de> On Thu, Mar 12, 2009 at 06:06:24PM -0500, Sean Barry wrote: > Hello, > Is it possible to configure the file system driver to Not record the time > and date stamp metadata? > > I will be starting a personal project of setting up a NAS server using > FreeNas. This will be a file storage and I do not have a need for extra > metadata information. This is part of the inode, where file size and such is also noted. You don't win anything by not saveing modtime. However, you can mount using -noatime, so the the inode won't get updated on read access. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From avg at freebsd.org Fri Mar 13 11:09:38 2009 From: avg at freebsd.org (Andriy Gapon) Date: Fri Mar 13 11:09:45 2009 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <4922FB81.50608@icyb.net.ua> References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> <4922FB81.50608@icyb.net.ua> Message-ID: <49BA9E93.4060609@freebsd.org> Very belated but somebody reading archives might find this useful. Only today I discovered zdb command and its -C option: $ zdb -C tank version=6 name='tank' state=0 txg=1997530 pool_guid=15723282379537418671 hostid=714261228 hostname='' vdev_tree type='root' id=0 guid=15723282379537418671 children[0] type='disk' id=0 guid=1732303387090405178 path='/dev/ad6s2d' devid='ad:GEA534RF0TK35A' whole_disk=0 metaslab_array=14 metaslab_shift=32 ashift=9 asize=493659881472 DTL=182 on 18/11/2008 19:29 Andriy Gapon said the following: > I just remembered that I saved old zpool.cache file before "migrating" > the pool. > I looked at the diff of hexdumps and there are a number of differences, > it's hard to understand them because the file is binary (actually it > seems to contain serialized name-value pairs), but one difference is > prominent: > ... > 00000260 64 65 76 69 64 00 00 00 00 00 00 09 00 00 00 01 > |devid...........| > ... > -00000270 00 00 00 15 61 64 3a 47 45 41 35 33 34 52 46 30 > |....ad:GEA534RF0| > -00000280 54 4b 33 35 41 73 31 73 33 00 00 00 00 00 00 28 > |TK35As1s3......(| > ... > +00000270 00 00 00 11 61 64 3a 47 45 41 35 33 34 52 46 30 > |....ad:GEA534RF0| > +00000280 54 4b 33 35 41 00 00 00 00 00 00 28 00 00 00 28 > |TK35A......(...(| > ... > > It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new one > is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is ad6s2d. > > The new value is what is reported by diskinfo: > $ diskinfo -v ad6 > ad6 > ... > ad:GEA534RF0TK35A # Disk ident. > > $ diskinfo -v ad6s2 > ad6s2 > ... > ad:GEA534RF0TK35A # Disk ident. > > $ diskinfo -v ad6s2d > ad6s2d > ... > ad:GEA534RF0TK35A # Disk ident. > > Hmm, "indent" is reported to be the same for all three entities. > > I don't remember what diskinfo reported with pre-gpart kernel, but I > suspect that it was something different. > Could anybody please check this? (on 7.X machine without GEOM_PART). > > I quickly glimpsed through sources and it seems that this comes from > DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that > geom_slice.c code has some special handling for that. > -- Andriy Gapon From linimon at FreeBSD.org Fri Mar 13 13:05:51 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Mar 13 13:05:57 2009 Subject: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Message-ID: <200903132005.n2DK5oVn043744@freefall.freebsd.org> Old Synopsis: tmpfs-related panic while interrupting a port build on tmpfs WRKDIR New Synopsis: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 13 20:05:22 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132597 From james-freebsd-fs2 at jrv.org Fri Mar 13 14:30:13 2009 From: james-freebsd-fs2 at jrv.org (James R. Van Artsdalen) Date: Fri Mar 13 14:30:20 2009 Subject: ZFS recv doesn't properly skip existing snapshots Message-ID: <49BAD057.6060602@jrv.org> /home/james# uname -a FreeBSD bigtex.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r189099: Fri Feb 27 07:09:47 CST 2009 james@bigtex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 "zfs recv" doesn't properly skip existing snapshots in a replication stream. I'm working on a way to keep a remote pool in sync with a local pool using zfs send/recv. It appears that "zfs recv" may not be atomic across the input stream but only within each individual filesystem. This means that the pool replication script must be prepared to handle the situation where a parent filesystem may have received a snapshot that a child did not. It appears "zfs recv" is supposed to simply skip any snapshot it already has, making me think that it should pick up at the next snapshot record in the input stream. But instead "zfs recv" appears to never get in sync with the input stream again and simple exits. Comments embedded with hashed below. /home/james# zfs create bigtex/foo /home/james# zfs create bigtex/foo/bar /home/james# zfs snapshot -r bigtex/foo@a /home/james# zfs snapshot -r bigtex/foo@b /home/james# zfs snapshot -r bigtex/foo@c /home/james# zfs snapshot -r bigtex/foo@d /home/james# zfs list -t snapshot ... bigtex/foo@a 0 - 18K - bigtex/foo@b 0 - 18K - bigtex/foo@c 0 - 18K - bigtex/foo@d 0 - 18K - bigtex/foo/bar@a 0 - 18K - bigtex/foo/bar@b 0 - 18K - bigtex/foo/bar@c 0 - 18K - bigtex/foo/bar@d 0 - 18K - # send initial data. Works as expected. /home/james# /root/zfs send -v -R bigtex/foo@b | /root/zfs recv -dv bigtmptex sending from @ to bigtex/foo@a receiving full stream of bigtex/foo@a into bigtmptex/foo@a sending from @a to bigtex/foo@b sending from @ to bigtex/foo/bar@a sending from @a to bigtex/foo/bar@b received 13.6KB stream in 1 seconds (13.6KB/sec) receiving incremental stream of bigtex/foo@b into bigtmptex/foo@b received 312B stream in 1 seconds (312B/sec) receiving full stream of bigtex/foo/bar@a into bigtmptex/foo/bar@a received 13.6KB stream in 1 seconds (13.6KB/sec) receiving incremental stream of bigtex/foo/bar@b into bigtmptex/foo/bar@b received 312B stream in 1 seconds (312B/sec) # send incremental update. Works as expected. /home/james# /root/zfs send -RvI @b bigtex/foo@d | /root/zfs recv -dvF bigtmptex sending from @b to bigtex/foo@c sending from @c to bigtex/foo@d sending from @b to bigtex/foo/bar@c sending from @c to bigtex/foo/bar@d receiving incremental stream of bigtex/foo@c into bigtmptex/foo@c received 312B stream in 1 seconds (312B/sec) receiving incremental stream of bigtex/foo@d into bigtmptex/foo@d received 312B stream in 1 seconds (312B/sec) receiving incremental stream of bigtex/foo/bar@c into bigtmptex/foo/bar@c received 312B stream in 1 seconds (312B/sec) receiving incremental stream of bigtex/foo/bar@d into bigtmptex/foo/bar@d received 312B stream in 1 seconds (312B/sec) # The results are correct. /home/james# zfs list -t snapshot ... bigtex/foo@a 0 - 18K - bigtex/foo@b 0 - 18K - bigtex/foo@c 0 - 18K - bigtex/foo@d 0 - 18K - bigtex/foo/bar@a 0 - 18K - bigtex/foo/bar@b 0 - 18K - bigtex/foo/bar@c 0 - 18K - bigtex/foo/bar@d 0 - 18K - bigtmptex/foo@a 0 - 18K - bigtmptex/foo@b 0 - 18K - bigtmptex/foo@c 0 - 18K - bigtmptex/foo@d 0 - 18K - bigtmptex/foo/bar@a 0 - 18K - bigtmptex/foo/bar@b 0 - 18K - bigtmptex/foo/bar@c 0 - 18K - bigtmptex/foo/bar@d 0 - 18K - # pretend that the incremental send/recv above was interrupted after bigtex/foo@d was received but before bigtex/foo/bar@d /home/james# zfs destroy bigtmptex/foo/bar@d # a clever script might realize that we need to start at @c because @d has not been received by some child filesystems. But zfs recv doesn't work right. /home/james# /root/zfs send -RvI @c bigtex/foo@d | /root/zfs recv -dvF bigtmptex sending from @c to bigtex/foo@d receiving incremental stream of bigtex/foo@d into bigtmptex/foo@d snap bigtmptex/foo@d already exists; ignoring sending from @c to bigtex/foo/bar@d warning: cannot send 'bigtex/foo/bar@d': Broken pipe /home/james# zfs list -t snapshot ... bigtmptex/foo@a 0 - 18K - bigtmptex/foo@b 0 - 18K - bigtmptex/foo@c 0 - 18K - bigtmptex/foo@d 0 - 18K - bigtmptex/foo/bar@a 0 - 18K - bigtmptex/foo/bar@b 0 - 18K - bigtmptex/foo/bar@c 0 - 18K - From ota at j.email.ne.jp Fri Mar 13 21:50:04 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Fri Mar 13 21:50:10 2009 Subject: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Message-ID: <200903140450.n2E4o3to011990@freefall.freebsd.org> The following reply was made to PR kern/132597; it has been noted by GNATS. From: Yoshihiro Ota To: bug-followup@FreeBSD.org Cc: bf2006a@yahoo.com Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Date: Sat, 14 Mar 2009 00:42:58 -0400 Which ports were you compiling when panic happened? Hiro From pho at freebsd.org Sat Mar 14 03:48:20 2009 From: pho at freebsd.org (Peter Holm) Date: Sat Mar 14 03:48:27 2009 Subject: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR In-Reply-To: <200903140450.n2E4o3to011990@freefall.freebsd.org> References: <200903140450.n2E4o3to011990@freefall.freebsd.org> Message-ID: <20090314102135.GA93077@x2.osted.lan> On Sat, Mar 14, 2009 at 04:50:03AM +0000, Yoshihiro Ota wrote: > The following reply was made to PR kern/132597; it has been noted by GNATS. > > From: Yoshihiro Ota > To: bug-followup@FreeBSD.org > Cc: bf2006a@yahoo.com > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while > interrupting a port build on tmpfs WRKDIR > Date: Sat, 14 Mar 2009 00:42:58 -0400 > > Which ports were you compiling when panic happened? > > Hiro The panic in this PR looks a lot like the one I reported to attilio@ http://people.freebsd.org/~pho/stress/log/attilio022.txt It was just regular FS load that provoked it. -- Peter From bf2006a at yahoo.com Sat Mar 14 10:40:02 2009 From: bf2006a at yahoo.com (bf) Date: Sat Mar 14 10:40:30 2009 Subject: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Message-ID: <200903141740.n2EHe2GE049922@freefall.freebsd.org> The following reply was made to PR kern/132597; it has been noted by GNATS. From: bf To: Yoshihiro Ota Cc: bug-followup@FreeBSD.org Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Date: Sat, 14 Mar 2009 10:31:07 -0700 (PDT) --- On Sat, 3/14/09, Yoshihiro Ota wrote: > From: Yoshihiro Ota > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR > To: bug-followup@FreeBSD.org > Cc: bf2006a@yahoo.com > Date: Saturday, March 14, 2009, 12:42 AM > Which ports were you compiling when panic happened? > > Hiro I see now that I confused your response with my other related PR, which I had just filed before I received your message. I had been building a number of ports, so I do not now recall which one it was, sorry. I will say that a panic of this kind, despite the other recent serious problems with tmpfs, is rare: I have only seen one such panic in about a year of heavy use of a tmpfs /tmp for building ports. That is why I didn't use a higher priority when filing the PR. Regards, b. From kostikbel at gmail.com Sat Mar 14 13:32:23 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Mar 14 13:32:30 2009 Subject: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR In-Reply-To: <20090314102135.GA93077@x2.osted.lan> References: <200903140450.n2E4o3to011990@freefall.freebsd.org> <20090314102135.GA93077@x2.osted.lan> Message-ID: <20090314203215.GA41617@deviant.kiev.zoral.com.ua> On Sat, Mar 14, 2009 at 11:21:35AM +0100, Peter Holm wrote: > On Sat, Mar 14, 2009 at 04:50:03AM +0000, Yoshihiro Ota wrote: > > The following reply was made to PR kern/132597; it has been noted by GNATS. > > > > From: Yoshihiro Ota > > To: bug-followup@FreeBSD.org > > Cc: bf2006a@yahoo.com > > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while > > interrupting a port build on tmpfs WRKDIR > > Date: Sat, 14 Mar 2009 00:42:58 -0400 > > > > Which ports were you compiling when panic happened? > > > > Hiro > > The panic in this PR looks a lot like the one I reported to attilio@ > > http://people.freebsd.org/~pho/stress/log/attilio022.txt > > It was just regular FS load that provoked it. It seems to be quite clean what is going on there. In fact, there are two issues: First is the usual problem of DOTDOT lookup that shall be fixed in style of vn_vget_ino() by busying mp before unlocking dvp. Second one is the reason for the panic. The tmpfs vnode is unlocked, and then corresponding tmpfs _node_ is passed to the tmpfs_alloc_vp(). Since the vnode may be reclaimed after the unlock, passed node might become freed. Then, the tmpfs_alloc_vp() would operate on the freed memory. -------------- 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/20090314/f06d2720/attachment.pgp From ady at freebsd.ady.ro Sun Mar 15 12:37:39 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Mar 15 12:37:45 2009 Subject: ETA for ZFS v. 13 Merge From HEAD ? Message-ID: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> Hi Pawel, Coming back to the subject, when do you think we might have a merge of r185029 (import of ZFS version 13) from head back into -stable ? Is there anything we can help with to speed up the process (e.g. testing) ? PS: ZFS-FUSE on Linux has also reached v 13... Thank you, Adrian Penisoara ROFUG / EnterpriseBSD --------------------------- Date: Wed, 26 Nov 2008 10:52:41 +0100 From: Pawel Jakub Dawidek Subject: Re: svn commit: r185029 - in head: cddl/compat/opensolaris/include cddl/compat/opensolaris/misc cddl/contrib/opensolaris/cmd/zdb cddl/contrib/opensolaris/cmd/zfs cddl/contrib/opensolaris/cmd/zinject cd... To: Attila Nagy Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Message-ID: <20081126095241.GA3188@garage.freebsd.pl> Content-Type: text/plain; charset="us-ascii" On Wed, Nov 26, 2008 at 10:15:58AM +0100, Attila Nagy wrote: > Hello, > > Pawel Jakub Dawidek wrote: > >Author: pjd > >Date: Mon Nov 17 20:49:29 2008 > >New Revision: 185029 > >URL: http://svn.freebsd.org/changeset/base/185029 > > > >Log: > > Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes. > > > This, and other changes stabilized ZFS by a great level in HEAD. > Do you plan to MFC these to 7-STABLE? Yes, but ETA yet. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! From ken at mthelicon.com Sun Mar 15 15:40:02 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Sun Mar 15 15:40:08 2009 Subject: ETA for ZFS v. 13 Merge From HEAD ? In-Reply-To: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> References: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> Message-ID: <4AE4493D5E9141E8812E4BC83FB5A2A5@PegaPegII> Hi Adrian, I am not sure, but I didnt think ZFS 13 was ever going to be merged into 7-stable. I thought the kernel memory requirements were to great (just going back in my memory on that one). Also, I think there are still a few bugs left with the zil being enabled (and/or prefetch) causing lockups on machine with a lot of IO. I know I have hit that bug a few times on my machine when using various torrent clients when they want to preallocate large amounts of diskspace. I personally cant wait until a later version of ZFS is imported that supports encryption. I can finally say good-bye to our GEOM ELI USB drives for backups!! Never the less, I am quite thankfull to thoes involved in porting V13 to FreeBSD. Its a wonderfull improvement and my FS of choice when installing on new machines (especially zfs boot) Best regards, Peg ----- Original Message ----- From: "Adrian Penisoara" To: "Pawel Jakub Dawidek" Cc: ; Sent: Sunday, March 15, 2009 7:09 PM Subject: ETA for ZFS v. 13 Merge From HEAD ? > Hi Pawel, > Coming back to the subject, when do you think we might have a merge of > r185029 (import of ZFS version 13) from head back into -stable ? > > Is there anything we can help with to speed up the process (e.g. testing) > ? > > PS: ZFS-FUSE on Linux has also reached v 13... > > Thank you, > Adrian Penisoara > ROFUG / EnterpriseBSD > > --------------------------- > Date: Wed, 26 Nov 2008 10:52:41 +0100 > From: Pawel Jakub Dawidek > Subject: Re: svn commit: r185029 - in head: > cddl/compat/opensolaris/include cddl/compat/opensolaris/misc > cddl/contrib/opensolaris/cmd/zdb > cddl/contrib/opensolaris/cmd/zfs > cddl/contrib/opensolaris/cmd/zinject cd... > To: Attila Nagy > Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, > src-committers@freebsd.org > Message-ID: <20081126095241.GA3188@garage.freebsd.pl> > Content-Type: text/plain; charset="us-ascii" > > On Wed, Nov 26, 2008 at 10:15:58AM +0100, Attila Nagy wrote: >> Hello, >> >> Pawel Jakub Dawidek wrote: >> >Author: pjd >> >Date: Mon Nov 17 20:49:29 2008 >> >New Revision: 185029 >> >URL: http://svn.freebsd.org/changeset/base/185029 >> > >> >Log: >> > Update ZFS from version 6 to 13 and bring some FreeBSD-specific > changes. >> > >> This, and other changes stabilized ZFS by a great level in HEAD. >> Do you plan to MFC these to 7-STABLE? > > Yes, but ETA yet. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From bugmaster at FreeBSD.org Mon Mar 16 04:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 16 04:07:49 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200903161106.n2GB6rCl043227@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/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] 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/129174 fs [nfs] [zfs] [panic] NFS v3 Panic when under high load o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129084 fs [udf] [panic] [lor] udf panic: getblk: size(67584) > M 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po 49 problems total. From zbeeble at gmail.com Mon Mar 16 11:09:08 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon Mar 16 11:09:15 2009 Subject: ETA for ZFS v. 13 Merge From HEAD ? In-Reply-To: <4AE4493D5E9141E8812E4BC83FB5A2A5@PegaPegII> References: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> <4AE4493D5E9141E8812E4BC83FB5A2A5@PegaPegII> Message-ID: <5f67a8c40903161109le12b8afuc25b8c1ec1b6f70c@mail.gmail.com> On Sun, Mar 15, 2009 at 6:39 PM, Pegasus Mc Cleaft wrote: > Hi Adrian, > > I am not sure, but I didnt think ZFS 13 was ever going to be merged into > 7-stable. I thought the kernel memory requirements were to great (just going > back in my memory on that one). Also, I think there are still a few bugs > left with the zil being enabled (and/or prefetch) causing lockups on machine > with a lot of IO. I know I have hit that bug a few times on my machine when > using various torrent clients when they want to preallocate large amounts of > diskspace. > > I personally cant wait until a later version of ZFS is imported that > supports encryption. I can finally say good-bye to our GEOM ELI USB drives > for backups!! Never the less, I am quite thankfull to thoes involved in > porting V13 to FreeBSD. Its a wonderfull improvement and my FS of choice > when installing on new machines (especially zfs boot) I think that you're touching on two entirely separate points here... What it takes to upgrade ZFS in -STABLE and what it takes to bring ZFS modules in to FreeBSD. I sincerely hope that ZFSv13 is planned for -STABLE. Last we left this issue, testing and a few kernel improvements were in the way. None of the kernel improvements were going to change the API, so the project was doable in -STABLE. That said, time marches on, 8.0-RELEASE draws ever nearer. When we were still several years out on 8.0 and ZFS was causing me more problems, I was much more keen to push for the port. I would still welcome it with open arms, but I'm not convinced that anyone is going to push it forward. The issue of encryption (along with many other issues) is tied to the ability of FreeBSD to compile and use ZFS modules. Just like netgraph modules extend the function of netgraph.ko and geom modules extend the base geom function, ZFS is designed (in Solaris, at least) to take modules. ZFS encryption is a module. I'm not clear on compression --- it would make sense that it is a module, but it seemingly got copied into FreeBSD as a core feature (and it may also be so in solaris). Anyways... is there any plans to allow for ZFS modules in FreeBSD? From toasty at dragondata.com Tue Mar 17 16:04:59 2009 From: toasty at dragondata.com (Kevin Day) Date: Tue Mar 17 16:05:07 2009 Subject: zio->io_cv deadlock In-Reply-To: <8E12CEFC-25DE-4B82-97BD-7ED717650089@dragondata.com> References: <8E12CEFC-25DE-4B82-97BD-7ED717650089@dragondata.com> Message-ID: I've got a test environment where I can make this deadlock happen within 3-4 hours of use now. This is from -CURRENT as of yesterday. This server isn't trying to use zfs on root, so when it hangs I'm not quite as bad off. Here's a ps output: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PPID CPU PRI NI MWCHAN SL RE PAGEIN LIM TSIZ root 477 0.0 0.0 2180 656 ?? Is 9:34AM 0:00.00 /sbin/ devd 0 1 0 44 0 select 127 127 0 - 336 root 593 0.0 0.0 5780 1444 ?? Is 9:35AM 0:00.05 /usr/ sbin/syslog 0 1 0 44 0 select 21 127 0 - 36 root 811 0.0 0.0 24872 4172 ?? Is 9:35AM 0:00.00 /usr/ sbin/sshd 0 1 0 44 0 select 127 127 0 - 220 root 837 0.0 0.0 6836 1532 ?? Is 9:35AM 0:00.07 /usr/ sbin/cron - 0 1 0 44 0 nanslp 27 127 0 - 36 root 974 0.0 0.0 8232 2484 ?? Ss 9:38AM 1:19.01 screen 0 1 0 44 0 select 0 127 6 - 292 root 1612 0.0 0.0 38852 7856 ?? Ss 2:49PM 0:00.16 sshd: root@pts/0 0 811 0 44 0 select 0 127 0 - 220 root 1617 0.0 0.0 10188 2792 0 Is 2:49PM 0:00.01 -csh (csh) 0 1612 0 47 0 pause 127 127 0 - 304 root 1622 0.0 0.0 8232 2132 0 S+ 2:49PM 0:00.03 screen - x 0 1617 0 44 0 pause 1 127 0 - 292 root 975 0.0 0.0 10188 2704 1 Is 9:38AM 0:00.01 /bin/ csh 0 974 0 49 0 pause 127 127 0 - 304 root 980 0.0 1.1 794196 766248 1 D+ 9:38AM 66:50.20 rsync - ravH root 0 975 0 69 0 zio->i 127 127 1 - 344 root 982 0.0 0.2 181844 142444 1 I+ 9:38AM 69:32.28 rsync - ravH root 0 980 0 44 0 select 57 127 0 - 344 root 983 0.0 0.0 10188 2788 2 Ss 9:38AM 0:00.01 /bin/ csh 0 974 0 44 0 pause 0 127 0 - 304 root 1 0.0 0.0 2176 596 ?? ILs 9:34AM 0:00.01 /sbin/ init -- 0 0 0 44 0 wait 127 127 8 - 604 root 827 0.0 0.0 10796 3800 ?? Ss 9:35AM 0:00.50 sendmail: accept 0 1 0 44 0 select 3 127 1 - 628 smmsp 831 0.0 0.0 10796 3844 ?? Is 9:35AM 0:00.01 sendmail: Queue 25 1 0 44 0 pause 127 127 0 - 628 root 887 0.0 0.0 5776 1224 v0 Is+ 9:35AM 0:00.01 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 0 - 20 root 888 0.0 0.0 5776 1224 v1 Is+ 9:35AM 0:00.00 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 0 - 20 root 889 0.0 0.0 5776 1224 v2 Is+ 9:35AM 0:00.01 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 0 - 20 root 890 0.0 0.0 5776 1224 v3 Is+ 9:35AM 0:00.00 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 2 - 20 root 891 0.0 0.0 5776 1224 v4 Is+ 9:35AM 0:00.01 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 0 - 20 root 892 0.0 0.0 5776 1224 v5 Is+ 9:35AM 0:00.01 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 0 - 20 root 893 0.0 0.0 5776 1224 v6 Is+ 9:35AM 0:00.01 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 0 - 20 root 894 0.0 0.0 5776 1224 v7 Is+ 9:35AM 0:00.01 /usr/ libexec/get 0 1 0 76 0 ttyin 127 127 0 - 20 root 981 0.0 0.0 27668 11220 1 S+ 9:38AM 172:25.63 ssh -l root 216. 0 980 0 44 0 select 1 127 0 - 120 root 2112 0.0 0.0 6892 1416 2 R+ 6:48PM 0:00.00 ps auxwwlv 0 983 0 44 0 - 127 0 0 - 28 root 0 0.0 0.0 0 128 ?? DLs 9:34AM 46:56.19 [kernel] 0 0 0 -68 0 - 127 127 0 - 0 root 2 0.0 0.0 0 16 ?? DL 9:34AM 0:01.23 [g_event] 0 0 0 -8 0 - 0 127 0 - 0 root 3 0.0 0.0 0 16 ?? DL 9:34AM 0:26.74 [g_up] 0 0 0 -8 0 - 0 127 0 - 0 root 4 0.0 0.0 0 16 ?? DL 9:34AM 5:51.49 [g_down] 0 0 0 -8 0 - 0 127 0 - 0 root 5 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [xpt_thrd] 0 0 0 -16 0 ccb_sc 127 127 0 - 0 root 6 0.0 0.0 0 16 ?? DL 9:34AM 0:00.14 [fdc0] 0 0 0 -16 0 - 0 127 0 - 0 root 7 0.0 0.0 0 24 ?? DL 9:34AM 0:00.00 [sctp_iterator] 0 0 0 -16 0 waitin 127 127 0 - 0 root 8 0.0 0.0 0 16 ?? DL 9:34AM 0:00.03 [pagedaemon] 0 0 0 -16 0 psleep 4 127 0 - 0 root 9 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [vmdaemon] 0 0 0 -16 0 psleep 127 127 0 - 0 root 10 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [audit] 0 0 0 -16 0 audit_ 127 127 0 - 0 root 11 800.0 0.0 0 128 ?? RL 9:34AM 3958:43.82 [idle] 0 0 0 171 0 - 127 127 0 - 0 root 12 0.0 0.0 0 400 ?? WL 9:34AM 6:03.01 [intr] 0 0 0 -60 0 - 127 127 0 - 0 root 13 0.0 0.0 0 16 ?? DL 9:34AM 0:44.77 [yarrow] 0 0 0 44 0 - 0 127 0 - 0 root 14 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [usbus0] 0 0 0 -64 0 wmsg 127 127 0 - 0 root 15 0.0 0.0 0 16 ?? DL 9:34AM 0:00.92 [usbus0] 0 0 0 -68 0 wmsg 2 127 0 - 0 root 16 0.0 0.0 0 16 ?? DL 9:34AM 0:00.56 [usbus0] 0 0 0 -68 0 wmsg 2 127 0 - 0 root 17 0.0 0.0 0 16 ?? DL 9:34AM 0:00.55 [usbus0] 0 0 0 -64 0 wmsg 2 127 0 - 0 root 18 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [usbus1] 0 0 0 -64 0 wmsg 127 127 0 - 0 root 19 0.0 0.0 0 16 ?? DL 9:34AM 0:00.92 [usbus1] 0 0 0 -68 0 wmsg 2 127 0 - 0 root 20 0.0 0.0 0 16 ?? DL 9:34AM 0:00.52 [usbus1] 0 0 0 -68 0 wmsg 2 127 0 - 0 root 21 0.0 0.0 0 16 ?? DL 9:34AM 0:00.60 [usbus1] 0 0 0 -64 0 wmsg 2 127 0 - 0 root 22 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [pagezero] 0 0 0 76 0 pgzero 127 127 0 - 0 root 23 0.0 0.0 0 16 ?? DL 9:34AM 0:00.14 [bufdaemon] 0 0 0 -16 0 psleep 0 127 0 - 0 root 24 0.0 0.0 0 16 ?? DL 9:34AM 0:24.78 [syncer] 0 0 0 44 0 zfsvfs 127 127 0 - 0 root 25 0.0 0.0 0 16 ?? DL 9:34AM 0:02.17 [vnlru] 0 0 0 44 0 vlruwt 0 127 0 - 0 root 26 0.0 0.0 0 16 ?? DL 9:34AM 0:00.21 [softdepflush] 0 0 0 -16 0 sdflus 0 127 0 - 0 root 88 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 89 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 90 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 91 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 92 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 93 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 94 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 95 0.0 0.0 0 16 ?? DL 9:34AM 0:00.00 [system_taskq] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 104 0.0 0.0 0 16 ?? DL 9:34AM 5:11.71 [arc_reclaim_thr 0 0 0 44 0 arc_re 0 127 0 - 0 root 105 0.0 0.0 0 16 ?? DL 9:34AM 0:00.15 [l2arc_feed_thre 0 0 0 -16 0 l2arc_ 0 127 0 - 0 root 936 0.0 0.0 0 16 ?? DL 9:37AM 0:00.55 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 937 0.0 0.0 0 16 ?? DL 9:37AM 0:00.17 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 938 0.0 0.0 0 16 ?? DL 9:37AM 0:00.00 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 939 0.0 0.0 0 16 ?? DL 9:37AM 0:08.89 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 940 0.0 0.0 0 16 ?? DL 9:37AM 0:31.71 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 941 0.0 0.0 0 16 ?? DL 9:37AM 0:08.91 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 942 0.0 0.0 0 16 ?? DL 9:37AM 0:08.76 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 943 0.0 0.0 0 16 ?? DL 9:37AM 0:08.79 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 944 0.0 0.0 0 16 ?? DL 9:37AM 0:09.21 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 945 0.0 0.0 0 16 ?? DL 9:37AM 0:08.83 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 946 0.0 0.0 0 16 ?? DL 9:37AM 0:08.88 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 947 0.0 0.0 0 16 ?? DL 9:37AM 1:34.28 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 948 0.0 0.0 0 16 ?? DL 9:37AM 1:34.28 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 949 0.0 0.0 0 16 ?? DL 9:37AM 1:34.25 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 950 0.0 0.0 0 16 ?? DL 9:37AM 1:34.30 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 951 0.0 0.0 0 16 ?? DL 9:37AM 1:34.74 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 952 0.0 0.0 0 16 ?? DL 9:37AM 1:34.38 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 953 0.0 0.0 0 16 ?? DL 9:37AM 1:34.36 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 954 0.0 0.0 0 16 ?? DL 9:37AM 1:34.14 [spa_zio] 0 0 0 44 0 tq->tq 127 127 0 - 0 root 955 0.0 0.0 0 16 ?? DL 9:37AM 2:46.35 [spa_zio] 0 0 0 44 0 zfsvfs 127 127 0 - 0 root 956 0.0 0.0 0 16 ?? DL 9:37AM 0:00.00 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 957 0.0 0.0 0 16 ?? DL 9:37AM 0:00.00 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 958 0.0 0.0 0 16 ?? DL 9:37AM 0:00.00 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 959 0.0 0.0 0 16 ?? DL 9:37AM 0:00.00 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 960 0.0 0.0 0 16 ?? DL 9:37AM 0:00.00 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 961 0.0 0.0 0 16 ?? DL 9:37AM 0:00.11 [spa_zio] 0 0 0 -16 0 tq->tq 127 127 0 - 0 root 962 0.0 0.0 0 16 ?? DL 9:37AM 0:24.24 [vdev:worker da1 0 0 0 44 0 vgeom: 127 127 0 - 0 root 963 0.0 0.0 0 16 ?? DL 9:37AM 0:00.21 [txg_thread_ente 0 0 0 -16 0 tx->tx 127 127 0 - 0 root 964 0.0 0.0 0 28 ?? DL 9:37AM 1:19.07 [txg_thread_ente 0 0 0 44 0 tx->tx 127 127 0 - 0 root 965 0.0 0.0 0 16 ?? DL 9:37AM 0:12.34 [zil_clean] 0 0 0 -16 0 tq->tq 127 127 0 - 0 Note that syncer and one spa_zio are stuck in zfsvfs, and my rsync process is frozen in zio->io_cv. zpool makes everything look okay: cs03# zpool iostat -v capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- z 549G 13.0T 14 133 709K 12.9M da1 549G 13.0T 14 133 709K 12.9M ---------- ----- ----- ----- ----- ----- ----- cs03# zpool status -v pool: z state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM z ONLINE 0 0 0 da1 ONLINE 0 0 0 errors: No known data errors ZFS related sysctls: vfs.zfs.arc_meta_limit: 26214400 vfs.zfs.arc_meta_used: 70401408 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 140928537 vfs.zfs.arc_max: 104857600 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 0 vfs.zfs.recover: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 35 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 13 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 kstat.zfs.misc.arcstats.hits: 57819155 kstat.zfs.misc.arcstats.misses: 5590858 kstat.zfs.misc.arcstats.demand_data_hits: 63981 kstat.zfs.misc.arcstats.demand_data_misses: 635 kstat.zfs.misc.arcstats.demand_metadata_hits: 47525277 kstat.zfs.misc.arcstats.demand_metadata_misses: 4114419 kstat.zfs.misc.arcstats.prefetch_data_hits: 19665 kstat.zfs.misc.arcstats.prefetch_data_misses: 809 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 10210232 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1474995 kstat.zfs.misc.arcstats.mru_hits: 11018143 kstat.zfs.misc.arcstats.mru_ghost_hits: 937056 kstat.zfs.misc.arcstats.mfu_hits: 37133185 kstat.zfs.misc.arcstats.mfu_ghost_hits: 3428689 kstat.zfs.misc.arcstats.deleted: 7789751 kstat.zfs.misc.arcstats.recycle_miss: 6302888 kstat.zfs.misc.arcstats.mutex_miss: 9406 kstat.zfs.misc.arcstats.evict_skip: 418277598 kstat.zfs.misc.arcstats.hash_elements: 9872 kstat.zfs.misc.arcstats.hash_elements_max: 124517 kstat.zfs.misc.arcstats.hash_collisions: 112246 kstat.zfs.misc.arcstats.hash_chains: 96 kstat.zfs.misc.arcstats.hash_chain_max: 3 kstat.zfs.misc.arcstats.p: 92080153 kstat.zfs.misc.arcstats.c: 140928537 kstat.zfs.misc.arcstats.c_min: 140928537 kstat.zfs.misc.arcstats.c_max: 104857600 kstat.zfs.misc.arcstats.size: 141645696 kstat.zfs.misc.arcstats.hdr_size: 2617264 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 671323 kstat.zfs.misc.vdev_cache_stats.hits: 4416731 kstat.zfs.misc.vdev_cache_stats.misses: 349266 There does seem to be something stuck in the syncer: vfs.worklist_len: 11 (that doesn't go down or move at all), but that doesn't tell me much. Next time this happens, is there anything else I should look at? -- Kevin On Feb 8, 2009, at 10:59 PM, Kevin Day wrote: > > I'm playing with a -CURRENT install from a couple of weeks ago. > Everything seems okay for a few days, then eventually every process > ends up stuck in zio->io_cv. If I go to the console, it's responsive > until I try logging in, then login is stuck in zio->io_cv as well. > Ctrl-Alt-Esc drops me into ddb, but then ddb hangs instantly. > > Nothing on the console or syslog before it hangs. > > Anyone seen anything similar? > > -- Kevin > > > Possibly relevant info: > > 8 core Opteron > 64GB RAM > > da1 at twa0 bus 0 target 0 lun 1 > da1: Fixed Direct Access SCSI-5 device > da1: 100.000MB/s transfers > da1: 4678158MB (9580867585 512 byte sectors: 255H 63S/T 596381C) > > server5# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > z 4.44T 1.19T 3.25T 26% ONLINE - > > server5# zpool status -v > pool: z > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > z ONLINE 0 0 0 > da1 ONLINE 0 0 0 > > errors: No known data errors > > server5# cat /boot/loader.conf > vm.kmem_size_max="2048M" > vm.kmem_size="2048M" > vfs.zfs.arc_max="100M" > zfs_load="YES" > vfs.root.mountfrom="zfs:z" > > > (tried lowering arc_max, didn't seem to help) > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From grarpamp at gmail.com Tue Mar 17 23:34:32 2009 From: grarpamp at gmail.com (grarpamp) Date: Tue Mar 17 23:34:40 2009 Subject: ZFS version list [was ETA for ZFS ver: n] Message-ID: ZFS version list [was ETA for ZFS ver: n] I needed raw, bit reliable, stable, encrypted storage. ZFS gave all but the last part so far. None of the features since v6 were useful to me. And as with most software, there are surely tons of fixes and optimizations being handled silently that are useful. Additions at or before v6 that were nifty: compression hot spares raidz2 ditto blocks sha256 - chained back to the uberblock thing Integrated crypto will be very useful, simply to eliminate that GEOM. Even if GBDE and GELI are cool :) Hopefully ZFS will include a strong 256 bit cipher along with other options. My guess is that it will be out from SUN midyear, before FBSD 8.0, and thus a potential for 8.0. The ZFS iSCSI bit might be cool. Putting things like that all under the ZFS hierarchy could be sickly entertaining :) If BSD chflags(2) schg, as on UFS, does or will work on ZFS, that's cool. See the Solaris chmod command. FBSD could very well have magically encrypted user homedirs that make use of some of the inherent ZFS [delegation, etc?] features. login could be hacked as could sshd or possibly pamify things. Haven't really thought about it other than Apple has it. Don't know about other BSD's. It is awesome that FBSD has ZFS! No matter what gets done when, thanks for all the work on it... past, present and on into future. Version list attached for people to reference... -------------- next part -------------- ======================================== http://opensolaris.org/os/community/zfs/version// ======================================== ZFS Pool Version 14 This version includes support for the following feature: * passthrough-x aclinherit property support This feature is available in: * Solaris Express Community Edition, build 103 The related bug and PSARC case for the version 14 change are: * 6765166 Need to provide mechanism to optionally inherit ACE_EXECUTE * PSARC 2008/659 New ZFS "passthrough-x" ACL inheritance rules ======================================== ZFS Pool Version 13 This version includes support for the following features: * usedbysnapshots property * usedbychildren property * usedbyrefreservation property * usedbydataset property These features are available in: * Solaris Express Community Edition, build 98 The related bug and PSARC case for version 13 change is: * 6730799 want snapused property * PSARC 2008/518 ZFS space accounting enhancements ======================================== ZFS Pool Version 12 This version includes support for the following feature: * Properties for Snapshots This feature is available in: * Solaris Express Community Edition, build 96 The related bug for the version 12 change is: * 6701797 want user properties on snapshots ======================================== ZFS Pool Version 11 This version includes support for the following feature: * Improved zpool scrub / resilver performance This feature is available in: * Solaris Express Community Edition, build 94 The related bug for the version 11 change is: * 6343667 scrub/resilver has to start over when a snapshot is taken * (Note, this bug is fixed when using build 94 even with older pool versions. However, upgrading the pool can improve scrub performance when there are many filesystems, snapshots, and clones.) ======================================== ZFS Pool Version 10 This version includes support for the following feature: * Devices can be added to a storage pool as "cache devices." These devices provide an additional layer of caching between main memory and disk. Using cache devices provides the greatest performance improvement for random read-workloads of mostly static content. This feature is available in the Solaris Express Community Edition, build 78. The Solaris 10 10/08 release includes ZFS pool version 10, but support for cache devices is not included in this Solaris release. The related bug for the version 10 change is: * 6536054 second tier ("external") ARC ======================================== ZFS Pool Version 9 This version includes support for the following features: * In addition to the existing ZFS quota and reservation features, this release includes dataset quotas and reservations that do not include descendent datasets, such as snapshots and clones, in the space consumption. ("zfs set refquota" and "zfs set refreservation".) * A reservation is automatically set when a non-sparse ZFS volume is created that matches the size of the volume. This release provides an immediate reservation feature so that you set a reservation on a non-sparse volume with enough space to take snapshots and modify the contents of the volume. * CIFS server support These features are available in Solaris Express Community Edition, build 77. The related bugs for version 9 changes are: * 6431277 want filesystem-only quotas * 6483677 need immediate reservation * 6617183 CIFS Service PSARC 2006/715 ======================================== ZFS Pool Version 8 This version now supports the ability to delegate zfs(1M) administrative tasks to ordinary users. This feature is available in: * Solaris Express Community Edition, build 69 * Solaris 10 10/08 release The related bug for the version 8 change is: * 6349470 investigate non-root restore/backup ======================================== ZFS Pool Version 7 This version includes support for the following feature: The ZFS Intent Log (ZIL) satisfies the need of some applications to know the data they changed is on stable storage on return from a system call. The Intent Log holds records of those system calls and they are replayed if the system power fails or panics if they have not been committed to the main pool. When the Intent Log is allocated from the main pool, it allocates blocks that chain through the pool. This version adds the capability to specify a separate Intent Log device or devices. This feature is available in: * Solaris Express Community Edition, build 68 * Solaris 10 10/08 release The related bug for the version 7 change is: * 6339640 Make ZIL use NVRAM when available. ======================================== ZFS Pool Version 6 This version includes support for the following feature: * 'bootfs' pool property This feature is available in: * Solaris Express Community Edition, build 62 * Solaris 10 10/08 release The related bugs for version 6 changes are as follows: * 4929890 ZFS Boot support for the x86 platform * 6479807 pools need properties ======================================== ZFS Pool Version 5 This version includes support for the following feature: * gzip compression for ZFS datasets This feature is available in: * Solaris Express Community Edition, build 62 * Solaris 10 10/08 release The related bug for the version 5 changes is: * 6536606 gzip compression for ZFS ======================================== ZFS Pool Version 4 This version includes support for the following feature: * zpool history This feature is available in: * Solaris Express Community Edition, build 62 * Solaris 10 8/07 release The related bugs for version 4 changes are as follows: * 6529406 zpool history needs to bump the on-disk version * 6343741 want to store a command history on disk ======================================== ZFS Pool Version 3 This version includes support for the following features: * Hot spares * Double-parity RAID-Z (raidz2) * Improved RAID-Z accounting These features are available in: * Solaris Express Community Edition, build 42 * Solaris 10 11/06 release, (build 3) The related bugs for version 3 changes are as follows: * 6405966 Hot Spare support in ZFS * 6417978 double parity RAID-Z a.k.a. RAID6 * 6288488 du reports misleading size on RAID-Z ======================================== ZFS Pool Version 2 This version includes support for "Ditto Blocks", or replicated metadata. Due to the tree-like structure of the ZFS on-disk format, an uncorrectable error in a leaf block may be relatively benign, while an uncorrectable error in pool metadata can result in an unopenable pool. This feature introduces automatic replication of metadata (up to 3 copies of each block) independent of any underlying pool-wide redundancy. For example, on a pool with a single mirror, the most critical metadata will appear three times on each side of the mirror, for a total of six copies. This ensures that while user data may be lost due to corruption, all data in the pool will be discoverable and the pool will still be usable. This will be expanded in the future to allow user data replication on a per-dataset basis. This feature was integrated on 4/10/06 with the following bug fix: 6410698 ZFS metadata needs to be more highly replicated (ditto blocks) This feature is available in: * Solaris Express Community Edition, build 38 * Solaris 10 10/06 release (build 09) ======================================== ZFS Pool Version 1 This is the initial ZFS on-disk format as integrated on 10/31/05. During the next six months of internal use, there were a few on-disk format changes that did not result in a version number change, but resulted in a flag day since earlier versions could not read the newer changes. The first official releases supporting this version are: * Solaris Express Community Edition, build 36 * Solaris 10 6/06 release Earlier releases may not support this version, despite being formatted with the same on-disk number. This is due to: 6389368 fat zap should use 16k blocks (with backwards compatability) 6390677 version number checking makes upgrades challenging ======================================== From attilio at freebsd.org Wed Mar 18 02:25:09 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Mar 18 02:25:15 2009 Subject: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR In-Reply-To: <20090314203215.GA41617@deviant.kiev.zoral.com.ua> References: <200903140450.n2E4o3to011990@freefall.freebsd.org> <20090314102135.GA93077@x2.osted.lan> <20090314203215.GA41617@deviant.kiev.zoral.com.ua> Message-ID: <3bbf2fe10903180159x10d2c721rf9ff4147a5c75ec7@mail.gmail.com> 2009/3/14, Kostik Belousov : > On Sat, Mar 14, 2009 at 11:21:35AM +0100, Peter Holm wrote: > > On Sat, Mar 14, 2009 at 04:50:03AM +0000, Yoshihiro Ota wrote: > > > The following reply was made to PR kern/132597; it has been noted by GNATS. > > > > > > From: Yoshihiro Ota > > > To: bug-followup@FreeBSD.org > > > Cc: bf2006a@yahoo.com > > > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while > > > interrupting a port build on tmpfs WRKDIR > > > Date: Sat, 14 Mar 2009 00:42:58 -0400 > > > > > > Which ports were you compiling when panic happened? > > > > > > Hiro > > > > The panic in this PR looks a lot like the one I reported to attilio@ > > > > http://people.freebsd.org/~pho/stress/log/attilio022.txt > > > > It was just regular FS load that provoked it. > > > It seems to be quite clean what is going on there. In fact, there are > two issues: > > First is the usual problem of DOTDOT lookup that shall be fixed in style > of vn_vget_ino() by busying mp before unlocking dvp. > > Second one is the reason for the panic. The tmpfs vnode is unlocked, and > then corresponding tmpfs _node_ is passed to the tmpfs_alloc_vp(). > Since the vnode may be reclaimed after the unlock, passed node might > become freed. Then, the tmpfs_alloc_vp() would operate on the freed > memory. So I have a question. In the tmpfs_lookup() there is dvp with gets vhold() before to unlock the dvp vnode lock. That should not be enough to prevent recycling and freeing of the structure? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From kostikbel at gmail.com Wed Mar 18 06:10:03 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Mar 18 06:10:11 2009 Subject: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR In-Reply-To: <3bbf2fe10903180159x10d2c721rf9ff4147a5c75ec7@mail.gmail.com> References: <200903140450.n2E4o3to011990@freefall.freebsd.org> <20090314102135.GA93077@x2.osted.lan> <20090314203215.GA41617@deviant.kiev.zoral.com.ua> <3bbf2fe10903180159x10d2c721rf9ff4147a5c75ec7@mail.gmail.com> Message-ID: <20090318130946.GD41617@deviant.kiev.zoral.com.ua> On Wed, Mar 18, 2009 at 09:59:14AM +0100, Attilio Rao wrote: > 2009/3/14, Kostik Belousov : > > On Sat, Mar 14, 2009 at 11:21:35AM +0100, Peter Holm wrote: > > > On Sat, Mar 14, 2009 at 04:50:03AM +0000, Yoshihiro Ota wrote: > > > > The following reply was made to PR kern/132597; it has been noted by GNATS. > > > > > > > > From: Yoshihiro Ota > > > > To: bug-followup@FreeBSD.org > > > > Cc: bf2006a@yahoo.com > > > > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while > > > > interrupting a port build on tmpfs WRKDIR > > > > Date: Sat, 14 Mar 2009 00:42:58 -0400 > > > > > > > > Which ports were you compiling when panic happened? > > > > > > > > Hiro > > > > > > The panic in this PR looks a lot like the one I reported to attilio@ > > > > > > http://people.freebsd.org/~pho/stress/log/attilio022.txt > > > > > > It was just regular FS load that provoked it. > > > > > > It seems to be quite clean what is going on there. In fact, there are > > two issues: > > > > First is the usual problem of DOTDOT lookup that shall be fixed in style > > of vn_vget_ino() by busying mp before unlocking dvp. > > > > Second one is the reason for the panic. The tmpfs vnode is unlocked, and > > then corresponding tmpfs _node_ is passed to the tmpfs_alloc_vp(). > > Since the vnode may be reclaimed after the unlock, passed node might > > become freed. Then, the tmpfs_alloc_vp() would operate on the freed > > memory. > > So I have a question. > In the tmpfs_lookup() there is dvp with gets vhold() before to unlock > the dvp vnode lock. > That should not be enough to prevent recycling and freeing of the structure? No. The only thing that prevents vnode reclaim is the vnode lock. Both vhold and vref only prevent struct vnode * pointer from becoming invalid, i.e. freeing vnode memory, and also keep vnode interlock and lock functional. The difference between vhold and vref is that vref() prevents non-forced unmounts from reclaiming such vnode. -------------- 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/20090318/bf14780b/attachment.pgp From gsutter at zer0.org Sun Mar 22 09:09:30 2009 From: gsutter at zer0.org (Gregory Sutter) Date: Sun Mar 22 09:09:36 2009 Subject: RFC: geli+gmirror problem + solution In-Reply-To: <20090312195904.GA1786@garage.freebsd.pl> References: <20090311215518.GA25410@gvr.gvr.org> <20090312195904.GA1786@garage.freebsd.pl> Message-ID: <20090322120521.GA5584@kyanos.zer0.org> On 2009-03-12 20:59 +0100, Pawel Jakub Dawidek wrote: > On Wed, Mar 11, 2009 at 10:55:18PM +0100, Guido van Rooij wrote: > > > > We have a setup where we have two disks in a gmirror with GELI on top > > of it. We boot from it (using a small unencrypted USB stick). > > We this have the G_ELI_FLAG_BOOT set. > > > > Anyway, when rebooting, geli does not detach and this the gmirror is > > never destroyed resulting in a rebuild each time. > > Maybe you could implement detaching on reboot > for geli providers? You can find example of how to do this in three last > functions in sys/geom/mirror/g_mirror.c. Has this been filed as a PR, and has any progress been made on a fix? I couldn't find anything exact in GNATS using the expected search terms, but I did find some resemblances: kern/119293: a similar-looking situation with GBDE on a gmirror kern/113957: a case in which gmirror sometimes reports degraded arrays As it happens, I just ran into this problem earlier today. My gmirror is still rebuilding from the incident. It was a disconcerting thing to have happen upon the first reboot after setting up the new storage. (Until I read this thread, I didn't know which layer had the problem; I've got quite the onion of geoms set up in /dev/mirror/gm0s1e.eli.journal.) It seems like a workaround could be to: - add the shutdown keyword to the geli rc script. The script already has a geli_stop function. and - use 'shutdown', send a signal to init, or make the 3-finger salute instead of using 'halt' or 'reboot', which don't use init and don't call rc.shutdown. -- Gregory S. Sutter A little nonsense now and then mailto:gsutter@zer0.org is relished by the wisest men. http://zer0.org/~gsutter/ --Roald Dahl (as Willy Wonka) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090322/f7093a9b/attachment.pgp From pjd at FreeBSD.org Sun Mar 22 10:27:20 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Mar 22 10:27:26 2009 Subject: RFC: geli+gmirror problem + solution In-Reply-To: <20090322120521.GA5584@kyanos.zer0.org> References: <20090311215518.GA25410@gvr.gvr.org> <20090312195904.GA1786@garage.freebsd.pl> <20090322120521.GA5584@kyanos.zer0.org> Message-ID: <20090322172749.GJ3102@garage.freebsd.pl> On Sun, Mar 22, 2009 at 05:05:21AM -0700, Gregory Sutter wrote: > On 2009-03-12 20:59 +0100, Pawel Jakub Dawidek wrote: > > On Wed, Mar 11, 2009 at 10:55:18PM +0100, Guido van Rooij wrote: > > > > > > We have a setup where we have two disks in a gmirror with GELI on top > > > of it. We boot from it (using a small unencrypted USB stick). > > > We this have the G_ELI_FLAG_BOOT set. > > > > > > Anyway, when rebooting, geli does not detach and this the gmirror is > > > never destroyed resulting in a rebuild each time. > > > > Maybe you could implement detaching on reboot > > for geli providers? You can find example of how to do this in three last > > functions in sys/geom/mirror/g_mirror.c. > > Has this been filed as a PR, and has any progress been made on a fix? The rest of the discussion was made private (probably by accident), sorry about that. Fix is already committed to HEAD. -- 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/20090322/c0e6ca9b/attachment.pgp From gsutter at zer0.org Sun Mar 22 12:43:38 2009 From: gsutter at zer0.org (Gregory Sutter) Date: Sun Mar 22 12:43:50 2009 Subject: RFC: geli+gmirror problem + solution In-Reply-To: <20090322172749.GJ3102@garage.freebsd.pl> References: <20090311215518.GA25410@gvr.gvr.org> <20090312195904.GA1786@garage.freebsd.pl> <20090322120521.GA5584@kyanos.zer0.org> <20090322172749.GJ3102@garage.freebsd.pl> Message-ID: <20090322194335.GL2075@kyanos.zer0.org> On 2009-03-22 18:27 +0100, Pawel Jakub Dawidek wrote: > On Sun, Mar 22, 2009 at 05:05:21AM -0700, Gregory Sutter wrote: > > On 2009-03-12 20:59 +0100, Pawel Jakub Dawidek wrote: > > > On Wed, Mar 11, 2009 at 10:55:18PM +0100, Guido van Rooij wrote: > > > > > > > > Anyway, when rebooting, geli does not detach and this the gmirror is > > > > never destroyed resulting in a rebuild each time. > > > > > > Maybe you could implement detaching on reboot > > > for geli providers? You can find example of how to do this in three last > > > functions in sys/geom/mirror/g_mirror.c. > > > > Has this been filed as a PR, and has any progress been made on a fix? > > The rest of the discussion was made private (probably by accident), > sorry about that. Fix is already committed to HEAD. Woot. Thanks for committing that! This fix looks like a straightforward MFC: http://svnweb.freebsd.org/viewvc/base/head/sys/geom/eli/g_eli.c?r1=172506&r2=189900 Do you agree, and if so, will you please MFC to 7-STABLE? That's where I'm encountering the problem. -- Gregory S. Sutter Mostly Harmless mailto:gsutter@zer0.org http://zer0.org/~gsutter/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090322/2e5fbc71/attachment.pgp From pjd at FreeBSD.org Sun Mar 22 13:34:03 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Mar 22 13:34:09 2009 Subject: RFC: geli+gmirror problem + solution In-Reply-To: <20090322194335.GL2075@kyanos.zer0.org> References: <20090311215518.GA25410@gvr.gvr.org> <20090312195904.GA1786@garage.freebsd.pl> <20090322120521.GA5584@kyanos.zer0.org> <20090322172749.GJ3102@garage.freebsd.pl> <20090322194335.GL2075@kyanos.zer0.org> Message-ID: <20090322203427.GL3102@garage.freebsd.pl> On Sun, Mar 22, 2009 at 12:43:35PM -0700, Gregory Sutter wrote: > On 2009-03-22 18:27 +0100, Pawel Jakub Dawidek wrote: > > On Sun, Mar 22, 2009 at 05:05:21AM -0700, Gregory Sutter wrote: > > > On 2009-03-12 20:59 +0100, Pawel Jakub Dawidek wrote: > > > > On Wed, Mar 11, 2009 at 10:55:18PM +0100, Guido van Rooij wrote: > > > > > > > > > > Anyway, when rebooting, geli does not detach and this the gmirror is > > > > > never destroyed resulting in a rebuild each time. > > > > > > > > Maybe you could implement detaching on reboot > > > > for geli providers? You can find example of how to do this in three last > > > > functions in sys/geom/mirror/g_mirror.c. > > > > > > Has this been filed as a PR, and has any progress been made on a fix? > > > > The rest of the discussion was made private (probably by accident), > > sorry about that. Fix is already committed to HEAD. > > Woot. Thanks for committing that! > > This fix looks like a straightforward MFC: > http://svnweb.freebsd.org/viewvc/base/head/sys/geom/eli/g_eli.c?r1=172506&r2=189900 > > Do you agree, and if so, will you please MFC to 7-STABLE? That's > where I'm encountering the problem. Let it settle for a week in HEAD, then I'll do MFC. -- 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/20090322/82d35f0c/attachment.pgp From guido at gvr.org Mon Mar 23 00:59:23 2009 From: guido at gvr.org (Guido van Rooij) Date: Mon Mar 23 00:59:29 2009 Subject: RFC: geli+gmirror problem + solution In-Reply-To: <20090322203427.GL3102@garage.freebsd.pl> References: <20090311215518.GA25410@gvr.gvr.org> <20090312195904.GA1786@garage.freebsd.pl> <20090322120521.GA5584@kyanos.zer0.org> <20090322172749.GJ3102@garage.freebsd.pl> <20090322194335.GL2075@kyanos.zer0.org> <20090322203427.GL3102@garage.freebsd.pl> Message-ID: <20090323075921.GA38261@gvr.gvr.org> On Sun, Mar 22, 2009 at 09:34:27PM +0100, Pawel Jakub Dawidek wrote: > > > > This fix looks like a straightforward MFC: > > http://svnweb.freebsd.org/viewvc/base/head/sys/geom/eli/g_eli.c?r1=172506&r2=189900 > > > > Do you agree, and if so, will you please MFC to 7-STABLE? That's > > where I'm encountering the problem. > > Let it settle for a week in HEAD, then I'll do MFC. FYI: I am running it on 7-RELEASE without any problem. -Guido From bugmaster at FreeBSD.org Mon Mar 23 04:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 23 04:07:49 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200903231106.n2NB6tQU003981@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/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] 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/129174 fs [nfs] [zfs] [panic] NFS v3 Panic when under high load o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129084 fs [udf] [panic] [lor] udf panic: getblk: size(67584) > M 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po 49 problems total. From gavin at FreeBSD.org Mon Mar 23 06:34:41 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Mar 23 06:34:47 2009 Subject: kern/129084: [udf] [panic] [lor] udf panic: getblk: size(67584) > MAXBSIZE(65536) Message-ID: <200903231334.n2NDYf4k020197@freefall.freebsd.org> Synopsis: [udf] [panic] [lor] udf panic: getblk: size(67584) > MAXBSIZE(65536) State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Mon Mar 23 13:34:07 UTC 2009 State-Changed-Why: This has been fixed and merged to 7.x (confirmed by avg on IRC) http://www.freebsd.org/cgi/query-pr.cgi?pr=129084 From jh at saunalahti.fi Mon Mar 23 09:40:04 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Mon Mar 23 09:40:18 2009 Subject: bin/131341: makefs: error "Bad file descriptor" on the mount point of md-presentation makefs image Message-ID: <200903231640.n2NGe3sj066425@freefall.freebsd.org> The following reply was made to PR bin/131341; it has been noted by GNATS. From: Jaakko Heinonen To: oleg.ginzburg@nevosoft.ru Cc: bug-followup@FreeBSD.org Subject: Re: bin/131341: makefs: error "Bad file descriptor" on the mount point of md-presentation makefs image Date: Mon, 23 Mar 2009 18:31:30 +0200 See this message: http://docs.freebsd.org/cgi/mid.cgi?20090323154536.GA2853 and a patch: http://www.saunalahti.fi/~jh3/patches/ffs-fs_fsbtodb.diff -- Jaakko From mel.flynn+fbsd.fs at mailing.thruhere.net Mon Mar 23 09:49:11 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Mon Mar 23 09:49:17 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate Message-ID: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> Hello list, in an effort to try and understand the various async systems available, it's unclear to me how (if at all) the above relate. If one mounts a disk with async, does this internally use aio system calls, or is there a subsystem available which does largely the same? If so, why are there 2 subsystems? When using aio, for example with squid, does this mean the underlying provider needs to be mounted async or is this totally unrelated? Similarly if said disk is on a gjournalled partition, is the async mount redundant or is using aio redundant or neither? The systems themselves are properly documented - I just couldn't find any info on how they relate, or why they are unrelated. -- Mel From julian at elischer.org Mon Mar 23 10:30:31 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Mar 23 10:30:38 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate In-Reply-To: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <49C7C45B.7040708@elischer.org> Mel Flynn wrote: > Hello list, > > in an effort to try and understand the various async systems available, it's > unclear to me how (if at all) the above relate. > > If one mounts a disk with async, does this internally use aio system calls, or > is there a subsystem available which does largely the same? If so, why are > there 2 subsystems? the async mount operation tells the systewm that writes done by a process may be actually written to teh filesystem at any time later, and that it is ok to return "success" to the user immediately, regardless of whether the write has actually been done. This also applies to the metadata. It does not affect reads at all. > > When using aio, for example with squid, does this mean the underlying provider > needs to be mounted async or is this totally unrelated? Similarly if said disk > is on a gjournalled partition, is the async mount redundant or is using aio > redundant or neither? > no the aio system calls are implemented in a manner that allows the caller to request IO and then return at a later time to find out the result. it has no connection to the mount option. BTW for efficient async IO check out the relationship between the aio calls and the kqueue calls. > The systems themselves are properly documented - I just couldn't find any info > on how they relate, or why they are unrelated. From chris at young-alumni.com Mon Mar 23 11:34:27 2009 From: chris at young-alumni.com (Chris Ruiz) Date: Mon Mar 23 11:34:33 2009 Subject: ETA for ZFS v. 13 Merge From HEAD ? In-Reply-To: <5f67a8c40903161109le12b8afuc25b8c1ec1b6f70c@mail.gmail.com> References: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> <4AE4493D5E9141E8812E4BC83FB5A2A5@PegaPegII> <5f67a8c40903161109le12b8afuc25b8c1ec1b6f70c@mail.gmail.com> Message-ID: <9DCF097D-421A-4F5F-8A48-D0286551C62C@young-alumni.com> On Mar 16, 2009, at 1:09 PM, Zaphod Beeblebrox wrote: > On Sun, Mar 15, 2009 at 6:39 PM, Pegasus Mc Cleaft > wrote: > >> Hi Adrian, >> >> I am not sure, but I didnt think ZFS 13 was ever going to be >> merged into >> 7-stable. I thought the kernel memory requirements were to great >> (just going >> back in my memory on that one). Also, I think there are still a few >> bugs >> left with the zil being enabled (and/or prefetch) causing lockups >> on machine >> with a lot of IO. I know I have hit that bug a few times on my >> machine when >> using various torrent clients when they want to preallocate large >> amounts of >> diskspace. >> >> I personally cant wait until a later version of ZFS is imported that >> supports encryption. I can finally say good-bye to our GEOM ELI USB >> drives >> for backups!! Never the less, I am quite thankfull to thoes >> involved in >> porting V13 to FreeBSD. Its a wonderfull improvement and my FS of >> choice >> when installing on new machines (especially zfs boot) > > > I think that you're touching on two entirely separate points here... > What it > takes to upgrade ZFS in -STABLE and what it takes to bring ZFS > modules in to > FreeBSD. > > I sincerely hope that ZFSv13 is planned for -STABLE. Last we left > this > issue, testing and a few kernel improvements were in the way. None > of the > kernel improvements were going to change the API, so the project was > doable > in -STABLE. That said, time marches on, 8.0-RELEASE draws ever > nearer. > When we were still several years out on 8.0 and ZFS was causing me > more > problems, I was much more keen to push for the port. I would still > welcome > it with open arms, but I'm not convinced that anyone is going to > push it > forward. > > The issue of encryption (along with many other issues) is tied to the > ability of FreeBSD to compile and use ZFS modules. Just like netgraph > modules extend the function of netgraph.ko and geom modules extend > the base > geom function, ZFS is designed (in Solaris, at least) to take > modules. ZFS > encryption is a module. I'm not clear on compression --- it would > make > sense that it is a module, but it seemingly got copied into FreeBSD > as a > core feature (and it may also be so in solaris). > > Anyways... is there any plans to allow for ZFS modules in FreeBSD? AFAIK ZFS v13 requires changes to the kernel that would break the ABI, which is not allowed to change in a STABLE branch. With 8.0 coming within the next 6 months, I doubt that 7 will see a new version of ZFS. There are no problems running ZFS v13 with zil and prefetch enabled and I have not had any predictable out of kernel memory panics. For me, ZFS on CURRENT really is *that* much better. Also, OpenSolaris has yet to integrate ZFS on disk encryption into their source. The code is currently under review: http://opensolaris.org/os/project/zfs-crypto/ . OpenSolaris uses ZFS v14 now and on disk encryption will probably be synced to a newer version of ZFS, meaning that this would require another code sync with OpenSolaris. Chris From linimon at FreeBSD.org Mon Mar 23 11:43:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Mar 23 11:43:56 2009 Subject: kern/132960: [zfs] [panic] panic:ffs_blkfree: freeing free frag Message-ID: <200903231843.n2NIhnd5041174@freefall.freebsd.org> Old Synopsis: panic:ffs_blkfree: freeing free frag New Synopsis: [zfs] [panic] panic:ffs_blkfree: freeing free frag Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 23 18:43:01 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132960 From zbeeble at gmail.com Mon Mar 23 14:09:20 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon Mar 23 14:09:27 2009 Subject: ETA for ZFS v. 13 Merge From HEAD ? In-Reply-To: <9DCF097D-421A-4F5F-8A48-D0286551C62C@young-alumni.com> References: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> <4AE4493D5E9141E8812E4BC83FB5A2A5@PegaPegII> <5f67a8c40903161109le12b8afuc25b8c1ec1b6f70c@mail.gmail.com> <9DCF097D-421A-4F5F-8A48-D0286551C62C@young-alumni.com> Message-ID: <5f67a8c40903231409q17fd0370wd2907525b8b6aff0@mail.gmail.com> On Mon, Mar 23, 2009 at 2:14 PM, Chris Ruiz wrote: > > AFAIK ZFS v13 requires changes to the kernel that would break the ABI, > which is not allowed to change in a STABLE branch. With 8.0 coming within > the next 6 months, I doubt that 7 will see a new version of ZFS. Can we have someone who actually knows comment on this requirement? The last time this was discussed, I didn't hear this conclusion --- that ZFS 13 required ABI breaking kernel changes. > Also, OpenSolaris has yet to integrate ZFS on disk encryption into their > source. The code is currently under review: > http://opensolaris.org/os/project/zfs-crypto/ . OpenSolaris uses ZFS v14 > now and on disk encryption will probably be synced to a newer version of > ZFS, meaning that this would require another code sync with OpenSolaris. It should be said that importing updates from OpenSolaris needs to be easier. From mel.flynn+fbsd.fs at mailing.thruhere.net Mon Mar 23 14:31:30 2009 From: mel.flynn+fbsd.fs at mailing.thruhere.net (Mel Flynn) Date: Mon Mar 23 14:31:36 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate In-Reply-To: <49C7C45B.7040708@elischer.org> References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> <49C7C45B.7040708@elischer.org> Message-ID: <200903232231.26279.mel.flynn+fbsd.fs@mailing.thruhere.net> On Monday 23 March 2009 18:18:19 Julian Elischer wrote: > Mel Flynn wrote: > > Hello list, > > > > in an effort to try and understand the various async systems available, > > it's unclear to me how (if at all) the above relate. > > > > If one mounts a disk with async, does this internally use aio system > > calls, or is there a subsystem available which does largely the same? If > > so, why are there 2 subsystems? > > the async mount operation tells the systewm that writes done by a > process may be actually written to teh filesystem at any time later, > and that it is ok to return "success" to the user immediately, > regardless of whether the write has actually been done. > This also applies to the metadata. It does not affect reads at all. So it is up to the underlying geom provider to handle the write queue? > > > When using aio, for example with squid, does this mean the underlying > > provider needs to be mounted async or is this totally unrelated? > > Similarly if said disk is on a gjournalled partition, is the async mount > > redundant or is using aio redundant or neither? > > no the aio system calls are implemented in a manner that allows > the caller to request IO and then return at a later time to find out > the result. it has no connection to the mount option. So with aio_write(2) on an async gjournal fs, one faces a write queue on the fd used by aio(4) along with another made by gjournal? This leads me to believe that it's better to take one of those out of the equation for performance. > BTW for efficient async IO check out the relationship between the aio > calls and the kqueue calls. Thanks for the pointer, reading up ... -- Mel From julian at elischer.org Mon Mar 23 16:45:51 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Mar 23 16:45:58 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate In-Reply-To: <200903232231.26279.mel.flynn+fbsd.fs@mailing.thruhere.net> References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> <49C7C45B.7040708@elischer.org> <200903232231.26279.mel.flynn+fbsd.fs@mailing.thruhere.net> Message-ID: <49C81F3A.7010207@elischer.org> Mel Flynn wrote: > On Monday 23 March 2009 18:18:19 Julian Elischer wrote: >> Mel Flynn wrote: >>> Hello list, >>> >>> in an effort to try and understand the various async systems available, >>> it's unclear to me how (if at all) the above relate. >>> >>> If one mounts a disk with async, does this internally use aio system >>> calls, or is there a subsystem available which does largely the same? If >>> so, why are there 2 subsystems? >> the async mount operation tells the systewm that writes done by a >> process may be actually written to teh filesystem at any time later, >> and that it is ok to return "success" to the user immediately, >> regardless of whether the write has actually been done. >> This also applies to the metadata. It does not affect reads at all. > > So it is up to the underlying geom provider to handle the write queue? The filesystem actually makes the I/O requests at a "later time". > >>> When using aio, for example with squid, does this mean the underlying >>> provider needs to be mounted async or is this totally unrelated? >>> Similarly if said disk is on a gjournalled partition, is the async mount >>> redundant or is using aio redundant or neither? >> no the aio system calls are implemented in a manner that allows >> the caller to request IO and then return at a later time to find out >> the result. it has no connection to the mount option. > > So with aio_write(2) on an async gjournal fs, one faces a write queue on the > fd used by aio(4) along with another made by gjournal? This leads me to > believe that it's better to take one of those out of the equation for > performance. oh, where to begin.... you do the aio operation. It is queued in the aio system, (unless it is acted upon immediately by the AIO thread) your thread then returns immediately. The aio thread associated with your process continues by (though the filesystem) requesting that the IO be done. The IO system (geom) queues the IO request and (probably immediately) starts operation on it. which results in the IO request being made to the hardware. On completion a notification is made by the driver to the geom layer which trickles the info back up to the AIO system which in turn notifies your process (when it asks) of the result of the operation. however, you have been working all (or much of) this time, so throughput and latency are not too bad. Notice that teh data is not necessarily queued everywhere if there is no work in front of it blovking the way. (I'm not a geom expert so that part is not too clear to me). async mounting plays no real part in this. > >> BTW for efficient async IO check out the relationship between the aio >> calls and the kqueue calls. > > Thanks for the pointer, reading up ... > From mi+thun at aldan.algebra.com Mon Mar 23 19:02:47 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Mon Mar 23 19:02:59 2009 Subject: dump | restore fails: unknown tape header type 1853384566 Message-ID: <49C83673.3000604@aldan.algebra.com> Hello! I'm trying to migrate a filesystem from one disk to another using: dump a0hCf 0 32 - /old | restore -rf - (/old is already mounted read-only). The process runs for a while and then stops with: [...] DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 unknown tape header type 1853384566 abort? [yn] Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's dump's output? The system runs 7.0-STABLE from July 6th, i386. I just tried updating the dump and restore from source (latest 7.x) -- the error is the same... Please, advise. Thanks! -mi From doconnor at gsoft.com.au Mon Mar 23 22:41:36 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Mar 23 22:41:42 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C83673.3000604@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> Message-ID: <200903241537.36515.doconnor@gsoft.com.au> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote: > I'm trying to migrate a filesystem from one disk to another using: > > dump a0hCf 0 32 - /old | restore -rf - > > (/old is already mounted read-only). The process runs for a while and > then stops with: > > [...] > DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 > DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 > DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 > unknown tape header type 1853384566 > abort? [yn] > > Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's > dump's output? What happens if you don't use the cache? Also, do you really want -h 0? That means you skip nodump marked files at a level 0 dump. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090324/380d8cc3/attachment.pgp From mi+thun at aldan.algebra.com Mon Mar 23 23:30:46 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Mon Mar 23 23:30:53 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <200903241537.36515.doconnor@gsoft.com.au> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> Message-ID: <49C87E0D.5090501@aldan.algebra.com> Daniel O'Connor ???????(??): > On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote: > >> I'm trying to migrate a filesystem from one disk to another using: >> >> dump a0hCf 0 32 - /old | restore -rf - >> >> (/old is already mounted read-only). The process runs for a while and >> then stops with: >> >> [...] >> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 >> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 >> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 >> unknown tape header type 1853384566 >> abort? [yn] >> >> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's >> dump's output? >> > > What happens if you don't use the cache? > No big difference: dump a0f - /old | restore -rf - [...] DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 unknown tape header type -621260722 abort? [yn] Looks like a junk value somewhere... Unitialized variable or some such. -mi From danny at cs.huji.ac.il Tue Mar 24 01:15:59 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Mar 24 01:16:05 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C87E0D.5090501@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> Message-ID: > Daniel O'Connor ???????(??): > > On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote: > > > >> I'm trying to migrate a filesystem from one disk to another using: > >> > >> dump a0hCf 0 32 - /old | restore -rf - > >> > >> (/old is already mounted read-only). The process runs for a while and> >> then stops with: > >> > >> [...] > >> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 > >> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 > >> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 > >> unknown tape header type 1853384566> >> abort? [yn] > >> > >> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's > >> dump's output? > >> > >> > What happens if you don't use the cache? > > > No big difference: > > dump a0f - /old | restore -rf - > [...] > DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 > DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 > DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 > unknown tape header type -621260722> abort? [yn] > > Looks like a junk value somewhere... Unitialized variable or some such. > can you try splitting it in 2, ie no pipe? dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz) restore rf some.file danny From brde at optusnet.com.au Tue Mar 24 05:41:14 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Tue Mar 24 05:41:21 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate In-Reply-To: <49C7C45B.7040708@elischer.org> References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> <49C7C45B.7040708@elischer.org> Message-ID: <20090324224001.D1670@besplex.bde.org> On Mon, 23 Mar 2009, Julian Elischer wrote: > Mel Flynn wrote: >> If one mounts a disk with async, does this internally use aio system calls, >> or is there a subsystem available which does largely the same? If so, why >> are there 2 subsystems? > > the async mount operation tells the systewm that writes done by a process may > be actually written to teh filesystem at any time later, and that it is ok to > return "success" to the user immediately, regardless of whether the write has > actually been done. > This also applies to the metadata. It does not affect reads at all. Actually, this only (*) applies to the metadata. The async mount option does not affect writes, except for the metadata part of writes and for a small affect on the amount of asyncness of writes. The data part of writes is always (*) written asynchronously and "success" is returned to the user immediately, irrespective of whether the write has actually been done. (Success may be returned even if the write was attempted but failed. Writes are retried endlessly to a fault, so the data for a failed writes is not always lost. (The usual fault is panicing when the disk goes away.) It is necessary to use fsync() or the still-unimplemnted POSIX interface fdatasync() to ensure that the data has been written or get a report of non-success.) (*) Not quite only or always, since (1) The async mount option is incompatible with soft updates and is silently ignored if soft updates is configured. Soft updates essentially gives async everything, with stronger ordering of writes so that the file system is always consistent (but often out of date). (2) The sync mount option may be used to force synchronous writes of data. This option should give synchronous everything, but when it is mixed with the async mount option (and that option is not ignored) it gives the weird and undesirable behaviour of sync writes of data and async writes of metadata. >> When using aio, for example with squid, does this mean the underlying >> provider needs to be mounted async or is this totally unrelated? Similarly >> if said disk is on a gjournalled partition, is the async mount redundant or >> is using aio redundant or neither? > > no the aio system calls are implemented in a manner that allows > the caller to request IO and then return at a later time to find out > the result. it has no connection to the mount option. Yes, essentially Unix kernels always had and used async writes, and the relatively new and quite different aio interface lets applications do async writes too. Bruce From hali at datapipe.net Tue Mar 24 08:09:03 2009 From: hali at datapipe.net (Hussain Ali) Date: Tue Mar 24 08:09:10 2009 Subject: ZFS move from FreeBSD to Opensolaris ? Message-ID: <20090324145841.GD17811@datapipe.com> Hello, Was wondering if anyone has had success in migrating an external zpool from FreeBSD 7.x to OpenSolaris. Currently, I am testing this out with Vmware and while I can export/ import the pool on FreeBSD VM's , I haven't had much success with in Vmware to date : freebsd# zpool import pool: tank id: 7702735926967895150 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: tank ONLINE da1 ONLINE da2 ONLINE da3 ONLINE da4 ONLINE opensolaris:~# zpool import pool: tank id: 7702735926967895150 state: UNAVAIL status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: http://www.sun.com/msg/ZFS-8000-5E config: tank UNAVAIL insufficient replicas c4t1d0s8 UNAVAIL corrupted data c4t2d0s2 UNAVAIL corrupted data c4t3d0s8 UNAVAIL corrupted data c4t4d0s8 UNAVAIL corrupted data On a tangent, I can go from Mac -> OpenSolaris. I am guessing this maybe due to lack of EFI/GPT labels on the geom providers. This may also be an issue with how vmware does virtual disks, so I am going to test out some real hardware, but if anyone else has first hand experience I would appreciate the input. -- -hussain This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. From mi+thun at aldan.algebra.com Tue Mar 24 09:20:31 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 09:20:38 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> Message-ID: <49C90813.8070705@aldan.algebra.com> Danny Braniss ???????(??): >> Daniel O'Connor ???????(??): >> >> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote: >> >> >> >>>> I'm trying to migrate a filesystem from one disk to another using: >>>> >>>> dump a0hCf 0 32 - /old | restore -rf - >>>> >>>> (/old is already mounted read-only). The process runs for a while and> >> then stops with: >>>> >>>> [...] >>>> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 >>>> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 >>>> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 >>>> unknown tape header type 1853384566> >> abort? [yn] >>>> >>>> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's >>>> dump's output? >>>> >>>> >>>> > > What happens if you don't use the cache? > >>> >>> >> No big difference: >> >>> dump a0f - /old | restore -rf - >>> >> [...] >> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 >> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 >> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 >> unknown tape header type -621260722> abort? [yn] >> >> Looks like a junk value somewhere... Unitialized variable or some such. >> >> > can you try splitting it in 2, ie no pipe? > dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz) > restore rf some.file > > danny > Well, the first part (the dump) runs almost to the completion, but hangs at the very end for some reason: dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 0 dump: Tue Mar 24 05:59:27 2009 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad2s1e (/ibmo) to /ibm/ibmo.0.2009-03-24.dump DUMP: mapping (Pass I) [regular files] DUMP: Cache 64 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 152357442 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 0.83% done, finished in 9:59 at Tue Mar 24 16:04:19 2009 DUMP: 2.74% done, finished in 5:55 at Tue Mar 24 12:05:07 2009 DUMP: 4.66% done, finished in 5:06 at Tue Mar 24 11:21:27 2009 DUMP: 6.58% done, finished in 4:43 at Tue Mar 24 11:03:37 2009 ... DUMP: 91.54% done, finished in 0:23 at Tue Mar 24 10:38:15 2009 DUMP: 93.41% done, finished in 0:18 at Tue Mar 24 10:38:02 2009 DUMP: 95.27% done, finished in 0:13 at Tue Mar 24 10:37:50 2009 DUMP: 97.15% done, finished in 0:07 at Tue Mar 24 10:37:36 2009 DUMP: 99.03% done, finished in 0:02 at Tue Mar 24 10:37:23 2009 DUMP: DUMP: 152769349 tape blocks on 1 volume DUMP: finished in 16706 seconds, throughput 9144 KBytes/sec [... Hang ...] load: 0.18 cmd: dump 10105 [sbwait] 72.53u 383.14s 0% 73048k load: 0.19 cmd: dump 10102 [sbwait] 164.93u 314.87s 0% 75008k load: 0.10 cmd: dump 10102 [running] 164.93u 314.87s 0% 75008k The timestamp on the output file is, indeed, 10:38 and the dumping process is hanging ever since then (over 90 minutes already). Yours, -mi From mi+thun at aldan.algebra.com Tue Mar 24 11:04:05 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 11:04:11 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> Message-ID: <49C92060.4060303@aldan.algebra.com> Danny Braniss ???????(??): > can you try splitting it in 2, ie no pipe? > dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz) > restore rf some.file > > Same problem: restore -rf ibmo.0.2009-03-24.dump load: 0.55 cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k unknown tape header type 213474529 abort? [yn] Please, advise. Thanks! Yours, -mi From oleg.ginzburg at nevosoft.ru Tue Mar 24 14:30:07 2009 From: oleg.ginzburg at nevosoft.ru (Oleg Ginzburg) Date: Tue Mar 24 14:30:57 2009 Subject: bin/131341: makefs: error "Bad file descriptor" on the mount point of md-presentation makefs image Message-ID: <200903242130.n2OLU4ec049453@freefall.freebsd.org> The following reply was made to PR bin/131341; it has been noted by GNATS. From: Oleg Ginzburg To: Jaakko Heinonen Cc: bug-followup@freebsd.org Subject: Re: bin/131341: makefs: error "Bad file descriptor" on the mount point of md-presentation makefs image Date: Tue, 24 Mar 2009 21:21:14 +0300 Hello Jaakko, I've apply yours http://www.saunalahti.fi/~jh3/patches/ffs-fs_fsbtodb.diff patch and this work fine for my, problem of PR-131341 is gone. Thanks a lot! On Monday 23 March 2009 19:31:30 Jaakko Heinonen wrote: > See this message: > > http://docs.freebsd.org/cgi/mid.cgi?20090323154536.GA2853 > > and a patch: > > http://www.saunalahti.fi/~jh3/patches/ffs-fs_fsbtodb.diff From janm at transactionware.com Tue Mar 24 17:42:28 2009 From: janm at transactionware.com (Jan Mikkelsen) Date: Tue Mar 24 17:42:35 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate In-Reply-To: <20090324224001.D1670@besplex.bde.org> References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> <49C7C45B.7040708@elischer.org> <20090324224001.D1670@besplex.bde.org> Message-ID: <49C97A6F.70204@transactionware.com> Hi, [Jumping into a conversation on aio, async mounts, etc.] I have had a few questions for a while that I haven't asked yet; these seems like an appropriate time to ask them! Is it reasonable to open a file with O_FSYNC and then use aio_write() to issue multiple writes, and then assume that the data is on disk when the aio completes? Can I get I/O parallelism using this approach? I recall reading (some time ago) that FreeBSD doesn't do I/O parallelism on a single file descriptor. Is that true? Do I need to open the file multiple times in order to get I/O parallelism? You can see where I'm going with this: What I'd really like to do is open a file with O_FSYNC | O_DIRECT | O_EXCL, and then do lots of aio operations on it using chunks that a multiple of the page size with buffers that are aligned on page boundaries. I'd like to know when aio writes are "really" complete to maintain various kinds of on-disk structures (eg. b-trees). I'd also like to avoid call fsync(2). Thanks, Jan Mikkelsen From andrew at modulus.org Tue Mar 24 18:05:38 2009 From: andrew at modulus.org (Andrew Snow) Date: Tue Mar 24 18:05:44 2009 Subject: ZFS move from FreeBSD to Opensolaris ? In-Reply-To: <20090324145841.GD17811@datapipe.com> References: <20090324145841.GD17811@datapipe.com> Message-ID: <49C982AF.5010305@modulus.org> Hussain Ali wrote: > On a tangent, I can go from Mac -> OpenSolaris. I am guessing this maybe > due to lack of EFI/GPT labels on the geom providers. I believe Opensolaris writes an EFI label when it is given an entire disk to add to a pool. FreeBSD does not do this or handle this case, it just uses the entire GEOM provider with no labelling. - Andrew From linimon at FreeBSD.org Tue Mar 24 18:14:57 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Mar 24 18:15:02 2009 Subject: kern/133020: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Message-ID: <200903250114.n2P1Eu1b059158@freefall.freebsd.org> Old Synopsis: inappropriate panic caused by zfs. Panic: zfs_fuid_create New Synopsis: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 25 01:14:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133020 From mi+thun at aldan.algebra.com Tue Mar 24 18:19:06 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 18:19:18 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C98202.9040403@modulus.org> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <49C90813.8070705@aldan.algebra.com> <49C98202.9040403@modulus.org> Message-ID: <49C98680.7020301@aldan.algebra.com> Andrew Snow ???????(??): > Mikhail T. wrote: >> dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old >> DUMP: WARNING: should use -L when dumping live read-write >> filesystems! > > I thought you said it was a read-only filesystem? It was yesterday. Today I remounted it rw to remove some junk-files, which I don't need to transfer. I don't believe, this is causing the problems. > In my experience, restore can sometimes throw warnings if you dump a > live filesystem. It might be causing your errors? If possible, can > you try completely unmounting the filesystem you are dumping and > trying again? I don't think, restore can even figure this out, much less throw a warning -- it is dump, that complains... But the dump started this morning is still hanging (in sbwait) -- I've never seen this before. I'm also very troubled, that such an important functionality (dump/restore!) is sooo problem-prone, and yet so few people seem to care... Is the official view, that dump is obsolete (and already bit-rotten), perhaps, and use of tar is encouraged instead? -mi From andrew at modulus.org Tue Mar 24 18:22:37 2009 From: andrew at modulus.org (Andrew Snow) Date: Tue Mar 24 18:22:44 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C90813.8070705@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <49C90813.8070705@aldan.algebra.com> Message-ID: <49C98202.9040403@modulus.org> Mikhail T. wrote: > dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old > DUMP: WARNING: should use -L when dumping live read-write filesystems! I thought you said it was a read-only filesystem? In my experience, restore can sometimes throw warnings if you dump a live filesystem. It might be causing your errors? If possible, can you try completely unmounting the filesystem you are dumping and trying again? From ota at j.email.ne.jp Tue Mar 24 18:34:21 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Tue Mar 24 18:34:28 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C87E0D.5090501@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> Message-ID: <20090324211549.27e65b90.ota@j.email.ne.jp> On Tue, 24 Mar 2009 02:30:37 -0400 "Mikhail T." wrote: > Daniel O'Connor ???????(??): > > On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote: > > > >> I'm trying to migrate a filesystem from one disk to another using: > >> > >> dump a0hCf 0 32 - /old | restore -rf - > >> > >> (/old is already mounted read-only). The process runs for a while and > >> then stops with: > >> > >> [...] > >> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 > >> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 > >> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 > >> unknown tape header type 1853384566 > >> abort? [yn] > >> > >> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's > >> dump's output? > >> > > > > What happens if you don't use the cache? > > > No big difference: > > dump a0f - /old | restore -rf - > [...] > DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 > DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 > DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 > unknown tape header type -621260722 > abort? [yn] > > Looks like a junk value somewhere... Unitialized variable or some such. > > -mi -a option seems to be the problem. Try without it. Hiro From doconnor at gsoft.com.au Tue Mar 24 19:02:22 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Mar 24 19:02:34 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C98680.7020301@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <49C98202.9040403@modulus.org> <49C98680.7020301@aldan.algebra.com> Message-ID: <200903251232.11418.doconnor@gsoft.com.au> On Wednesday 25 March 2009 11:48:56 Mikhail T. wrote: > Andrew Snow ???????(??): > > Mikhail T. wrote: > >> dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old > >> DUMP: WARNING: should use -L when dumping live read-write > >> filesystems! > > > > I thought you said it was a read-only filesystem? > > It was yesterday. Today I remounted it rw to remove some junk-files, > which I don't need to transfer. I don't believe, this is causing the > problems. > > > In my experience, restore can sometimes throw warnings if you dump a > > live filesystem. It might be causing your errors? If possible, can > > you try completely unmounting the filesystem you are dumping and > > trying again? > > I don't think, restore can even figure this out, much less throw a > warning -- it is dump, that complains... But the dump started this restore will emit a warning if dump writes a stream that is out of order because of a live file system but that is not what you are seeing. > morning is still hanging (in sbwait) -- I've never seen this before. I'm > also very troubled, that such an important functionality (dump/restore!) > is sooo problem-prone, and yet so few people seem to care... Well, "works for me". > Is the official view, that dump is obsolete (and already bit-rotten), > perhaps, and use of tar is encouraged instead? I've never had dump fail but it IS rather crusty and slow.. That said tar doesn't cover all the information I believe. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090325/ba15cfeb/attachment.pgp From mi+thun at aldan.algebra.com Tue Mar 24 19:08:14 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 19:08:26 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <200903251232.11418.doconnor@gsoft.com.au> References: <49C83673.3000604@aldan.algebra.com> <49C98202.9040403@modulus.org> <49C98680.7020301@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> Message-ID: <49C99204.2050601@aldan.algebra.com> Daniel O'Connor ???????(??): >> morning is still hanging (in sbwait) -- I've never seen this before. I'm >> also very troubled, that such an important functionality (dump/restore!) >> is sooo problem-prone, and yet so few people seem to care... >> > > Well, "works for me". > Well, would like a login on this system to take a look for yourself? I can reproduce the problem easily. >> Is the official view, that dump is obsolete (and already bit-rotten), >> perhaps, and use of tar is encouraged instead? >> > > I've never had dump fail but it IS rather crusty and slow.. That said tar > doesn't cover all the information I believe. So, if dump/restore ain't it, does FreeBSD have a supported way of making filesystem-level backups, that's both modern and covers all aspects (like flags)? That said, I point out, that for me, dump is not failing (although it did hang this morning). It is the restore, which fails to read dump's output: unknown tape header type 213474529 abort? [yn] n resync restore, skipped 502 blocks expected next file 54, got 0 unknown tape header type -954356454 abort? [yn] n resync restore, skipped 29 blocks expected next file 54, got 0 unknown tape header type -1754938223 abort? [yn] n resync restore, skipped 482 blocks expected next file 54, got 0 unknown tape header type -915868704 abort? [yn] n resync restore, skipped 29 blocks expected next file 54, got 0 unknown tape header type 1790084751 abort? [yn] n resync restore, skipped 482 blocks expected next file 54, got 0 unknown tape header type 903667267 abort? [yn] n ... Thanks! -mi From mi+thun at aldan.algebra.com Tue Mar 24 19:40:25 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 19:40:38 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <20090324211549.27e65b90.ota@j.email.ne.jp> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <20090324211549.27e65b90.ota@j.email.ne.jp> Message-ID: <49C99997.9050306@aldan.algebra.com> Yoshihiro Ota ???????(??): >> No big difference: >> dump a0f - /old | restore -rf - >> [...] >> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 >> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 >> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 >> unknown tape header type -621260722 >> abort? [yn] >> >> Looks like a junk value somewhere... Unitialized variable or some such. >> >> -mi >> > > -a option seems to be the problem. > Try without it. > As could be expected, it failed exactly the same without the obviously unrelated -a option: root@symbion:/ibm (113) dump 0f - /ibmo | restore -rf - DUMP: Date of this level 0 dump: Tue Mar 24 21:31:19 2009 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad2s1e (/ibmo) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 152357442 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 0.16% done, finished in 242:05 at Sat Apr 4 00:00:21 2009 DUMP: 4.29% done, finished in 10:24 at Wed Mar 25 08:24:02 2009 DUMP: 8.56% done, finished in 5:52 at Wed Mar 25 03:56:43 2009 DUMP: 11.76% done, finished in 4:35 at Wed Mar 25 02:43:29 2009 DUMP: 16.00% done, finished in 3:38 at Wed Mar 25 01:52:05 2009 DUMP: 19.28% done, finished in 3:15 at Wed Mar 25 01:33:43 2009 DUMP: 22.74% done, finished in 2:55 at Wed Mar 25 01:18:49 2009 unknown tape header type 1431655765 abort? [yn] n resync restore, skipped 9 blocks expected next file 1599492, got 0 DUMP: 24.50% done, finished in 3:27 at Wed Mar 25 02:05:41 2009 unknown tape header type 1508167078 abort? [yn] n resync restore, skipped 66 blocks expected next file 1599492, got 0 unknown tape header type -1493630979 abort? [yn] y dump core? [yn] n DUMP: Broken pipe DUMP: The ENTIRE dump is aborted. Now can one get /real/ support for the most basic functionality of the most advanced modern Unix in the world? Thanks, -mi From andrew at modulus.org Tue Mar 24 20:02:33 2009 From: andrew at modulus.org (Andrew Snow) Date: Tue Mar 24 20:02:41 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C99997.9050306@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <20090324211549.27e65b90.ota@j.email.ne.jp> <49C99997.9050306@aldan.algebra.com> Message-ID: <49C99E03.9060604@modulus.org> Mikhail T. wrote: > Now can one get /real/ support for the most basic functionality of the > most advanced modern Unix in the world? Thanks, I think before this goes any further, you will need to try rebooting/unmouting it, running fsck on it, and then dump the unmounted partition and see how that goes. - Andrew From doconnor at gsoft.com.au Tue Mar 24 20:05:03 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Mar 24 20:05:09 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C99204.2050601@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> Message-ID: <200903251334.38350.doconnor@gsoft.com.au> On Wednesday 25 March 2009 12:38:04 Mikhail T. wrote: > Daniel O'Connor ???????(??): > >> morning is still hanging (in sbwait) -- I've never seen this before. I'm > >> also very troubled, that such an important functionality (dump/restore!) > >> is sooo problem-prone, and yet so few people seem to care... > > > > Well, "works for me". > > Well, would like a login on this system to take a look for yourself? I > can reproduce the problem easily. I don't know the internals of dump/restore :( > >> Is the official view, that dump is obsolete (and already bit-rotten), > >> perhaps, and use of tar is encouraged instead? > > > > I've never had dump fail but it IS rather crusty and slow.. That said tar > > doesn't cover all the information I believe. > > So, if dump/restore ain't it, does FreeBSD have a supported way of > making filesystem-level backups, that's both modern and covers all > aspects (like flags)? I would try a pax archive, eg.. tar --format pax --one-file-system -pcf - -C / . | tar -pxf - -C /mnt/newdisk According to the libarchive-formats page this handles ACLs & flags, my testing shows it handles flags (at least). eg.. [midget 13:30] /tmp/test2 >touch foo [midget 13:30] /tmp/test2 >chflags uchg foo [midget 13:30] /tmp/test2 >tar --format pax -zpcf /tmp/test.pax.gz foo [midget 13:30] /tmp/test2 >rm -f foo rm: foo: Operation not permitted [midget 13:30] /tmp/test2 >chflags nouchg foo [midget 13:30] /tmp/test2 >rm foo [midget 13:30] /tmp/test2 >tar -pxf /tmp/test.pax.gz [midget 13:30] /tmp/test2 >ls -lao total 30 drwxr-xr-x 2 darius wheel - 512 Mar 25 13:30 . drwxrwxrwt 53 root wheel - 28672 Mar 25 13:29 .. -rw-r--r-- 1 darius wheel uchg 0 Mar 25 13:30 foo [midget 13:30] /tmp/test2 >rm -f foo rm: foo: Operation not permitted > That said, I point out, that for me, dump is not failing (although it > did hang this morning). It is the restore, which fails to read dump's > output: You can't tell the difference between dump producing mangled output or restore bombing out on valid input.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090325/bc00de19/attachment.pgp From mi+thun at aldan.algebra.com Tue Mar 24 20:05:41 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 20:05:52 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C99E03.9060604@modulus.org> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <20090324211549.27e65b90.ota@j.email.ne.jp> <49C99997.9050306@aldan.algebra.com> <49C99E03.9060604@modulus.org> Message-ID: <49C99F7E.2010108@aldan.algebra.com> Andrew Snow ???????(??): > Mikhail T. wrote: > >> Now can one get /real/ support for the most basic functionality of the >> most advanced modern Unix in the world? Thanks, >> > > I think before this goes any further, you will need to try > rebooting/unmouting it, running fsck on it, and then dump the unmounted > partition and see how that goes. > The system's uptime is only 3 days -- I had to reboot it to put in the new disk... But I will try your suggestion next, after the current attempt (using restore's -v switch) ends. If it chokes on the same file every time, that would be a clue... Thanks, -mi From mi+thun at aldan.algebra.com Tue Mar 24 20:07:01 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 20:07:13 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <200903251334.38350.doconnor@gsoft.com.au> References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> Message-ID: <49C99FD2.50609@aldan.algebra.com> Daniel O'Connor ???????(??): >> That said, I point out, that for me, dump is not failing (although it >> did hang this morning). It is the restore, which fails to read dump's >> output: >> > > You can't tell the difference between dump producing mangled output or restore > bombing out on valid input.. > That's true. I just wanted to point out, that someone running dump only (to make backups) is not going to know, whether his dumps are usable (for whichever of the two reasons), until he needs them... -mi From doconnor at gsoft.com.au Tue Mar 24 20:59:51 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Mar 24 21:00:04 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C99997.9050306@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <20090324211549.27e65b90.ota@j.email.ne.jp> <49C99997.9050306@aldan.algebra.com> Message-ID: <200903251429.40578.doconnor@gsoft.com.au> On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote: > Now can one get /real/ support for the most basic functionality of the > most advanced modern Unix in the world? Thanks, Maybe you should return it to the shop and ask for your money back. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090325/b8fd1a20/attachment.pgp From mi+thun at aldan.algebra.com Tue Mar 24 21:05:04 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 21:05:10 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <200903251429.40578.doconnor@gsoft.com.au> References: <49C83673.3000604@aldan.algebra.com> <20090324211549.27e65b90.ota@j.email.ne.jp> <49C99997.9050306@aldan.algebra.com> <200903251429.40578.doconnor@gsoft.com.au> Message-ID: <49C9AD6D.30305@aldan.algebra.com> Daniel O'Connor ???????(??): > On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote: > >> Now can one get /real/ support for the most basic functionality of the >> most advanced modern Unix in the world? Thanks, >> > > Maybe you should return it to the shop and ask for your money back. > Well, if this response is the best one can get, may be I should also revoke my own 15 years worth of contributions to the project... Except, why would I? I always supported people, who had problems with any of my work -- and the attitude of the rest of the contributors /used to be/ the same... -mi From doconnor at gsoft.com.au Tue Mar 24 21:22:53 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Mar 24 21:23:00 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C9AD6D.30305@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903251429.40578.doconnor@gsoft.com.au> <49C9AD6D.30305@aldan.algebra.com> Message-ID: <200903251452.42301.doconnor@gsoft.com.au> On Wednesday 25 March 2009 14:35:01 Mikhail T. wrote: > Daniel O'Connor ???????(??): > > On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote: > >> Now can one get /real/ support for the most basic functionality of the > >> most advanced modern Unix in the world? Thanks, > > > > Maybe you should return it to the shop and ask for your money back. > > Well, if this response is the best one can get, may be I should also > revoke my own 15 years worth of contributions to the project... > > Except, why would I? I always supported people, who had problems with > any of my work -- and the attitude of the rest of the contributors /used > to be/ the same... People ARE helping you, just because they haven't come up with an answer is no reason to send snarky comments to the list. Outrage (fake or otherwise) that people don't seem to be taking your particular problem seriously is unhelpful and probably counter-productive. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090325/0e125c74/attachment.pgp From mi+thun at aldan.algebra.com Tue Mar 24 21:29:38 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 21:30:05 2009 Subject: support quality (Re: dump | restore fails: unknown tape header type 1853384566) In-Reply-To: <200903251452.42301.doconnor@gsoft.com.au> References: <49C83673.3000604@aldan.algebra.com> <200903251429.40578.doconnor@gsoft.com.au> <49C9AD6D.30305@aldan.algebra.com> <200903251452.42301.doconnor@gsoft.com.au> Message-ID: <49C9B330.10500@aldan.algebra.com> Daniel O'Connor ???????(??): > People ARE helping you, just because they haven't come up with an answer is no > reason to send snarky comments to the list. > No, sorry, people aren't. They are trying, yes, but not even close. The suggestion to eliminate the -a switch (a no-op, in fact) was particularly unhelpful -- and deserving of mockery. Later on someone with a similar problem will find this thread with a search engine and will be trying to follow the posted advices -- to no avail, of course, plunging FreeBSD further into disrepute. > Outrage (fake or otherwise) that people don't seem to be taking your > particular problem seriously is unhelpful and probably counter-productive. It is fairly obvious by now, that no real help will be forthcoming, for whatever reason. Thus any talk of "productivity" is moot. Thanks for trying. -mi From mi+thun at aldan.algebra.com Tue Mar 24 21:30:50 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Tue Mar 24 21:31:02 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C99E03.9060604@modulus.org> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <20090324211549.27e65b90.ota@j.email.ne.jp> <49C99997.9050306@aldan.algebra.com> <49C99E03.9060604@modulus.org> Message-ID: <49C9B377.5090903@aldan.algebra.com> Andrew Snow ???????(??): > I think before this goes any further, you will need to try > rebooting/unmouting it, running fsck on it, and then dump the unmounted > partition and see how that goes. > > Rebooted, reran `fsck -y /old' (all clean). Same problem... -mi From markir at paradise.net.nz Tue Mar 24 21:54:40 2009 From: markir at paradise.net.nz (Mark Kirkwood) Date: Tue Mar 24 21:54:47 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C99204.2050601@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <49C98202.9040403@modulus.org> <49C98680.7020301@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> Message-ID: <49C9B57F.4010403@paradise.net.nz> Mikhail T. wrote: > > That said, I point out, that for me, dump is not failing (although it > did hang this morning). It is the restore, which fails to read dump's > output: > > unknown tape header type 213474529 > abort? [yn] n > resync restore, skipped 502 blocks > expected next file 54, got 0 > unknown tape header type -954356454 > abort? [yn] n > resync restore, skipped 29 blocks > expected next file 54, got 0 > unknown tape header type -1754938223 > abort? [yn] n > resync restore, skipped 482 blocks > expected next file 54, got 0 > unknown tape header type -915868704 > abort? [yn] n > resync restore, skipped 29 blocks > expected next file 54, got 0 > unknown tape header type 1790084751 > abort? [yn] n > resync restore, skipped 482 blocks > expected next file 54, got 0 > unknown tape header type 903667267 > abort? [yn] n > ... > Is this link any help? http://www.mail-archive.com/freebsd-questions@freebsd.org/msg197899.html Other than that, I'd suggest checking the disk(s) with smartmontools to try to rule out hardware problems. regards Mark From freebsd-nospam at yaxom.com Tue Mar 24 22:22:45 2009 From: freebsd-nospam at yaxom.com (Greg Black) Date: Tue Mar 24 22:22:52 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C99FD2.50609@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> Message-ID: On 2009-03-24, Mikhail T. wrote: > That's true. I just wanted to point out, that someone running dump only > (to make backups) is not going to know, whether his dumps are usable > (for whichever of the two reasons), until he needs them... Such a person is not making backups and deserves what he gets. I haven't got anything to say about dump/restore because I haven't bothered with them for years. I do know that dumps from mounted file systems will often appear to work, but will fail when it matters. This is not a bug and is expected behaviour to which the solution is obvious. From doconnor at gsoft.com.au Wed Mar 25 00:58:15 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Mar 25 00:58:28 2009 Subject: support quality (Re: dump | restore fails: unknown tape header type 1853384566) In-Reply-To: <49C9B330.10500@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903251452.42301.doconnor@gsoft.com.au> <49C9B330.10500@aldan.algebra.com> Message-ID: <200903251820.54749.doconnor@gsoft.com.au> On Wednesday 25 March 2009 14:59:36 Mikhail T. wrote: > Daniel O'Connor ???????(??): > > People ARE helping you, just because they haven't come up with an answer > > is no reason to send snarky comments to the list. > > No, sorry, people aren't. They are trying, yes, but not even close. The > suggestion to eliminate the -a switch (a no-op, in fact) was > particularly unhelpful -- and deserving of mockery. Later on someone > with a similar problem will find this thread with a search engine and > will be trying to follow the posted advices -- to no avail, of course, > plunging FreeBSD further into disrepute. I don't see how whining about it's going to change it. Insulting people for having a helpful attitude (even if it didn't solve your problem) is not going to reward them for their time and effort. > > Outrage (fake or otherwise) that people don't seem to be taking your > > particular problem seriously is unhelpful and probably > > counter-productive. > > It is fairly obvious by now, that no real help will be forthcoming, for > whatever reason. Thus any talk of "productivity" is moot. Thanks for > trying. Except that I offered you a way of transferring your files that would preserve file flags and so on. Yes, dump is broken for you, deal with it. It is quite possible your FS is corrupt, and/or your disk is damaged. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090325/bb81e316/attachment.pgp From admin at kkip.pl Wed Mar 25 01:31:56 2009 From: admin at kkip.pl (Bartosz Stec) Date: Wed Mar 25 01:32:09 2009 Subject: support quality (Re: dump | restore fails: unknown tape header type 1853384566) In-Reply-To: <200903251820.54749.doconnor@gsoft.com.au> References: <49C83673.3000604@aldan.algebra.com> <200903251452.42301.doconnor@gsoft.com.au> <49C9B330.10500@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> Message-ID: <49C9E635.5010106@kkip.pl> > Yes, dump is broken for you, deal with it. It is quite possible your FS is > corrupt, and/or your disk is damaged. > > ..and/or it is some other hardware problem, maybe you also should test your memory with memtest or something similiar? I'm using dump/restore very frequently and I had never seen such problem. Neither on -RELAESE, -STABLE, nor -CURRENT. So I think you should make sure that your problem is not hardware/filesystem dependent before you point dump/restore as a couse of the problem. Peter Jeremy already gives you good hints to do that. -- Bartosz Stec. From doconnor at gsoft.com.au Wed Mar 25 01:55:48 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Mar 25 01:55:54 2009 Subject: support quality (Re: dump | restore fails: unknown tape header type 1853384566) In-Reply-To: <49C9E635.5010106@kkip.pl> References: <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <49C9E635.5010106@kkip.pl> Message-ID: <200903251925.36108.doconnor@gsoft.com.au> On Wednesday 25 March 2009 18:37:17 Bartosz Stec wrote: > > Yes, dump is broken for you, deal with it. It is quite possible your FS > > is corrupt, and/or your disk is damaged. > > ..and/or it is some other hardware problem, maybe you also should test > your memory with memtest or something similiar? I'm using dump/restore > very frequently and I had never seen such problem. Neither on -RELAESE, > -STABLE, nor -CURRENT. > So I think you should make sure that your problem is not > hardware/filesystem dependent before you point dump/restore as a couse > of the problem. Peter Jeremy already gives you good hints to do that. One other thing would be to make absolutely sure that your version of dump & restore are in sync, the are very machine/version dependent. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090325/7feff92e/attachment.pgp From jacks at sage-american.com Wed Mar 25 05:32:44 2009 From: jacks at sage-american.com (Jack L. Stone) Date: Wed Mar 25 05:32:57 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <200903251925.36108.doconnor@gsoft.com.au> References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <49C9E635.5010106@kkip.pl> Message-ID: <3.0.1.32.20090325072137.00ee6b48@sage-american.com> At 07:25 PM 3.25.2009 +1030, Daniel O'Connor wrote: >On Wednesday 25 March 2009 18:37:17 Bartosz Stec wrote: >> > Yes, dump is broken for you, deal with it. It is quite possible your FS >> > is corrupt, and/or your disk is damaged. >> >> ..and/or it is some other hardware problem, maybe you also should test >> your memory with memtest or something similiar? I'm using dump/restore >> very frequently and I had never seen such problem. Neither on -RELAESE, >> -STABLE, nor -CURRENT. >> So I think you should make sure that your problem is not >> hardware/filesystem dependent before you point dump/restore as a couse >> of the problem. Peter Jeremy already gives you good hints to do that. > >One other thing would be to make absolutely sure that your version of dump & >restore are in sync, the are very machine/version dependent. > >-- I've been watching this thread with some interest since we've had some similar problems with dump/restore which we use every morning via cron scripts on a number of servers to produce bootable clones as part of our backup program. Have been doing this for years and also never saw a problem as most of you say. We prefer dump/restore for backups. However, last month upon upon upgrading those servers from FBSD-6.3px (RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers had a similar problem as the original poster while the other half did not. All of the servers (rackmounts) use the same (type) hardware. We spent many hours trying to solve the problem with those that failed to dump/restore. Also, searched for any others with the problem and only found a very few, but without solutions to this issue. (Indeed, the only one was a reference to any efforts to restore an older OS version which didn't apply here). And, indeed we tried everything suggested here to fix the proble without success. Sometimes the problem was dump which would reach 99% and never finish -- it would stick there and would overlap with another cron start the next day, and the next day, and the next day. (The servers that did work fooled us and we found out about this issue on the others when the overlaps appeared and drew our attention). That's when our work to try and solve the issues started and went on for days. Our script that has always worked contained this (after scraping and making fresh FS): /sbin/dump -D /root/dumpdates -0auL -f - / | /sbin/restore -rf - Indeed, the first thing we did was to remove the pipe and tried to restore from a file. However, because the dumps would not go past the 99%, no file to restore from! There were some exceptions when the dump would complete, but was not reliable. When these reached the restore level, restore would go crazy with errors. SOLUTION The "clones" are a very important pasrt of our backup program. Since the dump side of the problems simply stuck and provided no error message at all and the errors from any restores were not useful, our only solution was to revert back to FBSD-6.3 on those servers with this issue and dump/restore went back to working again. We left those that were working on FBSD-7.0-R and they continue to work okay. We could only conclude that the problem was perhaps something with hardeware, perhaps the way memory was handled in 7.0, but that is only a guess. Once again, every suggestion on this thread was tried during our long efforts to fix the issue. Perhaps there is yet another suggestion? In the meantime, we've decided to wait for 7.2R (7.1 did not fix the problems either). /Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american From brde at optusnet.com.au Wed Mar 25 05:50:40 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Mar 25 05:50:47 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate In-Reply-To: <49C97A6F.70204@transactionware.com> References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> <49C7C45B.7040708@elischer.org> <20090324224001.D1670@besplex.bde.org> <49C97A6F.70204@transactionware.com> Message-ID: <20090325223213.P35996@delplex.bde.org> On Wed, 25 Mar 2009, Jan Mikkelsen wrote: > [Jumping into a conversation on aio, async mounts, etc.] > > I have had a few questions for a while that I haven't asked yet; these seems > like an appropriate time to ask them! > > Is it reasonable to open a file with O_FSYNC and then use aio_write() to > issue multiple writes, and then assume that the data is on disk when the aio > completes? I know very little about aio, but looking at the sources seems to show that O_FSYNC (or mounting with the sync option) just defeats the asyncness of aio. aio seems to use only fo_write() for writing, so at lower (file system) levels, O_FSYNC has the same behaviour as for write(2) -- it syncs the i/o at the end of the call in the usual case where fo_write = vn_write. > Can I get I/O parallelism using this approach? Apparently not. > I recall reading (some time > ago) that FreeBSD doesn't do I/O parallelism on a single file descriptor. Is > that true? Do I need to open the file multiple times in order to get I/O > parallelism? The fs part of vn_write() is serialized, now using the exclusive vnode lock. The code is essentially: vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); error = VOP_WRITE(...); /* this soon reaches foofs_write() */ VOP_UNLOCK(vp); In the usual case without O_FSYNC, foofs should try to only schedule the i/o (by writing it to the buffer cache and not waiting), so that the actual i/o is done in parallel later. However, foofs might need to do some physical input in order to tell where to write (e.g., reading indirect block(s)) or some physical output of metadata needed for consistency (e.g., writing indirect blocks), and any such i/o is serialized. (I think most file systems avoid writing to the inode on every foofs_write(), though not doing requires tricks to maintain consistency. No tricks seem to be available for indirect blocks, so ffs without soft updates always writes them synchronously (except in my version where the async mount option actually works for indurect blocks).) O_FSYNC should cause almost all writes related to the file to be synced at the end of foofs_write(). Thus it forces all i/o to be serialized. Some excepions to "all": - at least in ffs, bitmap blocks are not synced. This is safe since fsck can always recover bitmap blocks. - at least in ffs, directories above the file are not synced by fsync() for the file. This is normally harmless because critical directory operations are normally synchronous (or ordered relative to everything including related file operations in the case of soft updates), and fsync() is not specified to do this (?), but perhaps careful applications should fsync() all the directories too, and with the async mount option, even the most critical directory operation (creation of the file's directory entry) is asynchronous (except bugs make it partly synchronus). - at least in ffs, with the async mount option, fsync() is more broken than it should be broken -- it syncs everything except for the most critical metadata (the inode) and directories above the file. > You can see where I'm going with this: What I'd really like to do is open a > file with O_FSYNC | O_DIRECT | O_EXCL, and then do lots of aio operations on > it using chunks that a multiple of the page size with buffers that are > aligned on page boundaries. I'd like to know when aio writes are "really" > complete to maintain various kinds of on-disk structures (eg. b-trees). I'd > also like to avoid call fsync(2). Calling fsync() or aio_waitcomplete() seems to be necessary. More global options like the sync mount flag and O_FSYNC don't provide enough control. I can't find any aio interfaces to select or poll for completion. It seems to have only aio_return() to test for completion, with the possibly unwanted side effect of doing the completion if possible. I don't trust aio_return() to test that _all_ the things that would be done by the file system for fsync(2) have been done. aio_waitcomplete ensures doing these things by calling the file system (VOP_FSYNC()), but aio_return() doesn't seem to go near the file system. BTW, I just remembered that there is no mount option or file flag to give fully sync metadata. At least in ffs, all inode-change operations (chmod(), chown(), fchmod(), fchown(), etc.) are async, irrespective of mount options and O_FSYNC. It takes a syscall calling VOP_FSYNC() or an unrelated inode update to sync the metadata for these operations. Bruce From mozart at lib.uchicago.edu Wed Mar 25 07:56:39 2009 From: mozart at lib.uchicago.edu (Peggy Wilkins) Date: Wed Mar 25 07:56:46 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <3.0.1.32.20090325072137.00ee6b48@sage-american.com> References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> Message-ID: >>>>> Jack L Stone writes: >> I've been watching this thread with some interest since we've had some >> similar problems with dump/restore which we use every morning via cron >> scripts on a number of servers to produce bootable clones as part of our >> backup program. Have been doing this for years and also never saw a problem >> as most of you say. We prefer dump/restore for backups. >> However, last month upon upon upgrading those servers from FBSD-6.3px >> (RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers >> had a similar problem as the original poster while the other half did not. >> All of the servers (rackmounts) use the same (type) hardware. We spent many >> hours trying to solve the problem with those that failed to dump/restore. >> Also, searched for any others with the problem and only found a very few, >> but without solutions to this issue. (Indeed, the only one was a reference >> to any efforts to restore an older OS version which didn't apply here). [snip] >> SOLUTION >> The "clones" are a very important pasrt of our backup program. Since the >> dump side of the problems simply stuck and provided no error message at all >> and the errors from any restores were not useful, our only solution was to >> revert back to FBSD-6.3 on those servers with this issue and dump/restore >> went back to working again. We left those that were working on FBSD-7.0-R >> and they continue to work okay. I was seeing this same problem on all my 64-bit systems: FreeBSD-7 dump would hang at a random point. Dump continues to work flawlessly for me on FreeBSD-7/i386. I ran across this which includes a patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=121684 The kernel patch linked to there solved the problem for me, but I am running many production systems and am unwilling to apply this patch to -RELEASE every time there is a kernel update (I just use the standard GENERIC kernel which I get via freebsd-update). I now live without dump on amd64. Apparently this fix is waiting on some related issue; and I will be very happy when it makes it to the officially released kernel. plw From mr at FreeBSD.org Wed Mar 25 08:59:39 2009 From: mr at FreeBSD.org (mr@FreeBSD.org) Date: Wed Mar 25 08:59:45 2009 Subject: kern/133020: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Message-ID: <200903251559.n2PFxcFZ094719@freefall.freebsd.org> Synopsis: [zfs] [panic] inappropriate panic caused by zfs. Panic: zfs_fuid_create Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: mr Responsible-Changed-When: Wed Mar 25 15:57:50 UTC 2009 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=133020 From mi+thun at aldan.algebra.com Wed Mar 25 09:05:02 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Wed Mar 25 09:05:15 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> Message-ID: <49CA5602.9050001@aldan.algebra.com> Greg Black ???????(??): > On 2009-03-24, Mikhail T. wrote: > >> That's true. I just wanted to point out, that someone running dump only >> (to make backups) is not going to know, whether his dumps are usable >> (for whichever of the two reasons), until he needs them... >> > > Such a person is not making backups and deserves what he gets. > But he *is* making backups -- kindly re-read my paragraph above... He just is not routinely using them and thus does not know, that they aren't usable... It is not unreasonable to expect the two utilities to "just work", so I wouldn't be blaming such a person for not testing restore. That such a scenario is possible, despite the user making diligent regular backups, is a very bad sign... > I haven't got anything to say about dump/restore because I haven't > bothered with them for years. I do know that dumps from mounted file > systems will often appear to work, but will fail when it matters. This > is not a bug and is expected behaviour to which the solution is obvious. > FS being mounted read-only should not be a problem. And even read-write mounted filesystems will be Ok, although possibly inconsistent (a file modified during backup may get to into dump "as of" any point). But an idle FS is Ok to dump. Generally, when dumping read-write mounted filesystems, one is supposed to use snapshots, but that is very buggy on its own (leading to kernel crashes), so it is safer to rely on the FS being "idle", if it can not be forced into read-only for some other reason. -mi From dimitry at andric.com Wed Mar 25 09:11:40 2009 From: dimitry at andric.com (Dimitry Andric) Date: Wed Mar 25 09:11:52 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C87E0D.5090501@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> Message-ID: <49CA57BB.2070409@andric.com> On 2009-03-24 07:30, Mikhail T. wrote: > dump a0f - /old | restore -rf - > [...] > DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 > DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 > DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 > unknown tape header type -621260722 > abort? [yn] > > Looks like a junk value somewhere... Unitialized variable or some such. Hmm, I can't reproduce this at all; I use dump and restore quite regularly in this way, and I have never encountered this issue (except for the occasional 'expected file NNN, got file MMM', which is usually harmless). Maybe the dump output gets corrupted in some way? (E.g. faulty RAM, or disk?) If you are dumping a live filesystem, could it possibly help to add the -L option? From julian at elischer.org Wed Mar 25 10:22:13 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Mar 25 10:22:20 2009 Subject: Trying to understand how aio(4), mount(8) async (and gjournal) relate In-Reply-To: <20090325223213.P35996@delplex.bde.org> References: <200903231733.51671.mel.flynn+fbsd.fs@mailing.thruhere.net> <49C7C45B.7040708@elischer.org> <20090324224001.D1670@besplex.bde.org> <49C97A6F.70204@transactionware.com> <20090325223213.P35996@delplex.bde.org> Message-ID: <49CA684F.70604@elischer.org> Bruce Evans wrote: > On Wed, 25 Mar 2009, Jan Mikkelsen wrote: > >> [Jumping into a conversation on aio, async mounts, etc.] >> >> I have had a few questions for a while that I haven't asked yet; these >> seems like an appropriate time to ask them! >> >> Is it reasonable to open a file with O_FSYNC and then use aio_write() >> to issue multiple writes, and then assume that the data is on disk >> when the aio completes? > > I know very little about aio, but looking at the sources seems to show that > O_FSYNC (or mounting with the sync option) just defeats the asyncness of > aio. aio seems to use only fo_write() for writing, so at lower (file > system) levels, O_FSYNC has the same behaviour as for write(2) -- it syncs > the i/o at the end of the call in the usual case where fo_write = vn_write. > >> Can I get I/O parallelism using this approach? > > Apparently not. > >> I recall reading (some time ago) that FreeBSD doesn't do I/O >> parallelism on a single file descriptor. Is that true? Do I need to >> open the file multiple times in order to get I/O parallelism? > > The fs part of vn_write() is serialized, now using the exclusive vnode > lock. > The code is essentially: > > vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); > error = VOP_WRITE(...); /* this soon reaches foofs_write() */ > VOP_UNLOCK(vp); > > In the usual case without O_FSYNC, foofs should try to only schedule > the i/o (by writing it to the buffer cache and not waiting), so that > the actual i/o is done in parallel later. However, foofs might need > to do some physical input in order to tell where to write (e.g., reading > indirect block(s)) or some physical output of metadata needed for > consistency (e.g., writing indirect blocks), and any such i/o is > serialized. (I think most file systems avoid writing to the inode on > every foofs_write(), though not doing requires tricks to maintain > consistency. No tricks seem to be available for indirect blocks, so > ffs without soft updates always writes them synchronously (except in > my version where the async mount option actually works for indurect > blocks).) > > O_FSYNC should cause almost all writes related to the file to be > synced at the end of foofs_write(). Thus it forces all i/o to be > serialized. > Some excepions to "all": > - at least in ffs, bitmap blocks are not synced. This is safe since > fsck can always recover bitmap blocks. > - at least in ffs, directories above the file are not synced by fsync() > for the file. This is normally harmless because critical directory > operations are normally synchronous (or ordered relative to everything > including related file operations in the case of soft updates), and > fsync() is not specified to do this (?), but perhaps careful > applications should fsync() all the directories too, and with the > async mount option, even the most critical directory operation > (creation of the file's directory entry) is asynchronous (except > bugs make it partly synchronus). > - at least in ffs, with the async mount option, fsync() is more broken than > it should be broken -- it syncs everything except for the most critical > metadata (the inode) and directories above the file. > >> You can see where I'm going with this: What I'd really like to do is >> open a file with O_FSYNC | O_DIRECT | O_EXCL, and then do lots of aio >> operations on it using chunks that a multiple of the page size with >> buffers that are aligned on page boundaries. I'd like to know when >> aio writes are "really" complete to maintain various kinds of on-disk >> structures (eg. b-trees). I'd also like to avoid call fsync(2). > > Calling fsync() or aio_waitcomplete() seems to be necessary. More > global options like the sync mount flag and O_FSYNC don't provide > enough control. I can't find any aio interfaces to select or poll for > completion. it does have a comprehensive interface with kqueue. > It seems to have only aio_return() to test for completion, > with the possibly unwanted side effect of doing the completion if > possible. I don't trust aio_return() to test that _all_ the things > that would be done by the file system for fsync(2) have been done. > aio_waitcomplete ensures doing these things by calling the file system > (VOP_FSYNC()), but aio_return() doesn't seem to go near the file system. > > BTW, I just remembered that there is no mount option or file flag to > give fully sync metadata. At least in ffs, all inode-change operations > (chmod(), chown(), fchmod(), fchown(), etc.) are async, irrespective of > mount options and O_FSYNC. It takes a syscall calling VOP_FSYNC() or > an unrelated inode update to sync the metadata for these operations. > > Bruce From brucec at FreeBSD.org Wed Mar 25 10:30:21 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 10:30:28 2009 Subject: kern/89991: [ufs] softupdates with mount -ur causes fs UNREFS Message-ID: <200903251730.n2PHUFCQ019385@freefall.freebsd.org> Synopsis: [ufs] softupdates with mount -ur causes fs UNREFS Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 17:29:30 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=89991 From brucec at FreeBSD.org Wed Mar 25 10:31:04 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 10:31:16 2009 Subject: kern/94480: [libufs] [patch] bread(3) & bwrite(3) can crash under low memory conditions Message-ID: <200903251731.n2PHV1I7022415@freefall.freebsd.org> Synopsis: [libufs] [patch] bread(3) & bwrite(3) can crash under low memory conditions Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 17:30:41 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94480 From hywel at hmallett.co.uk Wed Mar 25 11:13:40 2009 From: hywel at hmallett.co.uk (Hywel Mallett) Date: Wed Mar 25 11:13:48 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49CA57BB.2070409@andric.com> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <49CA57BB.2070409@andric.com> Message-ID: <20090325171903.x4eqs9ceo8w00c04@www.hmallett.co.uk> Quoting Dimitry Andric : > On 2009-03-24 07:30, Mikhail T. wrote: >> dump a0f - /old | restore -rf - >> [...] >> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009 >> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009 >> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009 >> unknown tape header type -621260722 >> abort? [yn] >> >> Looks like a junk value somewhere... Unitialized variable or some such. Looking at the restore code (tape.c, in findinode), restore is expecting a header type in the range 1-6, so the header type -621260722 is way out. Assuming that findinode is being passed the correct variable, it would indicate that dump is writing the header (or at least the header type incorrectly). I can't work out where this header is getting written though. It looks like plenty of data gets written into a header (such as inode, magic number, checksum). I wonder if one of these values is overflowing and overwriting the header type? > > Maybe the dump output gets corrupted in some way? (E.g. faulty RAM, or > disk?) If you are dumping a live filesystem, could it possibly help to > add the -L option? It might be worth fscking the original volume (though I suspect the OP has done this already), and also passing the -D option to restore, as restore will then try and continue, rather than abort on getting the invalid header type. Fixing the root cause would be better, but that might be a workaround for now. From brucec at FreeBSD.org Wed Mar 25 11:31:54 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 11:32:06 2009 Subject: kern/51685: [hang] Unbounded inode allocation causes kernel to lock up Message-ID: <200903251831.n2PIVcFr007703@freefall.freebsd.org> Synopsis: [hang] Unbounded inode allocation causes kernel to lock up Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 18:31:16 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=51685 From freebsd at edvax.de Wed Mar 25 15:13:01 2009 From: freebsd at edvax.de (Polytropon) Date: Wed Mar 25 15:13:08 2009 Subject: Repairing a defective UFS 2 partition with another BSD's fsck Message-ID: <20090325224807.81016dd9.freebsd@edvax.de> Dear -fs list, last night I had an idea how I could have a chance to repair my defective UFS partition. To remember, this is the whole story: http://kerneltrap.org/mailarchive/freebsd-fs/2008/11/2/3894714 "Repairing a defective UFS 2 partition with fsck_ffs (or other means)" I thought about the following: As far as I know, UFS isn't only used by FreeBSD, but also by OpenBSD and NetBSD. Variations should be less than, let's say, with Solaris UFS. So it may be that I can use the fsck utility of OpenBSD or NetBSD to check and repair the UFS dd duplicate where FreeBSD's fsck fails with fsck_ffs: bad inode number 306176 to nextinode To use with NetBSD, I've got a NetBSD Live! 2007 live system CD here. For OpenBSD... well, I don't know if they offer any live file system? The only commands I'd need are mount and fsck (both for UFS only). The system should be bootable via CD. Then I would need a shell to do something like this: # mkdir /temp # mount -t ufs -o rw /dev/wd1s1c /temp # cd /temp/rescue # fsck -t ufs -yf ad1s1f.dd In case NetBSD's or OpenBSD's fsck can't operate on the bare file, I'd think about something like: # mkdir /temp # mount -t ufs -o rw /dev/wd1s1c /temp # cd /temp/rescue # mdconfig -a -t vnode -u 10 -f ad1s1f.dd # fsck -t ufs -yf /dev/md10 What do you think, is this even possible? Should I try it? Please keep me CC because I'm on the questions@ list only. Thanks! I'll cross-post it to questions@ in case someone there as an idea for this really strange problem - remember, I'm the second (!) being on this planet having encountered this particular problem. I hope that's an acceptable behaviour. :-) -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... From peterjeremy at optushome.com.au Thu Mar 26 02:37:02 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Mar 26 02:37:09 2009 Subject: support quality (Re: dump | restore fails: unknown tape header type 1853384566) In-Reply-To: <200903251925.36108.doconnor@gsoft.com.au> References: <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <49C9E635.5010106@kkip.pl> <200903251925.36108.doconnor@gsoft.com.au> Message-ID: <20090326092504.GF56137@server.vk2pj.dyndns.org> On 2009-Mar-25 19:25:28 +1030, Daniel O'Connor wrote: >One other thing would be to make absolutely sure that your version of dump & >restore are in sync, the are very machine/version dependent. Actually, they aren't - the archive format is very stable. (This is a fairly important requirement - you don't want to suddenly be unable to restore your backups after an upgrade). I can restore dumps made on FreeBSD4.8/i386 and FreeBSD4.9/alpha on a FreeBSD-current/amd64 system without problems. It's possible that you might have problems with a backup made using a very recent dump on a very old restore if you've used filesystem features that didn't exist when that restore was built. -- 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/20090326/5512de9b/attachment.pgp From peterjeremy at optushome.com.au Thu Mar 26 02:48:25 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Mar 26 02:48:32 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <3.0.1.32.20090325072137.00ee6b48@sage-american.com> References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <49C9E635.5010106@kkip.pl> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> Message-ID: <20090326094821.GG56137@server.vk2pj.dyndns.org> On 2009-Mar-25 07:21:37 -0500, "Jack L. Stone" wrote: >However, last month upon upon upgrading those servers from FBSD-6.3px >(RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers >had a similar problem as the original poster while the other half did not. ... >the next day, and the next day, and the next day. (The servers that did >work fooled us and we found out about this issue on the others when the >overlaps appeared and drew our attention). That's when our work to try and >solve the issues started and went on for days. It's not clear to me whether all your servers have the problem and you only initially noticed it on some of them or some of your servers work and others dont. In the latter case, you are probably in a very good position to identify the problem since it is related to some difference between your servers. >We could only conclude that the problem was perhaps something with >hardeware, perhaps the way memory was handled in 7.0, but that is only a >guess. If you are talking about server-grade hardware (ECC RAM etc) then it's unlikely to be RAM corruption. About the only thing I can think of would be that if you have RAM above 4GB, you might be running foul of an address being truncated somewhere (particularly in a device driver). (The amd64 user memory map changed between 7.x and 8.x but I don't think there was any change between 6.x & 7.x). The pre-emption changes in 7.x and/or moving to an SMP host would seem to increase the probability of hitting the problem fixed in the patch mentioned later (kern/121684). -- 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/20090326/29a59832/attachment.pgp From doconnor at gsoft.com.au Thu Mar 26 02:56:09 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Mar 26 02:56:16 2009 Subject: support quality (Re: dump | restore fails: unknown tape header type 1853384566) In-Reply-To: <20090326092504.GF56137@server.vk2pj.dyndns.org> References: <49C83673.3000604@aldan.algebra.com> <200903251925.36108.doconnor@gsoft.com.au> <20090326092504.GF56137@server.vk2pj.dyndns.org> Message-ID: <200903262025.43890.doconnor@gsoft.com.au> On Thursday 26 March 2009 19:55:04 Peter Jeremy wrote: > On 2009-Mar-25 19:25:28 +1030, Daniel O'Connor wrote: > >One other thing would be to make absolutely sure that your version of dump > > & restore are in sync, the are very machine/version dependent. > > Actually, they aren't - the archive format is very stable. (This is a > fairly important requirement - you don't want to suddenly be unable to > restore your backups after an upgrade). I can restore dumps made on > FreeBSD4.8/i386 and FreeBSD4.9/alpha on a FreeBSD-current/amd64 system > without problems. Hmm interesting.. I must confess I haven't had problems recently but I tend to use tar these days anyway since it's more portable. > It's possible that you might have problems with a backup made using a > very recent dump on a very old restore if you've used filesystem > features that didn't exist when that restore was built. Could be, too long ago to remember :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/ab239417/attachment.pgp From jacks at sage-american.com Thu Mar 26 04:53:41 2009 From: jacks at sage-american.com (Jack L. Stone) Date: Thu Mar 26 04:53:54 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: References: <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> Message-ID: <3.0.1.32.20090326065337.00f081e0@sage-american.com> At 09:45 AM 3.25.2009 -0500, Peggy Wilkins wrote: >>>>>> Jack L Stone writes: > > >> I've been watching this thread with some interest since we've had some > >> similar problems with dump/restore which we use every morning via cron > >> scripts on a number of servers to produce bootable clones as part of our > >> backup program. Have been doing this for years and also never saw a problem > >> as most of you say. We prefer dump/restore for backups. > > >> However, last month upon upon upgrading those servers from FBSD-6.3px > >> (RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers > >> had a similar problem as the original poster while the other half did not. > >> All of the servers (rackmounts) use the same (type) hardware. We spent many > >> hours trying to solve the problem with those that failed to dump/restore. > >> Also, searched for any others with the problem and only found a very few, > >> but without solutions to this issue. (Indeed, the only one was a reference > >> to any efforts to restore an older OS version which didn't apply here). > [snip] > >> SOLUTION > >> The "clones" are a very important pasrt of our backup program. Since the > >> dump side of the problems simply stuck and provided no error message at all > >> and the errors from any restores were not useful, our only solution was to > >> revert back to FBSD-6.3 on those servers with this issue and dump/restore > >> went back to working again. We left those that were working on FBSD-7.0-R > >> and they continue to work okay. > >I was seeing this same problem on all my 64-bit systems: FreeBSD-7 >dump would hang at a random point. Dump continues to work flawlessly >for me on FreeBSD-7/i386. > >I ran across this which includes a patch: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=121684 > >The kernel patch linked to there solved the problem for me, but I am >running many production systems and am unwilling to apply this patch >to -RELEASE every time there is a kernel update (I just use the >standard GENERIC kernel which I get via freebsd-update). I now live >without dump on amd64. Apparently this fix is waiting on some related >issue; and I will be very happy when it makes it to the officially >released kernel. > >plw > Thanks for the reply. Forgot to mention, our machines are all i386 with the problem -- so are the ones without the problem. Yes, I found that patch too and tried it on one of the servers -- no joy. Guess we'll continue to wait also for now. Maybe 7.2/i386....or, until someone finds the solution since we're out of ideas and stuck with 6.3 in order to use dump that we have trusted. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american From jacks at sage-american.com Thu Mar 26 05:08:38 2009 From: jacks at sage-american.com (Jack L. Stone) Date: Thu Mar 26 05:08:45 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <200903261157.n2QBv2Z1038026@lava.sentex.ca> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> Message-ID: <3.0.1.32.20090326070807.00f081e0@sage-american.com> At 07:57 AM 3.26.2009 -0400, Mike Tancsa wrote: >> >>Thanks for the reply. Forgot to mention, our machines are all i386 with the >>problem -- so are the ones without the problem. >> >>Yes, I found that patch too and tried it on one of the servers -- no joy. >> >>Guess we'll continue to wait also for now. Maybe 7.2/i386....or, until >>someone finds the solution since we're out of ideas and stuck with 6.3 in >>order to use dump that we have trusted. > > >Hi, > I didnt see it in the thread clearly, but did you try >creating a dump without the -L... i.e. without snapshots enabled ? > > ---Mike > Yes, but it's for running a dump on a (L)ive FS and just spits out warnings to that effect and has no effect on solving the problem(s). Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american From mike at sentex.net Thu Mar 26 05:11:54 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Mar 26 05:12:01 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <3.0.1.32.20090326065337.00f081e0@sage-american.com> References: <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> Message-ID: <200903261157.n2QBv2Z1038026@lava.sentex.ca> At 07:53 AM 3/26/2009, Jack L. Stone wrote: > > >> SOLUTION > > >> The "clones" are a very important pasrt of our backup program. >Since the > > >> dump side of the problems simply stuck and provided no error >message at all > > >> and the errors from any restores were not useful, our only solution >was to > > >> revert back to FBSD-6.3 on those servers with this issue and >dump/restore > > >> went back to working again. We left those that were working on >FBSD-7.0-R > > >> and they continue to work okay. > > > >Thanks for the reply. Forgot to mention, our machines are all i386 with the >problem -- so are the ones without the problem. > >Yes, I found that patch too and tried it on one of the servers -- no joy. > >Guess we'll continue to wait also for now. Maybe 7.2/i386....or, until >someone finds the solution since we're out of ideas and stuck with 6.3 in >order to use dump that we have trusted. Hi, I didnt see it in the thread clearly, but did you try creating a dump without the -L... i.e. without snapshots enabled ? ---Mike From cptsalek at gmail.com Thu Mar 26 05:32:31 2009 From: cptsalek at gmail.com (Christian Walther) Date: Thu Mar 26 05:32:38 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <3.0.1.32.20090326065337.00f081e0@sage-american.com> References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> Message-ID: <14989d6e0903260505n41122fb4j768ccecf7c5833a0@mail.gmail.com> Hi, I followed this thread out of interest since I do not suffer from this error. But I wonder if truss could shed some light into this issue. If for example a dump hangs at 99%, it might be an idea to set up truss to trace the dump process. Yes, this will produce lots of output, but maybe it gives a hint as soon as dump hangs. Christian Walther From mike at sentex.net Thu Mar 26 06:32:13 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Mar 26 06:32:19 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <3.0.1.32.20090326070807.00f081e0@sage-american.com> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> Message-ID: <200903261331.n2QDVd4b038485@lava.sentex.ca> At 08:08 AM 3/26/2009, Jack L. Stone wrote: >Yes, but it's for running a dump on a (L)ive FS and just spits out warnings >to that effect and has no effect on solving the problem(s). Unless the filesystem is very busy, you will get your data backed up. If you have things like databases, I still would not trust snapshots. Better to use pg_dump or mysqldump or the app that comes with whatever DB you are using... When backing up things like / and /usr, I would hazard a guess that most things are not changing while the backup is running, at least they dont in my environments. I have never had a problem with things like /home and even /var or /mail which are changing quite a bit. We dont restore much in the course of our daily routine, but we have always been able to restore people's Maildir when they accidentally have deleted stuff and it all worked without issue over the years. ---Mike From peter.schuller at infidyne.com Thu Mar 26 07:01:34 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Thu Mar 26 07:01:41 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <200903261331.n2QDVd4b038485@lava.sentex.ca> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> Message-ID: <20090326140131.GA45201@hyperion.scode.org> > >Yes, but it's for running a dump on a (L)ive FS and just spits out warnings > >to that effect and has no effect on solving the problem(s). > > Unless the filesystem is very busy, you will get your data backed up. > If you have things like databases, I still would not trust > snapshots. Uh. If backuping up a live database from a snapshot is not trustworthy, either the snapshot facility is broken or the database is broken (i.e., not crash-safe to begin with). That said there are plenty of other reasos to use proper dump tools (data portability, confirming the ability to actually read all rows from a table, using a more often exercised code path and perhaps less likely to have edge case bugs, etc). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/cff65936/attachment.pgp From mike at sentex.net Thu Mar 26 07:15:43 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Mar 26 07:15:56 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <20090326140131.GA45201@hyperion.scode.org> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <200903261415.n2QEF7hF038711@lava.sentex.ca> At 10:01 AM 3/26/2009, Peter Schuller wrote: > > > > Unless the filesystem is very busy, you will get your data backed up. > > If you have things like databases, I still would not trust > > snapshots. > >Uh. If backuping up a live database from a snapshot is not >trustworthy, either the snapshot facility is broken or the database is >broken (i.e., not crash-safe to begin with). ... or the database is configured in a risky way... But judging by this thread, it seems dump with -L is indeed broken for some people. Hence, I suggested dumping the database using the database's backup tools and trying dump without -L ---Mike From karl at denninger.net Thu Mar 26 07:35:07 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Mar 26 07:35:13 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <20090326140131.GA45201@hyperion.scode.org> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <49CB8E74.9090508@denninger.net> Peter Schuller wrote: >>> Yes, but it's for running a dump on a (L)ive FS and just spits out warnings >>> to that effect and has no effect on solving the problem(s). >>> >> Unless the filesystem is very busy, you will get your data backed up. >> If you have things like databases, I still would not trust >> snapshots. >> > > Uh. If backuping up a live database from a snapshot is not > trustworthy, either the snapshot facility is broken or the database is > broken (i.e., not crash-safe to begin with). > > That said there are plenty of other reasos to use proper dump tools > (data portability, confirming the ability to actually read all rows > from a table, using a more often exercised code path and perhaps less > likely to have edge case bugs, etc). > The issue with backing up a database live comes in when the filesystem where the database and transaction log files are DIFFERS. You can get into a pathological case in that instance. If the transaction log and database itself are both on the same snapshotted entity (that is, the snapshot is pulled at the same instant in time for both) what you get BETTER be restorable or your database's transaction log facility doesn't really do what it promises to do! -- -- Karl Denninger karl@denninger.net From peter.schuller at infidyne.com Thu Mar 26 07:49:23 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Thu Mar 26 07:49:36 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <200903261415.n2QEF7hF038711@lava.sentex.ca> References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <200903261415.n2QEF7hF038711@lava.sentex.ca> Message-ID: <20090326144916.GB46345@hyperion.scode.org> > ... or the database is configured in a risky way... But judging by > this thread, it seems dump with -L is indeed broken for some > people. Hence, I suggested dumping the database using the database's > backup tools and trying dump without -L Well, if dump -L is really broken I'd recommend just not using dump unless you absolutely have to. That is assuming snapshots are not broken so that you can still use mksnap_ffs with your favorite backup tool. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/f178586e/attachment.pgp From peter.schuller at infidyne.com Thu Mar 26 07:52:38 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Thu Mar 26 07:52:45 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <49CB8E74.9090508@denninger.net> References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <49CB8E74.9090508@denninger.net> Message-ID: <20090326145230.GC46345@hyperion.scode.org> > The issue with backing up a database live comes in when the filesystem > where the database and transaction log files are DIFFERS. You can get > into a pathological case in that instance. > > If the transaction log and database itself are both on the same > snapshotted entity (that is, the snapshot is pulled at the same instant > in time for both) what you get BETTER be restorable or your database's > transaction log facility doesn't really do what it promises to do! Absolutely. Doing things like snapshot based backups of databases assumes you know what you're doing since it is not something which is documented as an official procedure in your typical database administrator guide. Personally, while I would use such schemes, I would always use a plain fully supported regular dump as a fallback position. I would only rely on snapshot based processes to do fancy stuff (such as near-realtime hot standby with zfs snaps + serialized incrementals). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/30c95fbe/attachment.pgp From karl at denninger.net Thu Mar 26 07:57:20 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Mar 26 07:57:32 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <20090326145230.GC46345@hyperion.scode.org> References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <49CB8E74.9090508@denninger.net> <20090326145230.GC46345@hyperion.scode.org> Message-ID: <49CB97CD.2010303@denninger.net> Peter Schuller wrote: >> The issue with backing up a database live comes in when the filesystem >> where the database and transaction log files are DIFFERS. You can get >> into a pathological case in that instance. >> >> If the transaction log and database itself are both on the same >> snapshotted entity (that is, the snapshot is pulled at the same instant >> in time for both) what you get BETTER be restorable or your database's >> transaction log facility doesn't really do what it promises to do! >> > > Absolutely. Doing things like snapshot based backups of databases > assumes you know what you're doing since it is not something which is > documented as an official procedure in your typical database > administrator guide. > > Personally, while I would use such schemes, I would always use a plain > fully supported regular dump as a fallback position. I would only rely > on snapshot based processes to do fancy stuff (such as near-realtime > hot standby with zfs snaps + serialized incrementals). > To add to this what SHOULD (ha!) work is to dump the database partition FIRST and THEN dump the Transaction Log partition. If you do it in the other order you WILL get screwed, as you will have transactions committed in the database that are not in the XLOG. That is essentially guaranteed to blow up in your face. As always any backup scheme has to be TESTED so you can prove to your own satisfaction that it is RESTORABLE. I can't tell you how many business clients I have run into (and not only on Unix machines) that have wind up with lots of backups and NONE of them can be restored - because they never TESTED their backup strategy. -- -- Karl Denninger karl@denninger.net From peter.schuller at infidyne.com Thu Mar 26 08:11:04 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Thu Mar 26 08:11:17 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <49CB97CD.2010303@denninger.net> References: <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <49CB8E74.9090508@denninger.net> <20090326145230.GC46345@hyperion.scode.org> <49CB97CD.2010303@denninger.net> Message-ID: <20090326151100.GA46864@hyperion.scode.org> > To add to this what SHOULD (ha!) work is to dump the database partition > FIRST and THEN dump the Transaction Log partition. Depending on how the database works; specifically when old data in the log may or may not be expunged. You could do this with PostgreSQL by using it's PITR support for example. But to the extent that you have a log which is only supposed to be used for internal reasons (such as with pg by default), you'd likely be in trouble anyway unless you had a specific reason to know that it is safe. > As always any backup scheme has to be TESTED so you can prove to your > own satisfaction that it is RESTORABLE. I can't tell you how many > business clients I have run into (and not only on Unix machines) that > have wind up with lots of backups and NONE of them can be restored - > because they never TESTED their backup strategy. Very true, but it is equally dangerous to rely on testing *only*; a backup system can be very very broken yet appear to work during testing, either because backups only break sometimes or because they break in ways that do not obviously and immediately blow up in your face. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/f90e4b18/attachment.pgp From karl at denninger.net Thu Mar 26 08:16:05 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Mar 26 08:16:17 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <20090326151100.GA46864@hyperion.scode.org> References: <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <49CB8E74.9090508@denninger.net> <20090326145230.GC46345@hyperion.scode.org> <49CB97CD.2010303@denninger.net> <20090326151100.GA46864@hyperion.scode.org> Message-ID: <49CB9C2E.8060401@denninger.net> Peter Schuller wrote: >> To add to this what SHOULD (ha!) work is to dump the database partition >> FIRST and THEN dump the Transaction Log partition. >> > > Depending on how the database works; specifically when old data in the > log may or may not be expunged. You could do this with PostgreSQL by > using it's PITR support for example. But to the extent that you have a > log which is only supposed to be used for internal reasons (such as > with pg by default), you'd likely be in trouble anyway unless you had > a specific reason to know that it is safe. > True. If the log rolls on you while you're taking the dumps you're DEAD. Both design and verification are important :) -- -- Karl Denninger karl@denninger.net From jake at poptart.org Thu Mar 26 08:24:17 2009 From: jake at poptart.org (Jake Scott) Date: Thu Mar 26 08:24:31 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <20090326140131.GA45201@hyperion.scode.org> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: Hi.. On Thu, 26 Mar 2009, Peter Schuller wrote: >>> Yes, but it's for running a dump on a (L)ive FS and just spits out warnings >>> to that effect and has no effect on solving the problem(s). >> >> Unless the filesystem is very busy, you will get your data backed up. >> If you have things like databases, I still would not trust >> snapshots. > > Uh. If backuping up a live database from a snapshot is not > trustworthy, either the snapshot facility is broken or the database is > broken (i.e., not crash-safe to begin with). Exactly right - if you backup a database by relying on storage snapshots then the best you will end up with is a database that needs to be recovered when you restore those volumes (crash consistent). That's not a good place to be in when your production DB has just blown up. In addition, there are all sorts of complications which mean that you might need to freeze IO on multiple volumes simultaneously in order for this to have a chance of being successful (maintaining write-order-fidelity). I would strongly discourage anyone from using this method of backup for anything that is considered production, thought it might do you for making QA clones of a running database. > That said there are plenty of other reasos to use proper dump tools > (data portability, confirming the ability to actually read all rows > from a table, using a more often exercised code path and perhaps less > likely to have edge case bugs, etc). Absolutely. You really must use a tool that interacts with the database to perform the backup. Most commercial DBs have hooks that allow the backup routines to call out to custom snapshot facilities. One would usually request a backup through the database, which would then freeze IO to its data files and maybe log files, deal with flushing caches etc and then call your snapshot routine. I'm not aware that MySQL and Postgres do though so the best you can do is a dump. Jake From peter.schuller at infidyne.com Thu Mar 26 08:40:57 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Thu Mar 26 08:41:11 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <20090326154048.GA47539@hyperion.scode.org> > Exactly right - if you backup a database by relying on storage snapshots > then the best you will end up with is a database that needs to be > recovered when you restore those volumes (crash consistent). That's not a > good place to be in when your production DB has just blown up. If you have a production db that you care about, your database better not have trouble recoverying from a crash consistent state. But again I'm not suggesting that snapshot based backups be the primary method of backing up. In terms of time-to-recovery, having a crash consistent DB can be a lot quicker to recover than grabbing a dump, whose restoration will tend to be a lot slower than copying files. > Absolutely. You really must use a tool that interacts with the database > to perform the backup. Most commercial DBs have hooks that allow the > backup routines to call out to custom snapshot facilities. One would > usually request a backup through the database, which would then freeze IO > to its data files and maybe log files, deal with flushing caches etc and > then call your snapshot routine. I'm not aware that MySQL and Postgres do > though so the best you can do is a dump. I do not think "really must" is appropriate since clearly you can recover without DB specific integration. There may be reasons why it's better to have DB specific integration though (for example, limiting the amount of log reply that will be needed at recovery). The implication above that you cannot use snapshot based mechanisms with PostgreSQL and MySQL is not true; it's just that if you do you have to know what you're doing. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/659fd146/attachment.pgp From karl at denninger.net Thu Mar 26 08:46:23 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Mar 26 08:46:30 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <49CBA34B.9070708@denninger.net> Jake Scott wrote: > >> That said there are plenty of other reasos to use proper dump tools >> (data portability, confirming the ability to actually read all rows >> from a table, using a more often exercised code path and perhaps less >> likely to have edge case bugs, etc). > > Absolutely. You really must use a tool that interacts with the > database to perform the backup. Most commercial DBs have hooks that > allow the backup routines to call out to custom snapshot facilities. > One would usually request a backup through the database, which would > then freeze IO to its data files and maybe log files, deal with > flushing caches etc and then call your snapshot routine. I'm not > aware that MySQL and Postgres do though so the best you can do is a dump. > > Jake VERY careful thought has to go into backup strategy with production databases. Hooks that call out and snapshot are not necessarily good enough although they're "necessary" to get a dump that restores without the database going into log-replay mode. It is not difficult to do this with Postgresql; you can quiesce the database, snapshot and then release it, then dump the snapshots. This gives you transaction-complete dumps (as opposed to "crashed and rolled forward" dumps). The latter ("crashed and rolled forward"), if its sufficient, is trivially able to be done by having Postgresql (and most other databases) keep a sufficient number of log segments that a rollover cannot happen during the dump process itself, and either snapshotting both filesystems at once, keeping both on the same filesystem (undesirable for performance reasons) or dumping the database first and XLOG second. However, whether either of these approaches is sufficient is another matter. One of the real problems with live transaction processing systems is a means to know when there is a failure exactly what you lost. This is not a trivial problem to solve and requires plenty of thought before implementation, especially if you cannot afford the outage time necessary to take the snapshots - in some cases even that (relatively) short outage time is unacceptable. -- -- Karl Denninger karl@denninger.net From peter.schuller at infidyne.com Thu Mar 26 08:53:51 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Thu Mar 26 08:54:04 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <49CBA34B.9070708@denninger.net> References: <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <49CBA34B.9070708@denninger.net> Message-ID: <20090326155349.GA47932@hyperion.scode.org> > However, whether either of these approaches is sufficient is another > matter. One of the real problems with live transaction processing > systems is a means to know when there is a failure exactly what you > lost. This is not a trivial problem to solve and requires plenty of > thought before implementation, especially if you cannot afford the > outage time necessary to take the snapshots - in some cases even that > (relatively) short outage time is unacceptable. I would like to point out that if the backup strategy is correct, a COMMIT is guaranteed to be correctly honored, and the problem of determining what was lost has more to do with the birds-eye view of to what point in time the database was reverted as part of emergency recovery, than any difficulty in understanding what actually happens during snapshot recovery. I completely understand that you have various requirements in production that makes it a non-solution to just get a consistent snapshot at some arbitrary point in time without synchronizing with other software components somehow, but such issuse are into the realm of application design and integration with the backup procedure, and we are no longer talking about the viability of obtaining a consistent backup of a single database through snapshotting. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/f3076714/attachment.pgp From peter at simons-rock.edu Thu Mar 26 09:05:00 2009 From: peter at simons-rock.edu (Peter C. Lai) Date: Thu Mar 26 09:05:07 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <20090326153528.GH13398@cesium.hyperfine.info> On 2009-03-26 02:45:45PM +0000, Jake Scott wrote: > Absolutely. You really must use a tool that interacts with the database to > perform the backup. Most commercial DBs have hooks that allow the backup > routines to call out to custom snapshot facilities. One would usually > request a backup through the database, which would then freeze IO to its > data files and maybe log files, deal with flushing caches etc and then call > your snapshot routine. I'm not aware that MySQL and Postgres do though so > the best you can do is a dump. With MySQL at least, you can (ab)use the replication facilities so that you can set up a "slave" and do the fs-level dump while the slave is in a "frozen" state - the last time I played with MySQL, you could basically desync your slave for a period of time (basically until transaction logs are purged on the master), during which the slave will be consistent; do the fs-level backup then kick the master to sync with the slave again. -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From dwmalone at maths.tcd.ie Thu Mar 26 10:01:10 2009 From: dwmalone at maths.tcd.ie (David Malone) Date: Thu Mar 26 10:01:19 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C92060.4060303@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <49C92060.4060303@aldan.algebra.com> Message-ID: <20090326170106.GA28100@walton.maths.tcd.ie> On Tue, Mar 24, 2009 at 02:03:12PM -0400, Mikhail T. wrote: > Same problem: > > restore -rf ibmo.0.2009-03-24.dump > load: 0.55 cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k > unknown tape header type 213474529 > abort? [yn] > > Please, advise. Thanks! Yours, Hi Mikhail, If you actually need to get a dump back that restore can't read, you can try the "-D" option that I added a few years ago. Dump and restore expect things to be in a block format, but if (say) dump outputs a few bytes into the stream due to a bug, then the entire end of the dump can become unreadable. The -D option to restore tells it to try hard to get back in sync again. I'd guess you've tripped over either a bug in dump or restore. If you can file a PR, particularly with access to a sample dump, then I can have a look and see if I can figure out what's going on. Daid. From jacks at sage-american.com Thu Mar 26 10:07:35 2009 From: jacks at sage-american.com (Jack L. Stone) Date: Thu Mar 26 10:07:48 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <200903261331.n2QDVd4b038485@lava.sentex.ca> References: <3.0.1.32.20090326070807.00f081e0@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> Message-ID: <3.0.1.32.20090326120732.00ee69f0@sage-american.com> At 09:32 AM 3.26.2009 -0400, Mike Tancsa wrote: >At 08:08 AM 3/26/2009, Jack L. Stone wrote: > >>Yes, but it's for running a dump on a (L)ive FS and just spits out warnings >>to that effect and has no effect on solving the problem(s). > >Unless the filesystem is very busy, you will get your data backed up. >If you have things like databases, I still would not trust >snapshots. Better to use pg_dump or mysqldump or the app that comes >with whatever DB you are using... When backing up things like / and >/usr, I would hazard a guess that most things are not changing while >the backup is running, at least they dont in my environments. I have >never had a problem with things like /home and even /var or /mail >which are changing quite a bit. We dont restore much in the course >of our daily routine, but we have always been able to restore >people's Maildir when they accidentally have deleted stuff and it all >worked without issue over the years. > > ---Mike Yes, we have been using the "L" switch for as long as it has existed because we have and always before that, backed up live FSes. And, as said before, we do a dump/restore dump every morning to produce a bootable clone. The clones have always worked for the many years we have done this. Indeed, we have always used the MySQL's own dump separately to backup DBs. But, that's OT. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american From jacks at sage-american.com Thu Mar 26 10:09:27 2009 From: jacks at sage-american.com (Jack L. Stone) Date: Thu Mar 26 10:09:39 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <200903261415.n2QEF7hF038711@lava.sentex.ca> References: <20090326140131.GA45201@hyperion.scode.org> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <3.0.1.32.20090326120922.00ee69f0@sage-american.com> At 10:15 AM 3.26.2009 -0400, Mike Tancsa wrote: >At 10:01 AM 3/26/2009, Peter Schuller wrote: >> > >> > Unless the filesystem is very busy, you will get your data backed up. >> > If you have things like databases, I still would not trust >> > snapshots. >> >>Uh. If backuping up a live database from a snapshot is not >>trustworthy, either the snapshot facility is broken or the database is >>broken (i.e., not crash-safe to begin with). > >... or the database is configured in a risky way... But judging by >this thread, it seems dump with -L is indeed broken for some >people. Hence, I suggested dumping the database using the database's >backup tools and trying dump without -L > > ---Mike Mike: The "L" for dumping is definitely NOT the problem. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american From petefrench at ticketswitch.com Thu Mar 26 10:11:16 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Mar 26 10:11:23 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: Message-ID: > Absolutely. You really must use a tool that interacts with the database > to perform the backup. Most commercial DBs have hooks that allow the > backup routines to call out to custom snapshot facilities. One would > usually request a backup through the database, which would then freeze IO > to its data files and maybe log files, deal with flushing caches etc and > then call your snapshot routine. I'm not aware that MySQL and Postgres do > though so the best you can do is a dump. mysql can do this - you can flush the tables and acuire a lock simultaneously so that you can then snapshot the uderlying filesystem and then release the lock to let everything continue. I use this for taking database snapshots and it works fine. I stop my slaves before snapshotting to avoid log files changing underneath me too .... like this... #!/bin/sh /usr/local/bin/mysql -usnapuser -psnapuser < References: <200903261415.n2QEF7hF038711@lava.sentex.ca> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <200903261415.n2QEF7hF038711@lava.sentex.ca> Message-ID: <3.0.1.32.20090326121157.00ee69f0@sage-american.com> At 03:49 PM 3.26.2009 +0100, Peter Schuller wrote: >> ... or the database is configured in a risky way... But judging by >> this thread, it seems dump with -L is indeed broken for some >> people. Hence, I suggested dumping the database using the database's >> backup tools and trying dump without -L > >Well, if dump -L is really broken I'd recommend just not using dump >unless you absolutely have to. That is assuming snapshots are not >broken so that you can still use mksnap_ffs with your favorite backup >tool. > >-- >/ Peter Schuller > No one has said the dump "L" is broken -- and is NOT but now may mislead others just tuning into this thread. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american From jacks at sage-american.com Thu Mar 26 10:23:52 2009 From: jacks at sage-american.com (Jack L. Stone) Date: Thu Mar 26 10:24:04 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: <49CBA34B.9070708@denninger.net> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <3.0.1.32.20090326122344.00ee69f0@sage-american.com> At 10:46 AM 3.26.2009 -0500, Karl Denninger wrote: >Jake Scott wrote: >> >>> That said there are plenty of other reasos to use proper dump tools >>> (data portability, confirming the ability to actually read all rows >>> from a table, using a more often exercised code path and perhaps less >>> likely to have edge case bugs, etc). >> This thread has drifted off the main issue of using the FS dump/restore problem. Although, the DBs may be included as a part of this dump, it should NOT be relied upon as a backup/restore of DBs. We use MySQL's dump/backup tools strictly for the DBs. The dumps of the DBs (using MySQL's own dump tool) here are run by cron jobs every hour or few hours at most. That keeps our DB backups very recent and near current as possible is a restore is needed. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american From tevans.uk at googlemail.com Thu Mar 26 10:36:44 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Thu Mar 26 10:36:58 2009 Subject: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) In-Reply-To: References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> Message-ID: <1238087475.7491.44.camel@strangepork.mintel.co.uk> On Thu, 2009-03-26 at 14:45 +0000, Jake Scott wrote: .. > Absolutely. You really must use a tool that interacts with the database > to perform the backup. Most commercial DBs have hooks that allow the > backup routines to call out to custom snapshot facilities. One would > usually request a backup through the database, which would then freeze IO > to its data files and maybe log files, deal with flushing caches etc and > then call your snapshot routine. I'm not aware that MySQL and Postgres do > though so the best you can do is a dump. > > > Jake > Just to add, mysql has a utility (mysqlhotcopy) to allow you to directly copy MyISAM databases with a guarentee of consistency (thus avoiding the conversion from MyISAM data -> SQL, and no need to reimport when recovering). It isn't exactly online though, any writes will be blocked until the hotcopy finishes. Still, it is only MyISAM, and not much call for that these days.. Cheers Tom From mike at sentex.net Thu Mar 26 11:18:59 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Mar 26 11:19:12 2009 Subject: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566) In-Reply-To: <3.0.1.32.20090326121157.00ee69f0@sage-american.com> References: <200903261415.n2QEF7hF038711@lava.sentex.ca> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <200903261415.n2QEF7hF038711@lava.sentex.ca> <3.0.1.32.20090326121157.00ee69f0@sage-american.com> Message-ID: <200903261818.n2QIIPih039864@lava.sentex.ca> At 01:11 PM 3/26/2009, Jack L. Stone wrote: >No one has said the dump "L" is broken -- and is NOT but now may mislead >others just tuning into this thread. OK, sorry I misunderstood that restore worked from dump files without -L.... I wonder if the original poster just needs to do an fsck on the disk. The only time I had dump crap out on me (other than with -L) was on a dirty filesystem. I regularly do stuff like cd /usr;dump 0f - /usr | (cd /tmp/usr; restore -rf - ) to duplicate partitions ---Mike From karl at denninger.net Thu Mar 26 11:48:03 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Mar 26 11:48:12 2009 Subject: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566) In-Reply-To: <200903261818.n2QIIPih039864@lava.sentex.ca> References: <200903261415.n2QEF7hF038711@lava.sentex.ca> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <200903261415.n2QEF7hF038711@lava.sentex.ca> <3.0.1.32.20090326121157.00ee69f0@sage-american.com> <200903261818.n2QIIPih039864@lava.sentex.ca> Message-ID: <49CBCDE0.60401@denninger.net> Mike Tancsa wrote: > At 01:11 PM 3/26/2009, Jack L. Stone wrote: > >> No one has said the dump "L" is broken -- and is NOT but now may mislead >> others just tuning into this thread. > > > OK, sorry I misunderstood that restore worked from dump files without > -L.... > I wonder if the original poster just needs to do an fsck on the disk. > The only time I had dump crap out on me (other than with -L) was on a > dirty filesystem. > > I regularly do stuff like > cd /usr;dump 0f - /usr | (cd /tmp/usr; restore -rf - ) > to duplicate partitions > > ---Mike I do as well but if the original user is trying to restore into a filesystem that is either not clean or not EMPTY for a full restore he could run into some trouble. I've never had dump/restore fail by the way, other than due to bad (tape) media (yes, it was that long ago :) ) -- -- Karl Denninger karl@denninger.net From peter.schuller at infidyne.com Thu Mar 26 11:48:39 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Thu Mar 26 11:48:52 2009 Subject: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566) In-Reply-To: <3.0.1.32.20090326121157.00ee69f0@sage-american.com> References: <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <200903261415.n2QEF7hF038711@lava.sentex.ca> <3.0.1.32.20090326121157.00ee69f0@sage-american.com> Message-ID: <20090326184835.GA53678@hyperion.scode.org> > >> ... or the database is configured in a risky way... But judging by > >> this thread, it seems dump with -L is indeed broken for some > >> people. Hence, I suggested dumping the database using the database's > >> backup tools and trying dump without -L > > > >Well, if dump -L is really broken I'd recommend just not using dump > >unless you absolutely have to. That is assuming snapshots are not > >broken so that you can still use mksnap_ffs with your favorite backup > >tool. > > > >-- > >/ Peter Schuller > > > > No one has said the dump "L" is broken -- and is NOT but now may mislead > others just tuning into this thread. I was commenting on the specific statement that I quoted above. I am not claiming anything about dump being broken. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/b6b6ec3b/attachment.pgp From jh at saunalahti.fi Thu Mar 26 12:10:09 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Thu Mar 26 12:10:15 2009 Subject: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Message-ID: <200903261910.n2QJA8HF015949@freefall.freebsd.org> The following reply was made to PR kern/132068; it has been noted by GNATS. From: Jaakko Heinonen To: Edward Fisk <7ogcg7g02@sneakemail.com> Cc: bug-followup@FreeBSD.org Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: Thu, 26 Mar 2009 21:01:10 +0200 I was able to trigger a panic on current using this patch: %%% Index: sys/nfsserver/nfs_srvsubs.c =================================================================== --- sys/nfsserver/nfs_srvsubs.c (revision 190316) +++ sys/nfsserver/nfs_srvsubs.c (working copy) @@ -1169,6 +1169,8 @@ nfsrv_fhtovp(fhandle_t *fhp, int lockfla vfs_unbusy(mp); if (error) goto out; + if ((*vpp)->v_type == VBAD) + panic("VBAD *vpp in nfsrv_fhtovp()"); #ifdef MNT_EXNORESPORT if (!(exflags & (MNT_EXNORESPORT|MNT_EXPUBLIC))) { saddr = (struct sockaddr_in *)nam; %%% #2 0xc08537d2 in panic (fmt=Variable "fmt" is not available.) at /home/jaakko/src/head/sys/kern/kern_shutdown.c:576 #3 0xc0a1c17e in nfsrv_fhtovp (fhp=0xf48ecae4, lockflag=1, vpp=0xf48ecad8, vfslockedp=0xf48ecac4, nfsd=0xf48ecbb0, slp=0x0, nam=0xc63aeac4, rdonlyp=0xf48ecad0, pubflag=1) at /home/jaakko/src/head/sys/nfsserver/nfs_srvsubs.c:1173 #4 0xc0a0ff20 in nfsrv_commit (nfsd=0xf48ecbb0, slp=0x0, mrq=0xf48ecba8) at /home/jaakko/src/head/sys/nfsserver/nfs_serv.c:3836 #5 0xc0a1b1a7 in nfssvc_program (rqst=0xca95d000, xprt=0xc63aea00) at /home/jaakko/src/head/sys/nfsserver/nfs_srvkrpc.c:420 #6 0xc0a35fe2 in svc_run_internal (pool=0xc57a7a80, ismaster=0) at /home/jaakko/src/head/sys/rpc/svc.c:883 #7 0xc0a362c0 in svc_thread_start (arg=0xc57a7a80) at /home/jaakko/src/head/sys/rpc/svc.c:1188 #8 0xc082fd38 in fork_exit (callout=0xc0a362b0 , arg=0xc57a7a80, frame=0xf48ecd38) at /home/jaakko/src/head/sys/kern/kern_fork.c:821 #9 0xc0b41630 in fork_trampoline () at /home/jaakko/src/head/sys/i386/i386/exception.s:270 I now know what is going on. The vnode may be reclaimed during zfs_zget() because it doesn't hold the vnode lock (except when a new znode is created). I tried to modify zfs_zget() to grab the vnode lock and check if the vnode is doomed. I was able to trigger the condition. However eventually vnode locking deadlocked with lookup(). I used exclusive locking so maybe one could avoid deadlocking with shared locking but it isn't a real solution especially because shared lookups can be disabled. Also other deadlock scenarios may exist. On 2009-03-05, Edward Fisk wrote: > The machine did a panic earlier, but was unfortunately unable to do a dump. > > panic: Bad link elm 0xffffff014f3e2400 prev->next != elm > xprt_unregister_locked() at xprt_unregister_locked+0xad This is a different issue. You may have already seen this discussion: http://lists.freebsd.org/pipermail/freebsd-current/2009-March/005097.html -- Jaakko From eugene at donpac.ru Thu Mar 26 15:11:50 2009 From: eugene at donpac.ru (Eugene Gladchenko) Date: Thu Mar 26 15:12:03 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C83673.3000604@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> Message-ID: <725997207.20090327003648@donpac.ru> Mikhail, MT> I'm trying to migrate a filesystem from one disk to another using: MT> dump a0hCf 0 32 - /old | restore -rf - MT> (/old is already mounted read-only). The process runs for a while and MT> then stops with: MT> [...] MT> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 MT> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 MT> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 MT> unknown tape header type 1853384566 MT> abort? [yn] MT> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's MT> dump's output? Is your /tmp large enough to restore? -- Eugene Gladchenko EVG15-RIPE From listreader at lazlarlyricon.com Thu Mar 26 15:48:36 2009 From: listreader at lazlarlyricon.com (Rolf G Nielsen) Date: Thu Mar 26 15:48:48 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49C83673.3000604@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> Message-ID: <49CC0168.70502@lazlarlyricon.com> Mikhail T. wrote: > Hello! > > I'm trying to migrate a filesystem from one disk to another using: > > dump a0hCf 0 32 - /old | restore -rf - Try dump -a0 -h 0 -C 32 -f - /old instead. Your command line should work, but I've had trouble with similar ones and have been able to solve it by separating the options. > > (/old is already mounted read-only). The process runs for a while and > then stops with: > > [...] > DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 > DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 > DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 > unknown tape header type 1853384566 > abort? [yn] > > Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's > dump's output? > > The system runs 7.0-STABLE from July 6th, i386. I just tried updating > the dump and restore from source (latest 7.x) -- the error is the same... > > Please, advise. Thanks! > > -mi > > _______________________________________________ > 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" > > > -- Sincerly, Rolf Nielsen From freebsd-nospam at yaxom.com Thu Mar 26 18:11:54 2009 From: freebsd-nospam at yaxom.com (Greg Black) Date: Thu Mar 26 18:12:07 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: <49CA5602.9050001@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> <49CA5602.9050001@aldan.algebra.com> Message-ID: On 2009-03-25, Mikhail T. wrote: > Greg Black ???????(??): >> On 2009-03-24, Mikhail T. wrote: >> >>> That's true. I just wanted to point out, that someone running dump only >>> (to make backups) is not going to know, whether his dumps are usable >>> (for whichever of the two reasons), until he needs them... >> >> Such a person is not making backups and deserves what he gets. >> > But he *is* making backups -- kindly re-read my paragraph above... He > just is not routinely using them and thus does not know, that they > aren't usable... It is not unreasonable to expect the two utilities to > "just work", so I wouldn't be blaming such a person for not testing > restore. Sorry, this person is *not* making backups in any meaningful fashion. Unless you verify regularly (preferably every time you make a backup) that you can restore both parts of the backup and the entire thing, you are not making backups. You may be lucky, but you probably won't be lucky when it really matters. This is a long-standing issue with backups. But people who don't understand the tools they are using tend to make these mistakes. The result is bad. The solution is to employ competent people who both understand the issues and have the authority to carry out their task. From dougb at FreeBSD.org Thu Mar 26 18:42:27 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Mar 26 18:42:33 2009 Subject: dump | restore fails: unknown tape header type 1853384566 In-Reply-To: References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> <49CA5602.9050001@aldan.algebra.com> Message-ID: <49CC28BD.1070501@FreeBSD.org> Greg Black wrote: > Sorry, this person is *not* making backups in any meaningful fashion. > Unless you verify regularly (preferably every time you make a backup) > that you can restore both parts of the backup and the entire thing, you > are not making backups. You may be lucky, but you probably won't be > lucky when it really matters. s/making backups/employing an effective data recovery strategy/ Please don't feed the "proper use of language" trolls. :) Meanwhile, we may want to consider that this whole thread is veering off topic ... Doug -- This .signature sanitized for your protection From mi+thun at aldan.algebra.com Thu Mar 26 18:52:48 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Thu Mar 26 18:53:01 2009 Subject: backup strategy (Re: dump | restore fails) In-Reply-To: References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> <49CA5602.9050001@aldan.algebra.com> Message-ID: <49CC3162.5090201@aldan.algebra.com> Greg Black ???????(??): > Sorry, this person is *not* making backups in any meaningful fashion. > Unless you verify regularly (preferably every time you make a backup) > that you can restore both parts of the backup and the entire thing, you > are not making backups. To qualify for your (and your kind's) recognition then, a person needs to have at least as much extra storage capacity as the largest filesystem they are backing up. They also need non-trivial scripting abilities, because the OS doesn't include anything like what you are describing (and I already do consider scheduling dumps via cron "trivial", which may be a stretch). Yours may thus be an acceptable requirement for a multi-computer shop with dedicated system administration personnel, but for a private home user with only one computer this simply is not reasonable. Stating this as a requirement is ridiculous -- unless you are prepared to say, that such people should not own a computer (with worthy data) at all. And that's even more ridiculous... Make your pick. I would agree with you, if the chosen backup method involved some complex or third-party tools. But if the simple, OS-supplied orthogonal dump/restore don't work together, then the OS is broken -- plain and simple, and pointing a finger at the user: "Well, it is all your fault, because you relied on us providing you with working utilities, ha-ha-ha!" -- is the lamest excuse imaginable. -mi P.S. Some people have actually volunteered to help debug this problem and I'm working on providing them with data (the troublesome partition is, sadly, over 170Gb, so it takes a while). Any results/conclusions will be posted under the original subject. P.P.S. The data transferred fine using tar, but that is not the point -- the bug (confirmed by at least one more person) -- needs to be fixed before a higher-profile embarrassment... From andrew at modulus.org Thu Mar 26 19:25:27 2009 From: andrew at modulus.org (Andrew Snow) Date: Thu Mar 26 19:25:33 2009 Subject: backup strategy (Re: dump | restore fails) In-Reply-To: <49CC3162.5090201@aldan.algebra.com> References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> <49CA5602.9050001@aldan.algebra.com> <49CC3162.5090201@aldan.algebra.com> Message-ID: <49CC3889.9000201@modulus.org> Mikhail T. wrote: > To qualify for your (and your kind's) recognition then, a person > needs to have at least as much extra storage capacity as the > largest filesystem they are backing up. They also need > non-trivial scripting abilities, because the OS doesn't > include anything like what you are describing Mikhail, users would be well advised to check their backups using this option, without having to have the space to restore: -N Do the extraction normally, but do not actually write any changes to disk. This can be used to check the integrity of dump media or other test purposes. RESTORE(8) FreeBSD System Manager's Manual From mi+thun at aldan.algebra.com Thu Mar 26 20:02:49 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Thu Mar 26 20:02:56 2009 Subject: backup strategy (Re: dump | restore fails) In-Reply-To: <49CC3889.9000201@modulus.org> References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> <49CA5602.9050001@aldan.algebra.com> <49CC3162.5090201@aldan.algebra.com> <49CC3889.9000201@modulus.org> Message-ID: <49CC39DE.3060604@aldan.algebra.com> Andrew Snow ???????(??): > Mikhail T. wrote: > > To qualify for your (and your kind's) recognition then, a person > > needs to have at least as much extra storage capacity as the > > largest filesystem they are backing up. They also need > > non-trivial scripting abilities, because the OS doesn't > > include anything like what you are describing > > Mikhail, users would be well advised to check their backups using this > option, without having to have the space to restore: > > -N Do the extraction normally, but do not actually write any > changes to disk. This can be used to check the integrity of dump media > or other test purposes. And then another "purist" will reject this as a fake and not sufficiently conclusive test... Just ask around... Because, you see, until you extract all data back and run a bit-by-bit comparison with the original, you don't really know, do you? -mi From linimon at FreeBSD.org Fri Mar 27 13:12:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Mar 27 13:12:47 2009 Subject: kern/133134: [zfs] Missing ZFS zpool labels Message-ID: <200903272012.n2RKCXTW090513@freefall.freebsd.org> Old Synopsis: Missing ZFS zpool labels New Synopsis: [zfs] Missing ZFS zpool labels Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 27 20:12:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133134 From juri_mian at yahoo.com Sat Mar 28 10:53:41 2009 From: juri_mian at yahoo.com (Juri Mianovich) Date: Sat Mar 28 11:25:06 2009 Subject: quick advice needed RE: Intel Integrated Server RAID and FreeBSD Message-ID: <286854.110.qm@web45606.mail.sp1.yahoo.com> Hello, I am considering this motherboard: http://www.intel.com/products/server/motherboards/S5000PSL/S5000PSL-overview.htm The Intel S5000 PSL Server board, with "Intel Integrated Server RAID". I plan on using the onboard raid for a simple boot mirror. I have two quick questions: 1. What chipset/controller is this "Intel Integrated Server RAID" and is it well supported in FreeBSD ? Will sysinstall recognize it ? Is there a CLI tool ofr viewing status once FreeBSD is running ? 2. Is this _real_ hardware raid ? As in, FreeBSD will know _nothing_ about the raid and will simply see one disk (which is a mirror) ? I am seeing discussion that I don't understand about how this is somehow software raid, but If it's all built on the board ... ? Performance isn't a real issue since it is just a boot mirror. I just want to hide the raid layer from the OS and do my raid work (rebuilds, etc.) through the BIOS. Thanks. From brucec at FreeBSD.org Sat Mar 28 16:26:16 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Sat Mar 28 16:26:27 2009 Subject: kern/72424: panic: ffs_blkfree: freeing free block in ffs/ffs_alloc.c:1750 Message-ID: <200903282326.n2SNQF2g083927@freefall.freebsd.org> Synopsis: panic: ffs_blkfree: freeing free block in ffs/ffs_alloc.c:1750 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Sat Mar 28 23:25:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=72424 From brucec at FreeBSD.org Sat Mar 28 16:28:22 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Sat Mar 28 16:28:29 2009 Subject: kern/62824: [panic] softdep_setup_inomapdep: found inode [5.2-CURRENT] Message-ID: <200903282328.n2SNSMDQ083995@freefall.freebsd.org> Synopsis: [panic] softdep_setup_inomapdep: found inode [5.2-CURRENT] Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Sat Mar 28 23:28:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=62824 From brucec at FreeBSD.org Sat Mar 28 16:30:53 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Sat Mar 28 16:31:00 2009 Subject: kern/92272: [ffs] [hang] Filling a filesystem while creating a snapshot on it locks the system Message-ID: <200903282330.n2SNUr00088757@freefall.freebsd.org> Synopsis: [ffs] [hang] Filling a filesystem while creating a snapshot on it locks the system Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Sat Mar 28 23:30:32 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=92272 From brucec at FreeBSD.org Sat Mar 28 16:32:35 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Sat Mar 28 16:32:46 2009 Subject: kern/94769: [ufs] Multiple file deletions on multi-snapshotted filesystems causes hang Message-ID: <200903282332.n2SNWYOc098212@freefall.freebsd.org> Synopsis: [ufs] Multiple file deletions on multi-snapshotted filesystems causes hang Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Sat Mar 28 23:32:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94769 From kib at FreeBSD.org Sun Mar 29 02:14:30 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Sun Mar 29 02:14:37 2009 Subject: kern/72424: panic: ffs_blkfree: freeing free block in ffs/ffs_alloc.c:1750 Message-ID: <200903290914.n2T9ETCc019364@freefall.freebsd.org> Synopsis: panic: ffs_blkfree: freeing free block in ffs/ffs_alloc.c:1750 State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Sun Mar 29 09:13:11 UTC 2009 State-Changed-Why: Several bugs that could cause this issue were fixed since 6.0-CURRENT. Peter' stress2 suite does not reproduce "freeing free blocks" now, at least not that I know about this. http://www.freebsd.org/cgi/query-pr.cgi?pr=72424 From kib at FreeBSD.org Sun Mar 29 02:20:14 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Sun Mar 29 02:20:20 2009 Subject: kern/62824: [panic] softdep_setup_inomapdep: found inode [5.2-CURRENT] Message-ID: <200903290920.n2T9KD3a020712@freefall.freebsd.org> Synopsis: [panic] softdep_setup_inomapdep: found inode [5.2-CURRENT] State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Sun Mar 29 09:19:17 UTC 2009 State-Changed-Why: I believe one known reason for this panic was fixed. Other then that, the problem was not reported at all recently (as in 2-3 years at least). http://www.freebsd.org/cgi/query-pr.cgi?pr=62824 From james-freebsd-fs2 at jrv.org Sun Mar 29 16:52:10 2009 From: james-freebsd-fs2 at jrv.org (James R. Van Artsdalen) Date: Sun Mar 29 16:52:16 2009 Subject: ZFS & USB disks? Message-ID: <49D0099B.2040807@jrv.org> uname -a: FreeBSD bigtex.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r189099: Fri Feb 27 07:09:47 CST 2009 james@bigtex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 This build is from before the recent USB changes. Is it safe to use ZFS with USB disk drives? The kernel output suggests "SYNCHRONIZE_CACHE" isn't supported. Does this cause a write-ordering problem for ZFS? Upon attaching a drive with a pool created on a Mac: kernel: vdev_geom_attach:112[1]: Attaching to da4. kernel: vdev_geom_attach:153[1]: Created consumer for da4. kernel: (da4:umass-sim0:0:0:1): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 kernel: (da4:umass-sim0:0:0:1): CAM Status: SCSI Status Error kernel: (da4:umass-sim0:0:0:1): SCSI Status: Check Condition kernel: (da4:umass-sim0:0:0:1): ILLEGAL REQUEST asc:20,0 kernel: (da4:umass-sim0:0:0:1): Invalid command operation code kernel: (da4:umass-sim0:0:0:1): (da4:umass-sim0:0:0:1): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 kernel: (da4:umass-sim0:0:0:1): ILLEGAL REQUEST asc:20,0 kernel: (da4:umass-sim0:0:0:1): Invalid command operation code kernel: Unretryable error kernel: (da4:umass-sim0:0:0:1): error 22 kernel: (da4:umass-sim0:0:0:1): Unretryable Error From linimon at FreeBSD.org Sun Mar 29 17:12:05 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Mar 29 17:12:27 2009 Subject: kern/133174: [patch] msdosfs must support utf-encoded international characters in filr names Message-ID: <200903300012.n2U0C4Cu037972@freefall.freebsd.org> Old Synopsis: msdosfs must support utf-encoded international characters in filr names New Synopsis: [patch] msdosfs must support utf-encoded international characters in filr names Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 30 00:11:27 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). Apparently there is a patch at the supplied URL. http://www.freebsd.org/cgi/query-pr.cgi?pr=133174 From linimon at FreeBSD.org Sun Mar 29 17:51:47 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Mar 29 17:51:53 2009 Subject: kern/133150: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data Message-ID: <200903300051.n2U0pk0t092212@freefall.freebsd.org> Old Synopsis: Page fault with ZFS on 7.1-RELEASE/amd64 while writing data New Synopsis: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 30 00:51:20 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133150 From bugmaster at FreeBSD.org Mon Mar 30 04:06:53 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 30 04:07:47 2009 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org Message-ID: <200903301106.n2UB6p8k054721@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/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] 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/129174 fs [nfs] [zfs] [panic] NFS v3 Panic when under high load 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/94480 fs [libufs] [patch] bread(3) & bwrite(3) can crash under 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/51685 fs [hang] Unbounded inode allocation causes kernel to loc 57 problems total. From mike at reifenberger.com Mon Mar 30 07:04:23 2009 From: mike at reifenberger.com (Michael Reifenberger) Date: Mon Mar 30 07:04:29 2009 Subject: PR kern/133020 Message-ID: Hi, your patch from the PR helped me. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From ivoras at freebsd.org Tue Mar 31 06:00:07 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Mar 31 06:00:13 2009 Subject: kern/133150: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data Message-ID: <200903311300.n2VD05gj094642@freefall.freebsd.org> The following reply was made to PR kern/133150; it has been noted by GNATS. From: Ivan Voras To: bug-followup@freebsd.org, jeffb.misc@gmail.com Cc: Subject: Re: kern/133150: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data Date: Tue, 31 Mar 2009 14:36:57 +0200 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD3FE5A75095A05DBB713766A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you try to repeat the error on 8-CURRENT? --------------enigD3FE5A75095A05DBB713766A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ0g5qldnAQVacBcgRAmiAAJsE1J8Vl1LKC1UztG+9/makz+jgjQCdE4eQ ZjnZc+qdI23Q7vdqKdfSedI= =DM3u -----END PGP SIGNATURE----- --------------enigD3FE5A75095A05DBB713766A-- From brampton+freebsd-fs at gmail.com Tue Mar 31 13:16:27 2009 From: brampton+freebsd-fs at gmail.com (Andrew Brampton) Date: Tue Mar 31 13:16:33 2009 Subject: Auto mount and ignore errors Message-ID: Hi, Recently my server hung on a reboot because it was unable to fsck a ext2 file system. This was because I didn't have the ext2 fsck tool installed (I do now). The partition in question was however not important, yet I listed it as "auto" in fstab. I would have preferred if my server noticed the problem, failed to mount it and just continue booting as normal. I tried the "late" option in the fstab but that just seem to hang the server later in the boot. So my question is, is there a fstab option which will ignore a failed mount, and if possible continue to boot? I've read the man page, and did a bit of googling, but didn't find anything. Would there be any objection to a patch which implemented a "ignerror" flag? thanks Andrew From linimon at FreeBSD.org Tue Mar 31 15:32:23 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Mar 31 15:32:34 2009 Subject: kern/133251: [xfs] xfs write Input/output error crash kernel: xfs_iunpin: REC RECABLE ip Message-ID: <200903312232.n2VMWMOC074733@freefall.freebsd.org> Synopsis: [xfs] xfs write Input/output error crash kernel: xfs_iunpin: REC RECABLE ip Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 31 22:32:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133251 From kan at FreeBSD.org Tue Mar 31 16:15:51 2009 From: kan at FreeBSD.org (kan@FreeBSD.org) Date: Tue Mar 31 16:15:58 2009 Subject: kern/133251: [xfs] xfs write Input/output error crash kernel: xfs_iunpin: REC RECABLE ip Message-ID: <200903312315.n2VNFoq0028218@freefall.freebsd.org> Synopsis: [xfs] xfs write Input/output error crash kernel: xfs_iunpin: REC RECABLE ip State-Changed-From-To: open->closed State-Changed-By: kan State-Changed-When: Tue Mar 31 23:14:29 UTC 2009 State-Changed-Why: XFS write support was never released or supported and you should not be trying to use it. http://www.freebsd.org/cgi/query-pr.cgi?pr=133251 From antik at bsd.ee Tue Mar 31 22:24:53 2009 From: antik at bsd.ee (Andrei Kolu) Date: Tue Mar 31 22:24:59 2009 Subject: Auto mount and ignore errors In-Reply-To: References: Message-ID: <49D2F2DE.1090807@bsd.ee> Andrew Brampton wrote: > So my question is, is there a fstab option which will ignore a failed > mount, and if possible continue to boot? I've read the man page, and > did a bit of googling, but didn't find anything. Would there be any > objection to a patch which implemented a "ignerror" flag? > > Mount from /etc/rc.local?