Re: ZFS Panic after freebsd-update
on 01/07/2013 21:50 Jeremy Chadwick said the following: The issue is that ZFS on FreeBSD is still young compared to other filesystems (specifically UFS). That's a fact. Nothing is perfect, but FFS/UFS tends to have a significantly larger number of bugs worked out of it to the point where people can use it without losing sleep (barring the SUJ stuff, don't get me started). That's subjective. I have the same concerns over other things, like ext2fs and fusefs for that matter -- but this thread is about a ZFS-related crash, and that's why I'm over-focused on it. I have an impression that you seem to state your (negative) opinion of ZFS in every other thread about ZFS problems. A heterogeneous (UFS+ZFS) setup, rather than homogeneous (ZFS-only), results in a system where an admin can upgrade + boot into single-user and perform some tasks to test/troubleshoot; if the ZFS layer is broken, it doesn't mean an essentially useless box. That isn't FUD, that's just the stage we're at right now. I'm aware lots of people have working ZFS-exclusive setups; like I said, works great until it doesn't. Yeah, a heterogeneous setup can have its benefits, but it can have its drawbacks too. This is true for heterogeneous vs monoculture in general. But the sword cuts both ways: what if something is broken in UFS layer or god forbid in VFS layer and you have only UFS? Besides, without mentioning specific classes of problems ZFS layer is broken is too vague. So, how do you kernel guys debug a problem in this environment: - ZFS-only - Running -RELEASE (i.e. no source, thus a kernel cannot be rebuilt with added debugging features, etc.) - No swap configured - No serial console I use boot environments and boot to a previous / known-good environment if I hit a loader bug, a kernel bug or a major userland problem in a new environment. I also use a mirrored setup and keep two copies of earlier boot chains. I am also not shy of live media in the case everything else fails. Now I wonder how you deal with the same kind of UFS-only environment. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS Panic after freebsd-update
On Tue, Jul 02, 2013 at 08:59:56AM +0300, Andriy Gapon wrote: on 01/07/2013 21:50 Jeremy Chadwick said the following: The issue is that ZFS on FreeBSD is still young compared to other filesystems (specifically UFS). That's a fact. Nothing is perfect, but FFS/UFS tends to have a significantly larger number of bugs worked out of it to the point where people can use it without losing sleep (barring the SUJ stuff, don't get me started). That's subjective. I have the same concerns over other things, like ext2fs and fusefs for that matter -- but this thread is about a ZFS-related crash, and that's why I'm over-focused on it. I have an impression that you seem to state your (negative) opinion of ZFS in every other thread about ZFS problems. The OP in question ended his post with the line Thoughts?, and I have given those thoughts. My thoughts/opinions/experience may differ from that of others. Diversity of thoughts/opinions/experiences is good. I'm not some kind of authoritative ZFS guru -- far from it. If I misunderstood what Thoughts? meant/implied, then draw and quarter me for it; my actions/words = my responsibility. I do not feel I have a negative opinion of ZFS. I still use it today on FreeBSD, donated money to Pawel when the project was originally announced (because I wanted to see something new and useful thrive on FreeBSD), and try my best to assist with issues pertaining to it where applicable. These are not the actions of someone with a negative opinion, these are the actions of someone who is supportive while simultaneously very cautious. Is ZFS better today than it was when it was introduced? By a long shot. For example, on my stable/9 system here I don't tune /boot/loader.conf any longer. But that doesn't change my viewpoint when it comes to using ZFS exclusively on a FreeBSD box. A heterogeneous (UFS+ZFS) setup, rather than homogeneous (ZFS-only), results in a system where an admin can upgrade + boot into single-user and perform some tasks to test/troubleshoot; if the ZFS layer is broken, it doesn't mean an essentially useless box. That isn't FUD, that's just the stage we're at right now. I'm aware lots of people have working ZFS-exclusive setups; like I said, works great until it doesn't. Yeah, a heterogeneous setup can have its benefits, but it can have its drawbacks too. This is true for heterogeneous vs monoculture in general. But the sword cuts both ways: what if something is broken in UFS layer or god forbid in VFS layer and you have only UFS? Besides, without mentioning specific classes of problems ZFS layer is broken is too vague. The likelihood of something being broken in UFS is significantly lower given its established history. I have to go off of experience, both personal and professional -- in my years of dealing with FreeBSD (1997-present), I have only encountered issues with UFS a few times (I can count them on one, maybe two hands), and I'm choosing to exclude SU+J from the picture for what should be obvious reasons. With ZFS, well... just look at the mailing lists and PR count. I don't want to be a jerk about it, but you really have to look at the quantity. It doesn't mean ZFS is crap, it just means that for me, I don't think we're quite there yet. And I will gladly admit -- because you are the one who taught me this -- that every incident need be treated unique. But one can't deny that a substantial percentage (I would say majority) of -fs and -stable posts relate somehow to ZFS; I'm often thrilled when it turns out to be something else. Playing a strange devil's advocate, let me give you an interesting example: softupdates. When SU was introduced to FreeBSD back in the late 90s, there were issues and concerns -- lots. As such, SU was chosen to be disabled by default on root filesystems given the importance of that filesystem (re: we do not want to risk losing as much data in the case of a crash -- see the official FAQ, section 8.3). All other filesystems defaulted to SU enabled. It's been like that up until 9.x where it now defaults to enabled. So that's what, 15 years? You could say that my example could also apply to ZFS, i.e. the reports are a part of its growth and maturity, and I'd agree. But I don't feel it's reached the point where I'm willing to risk going ZFS-only. Down the road, sure, but not now. That's just my take on it. Please make sure to also consider, politely, that a lot of people who have issues with ZFS have not been subscribed to the lists for long periods of time. They sign up/post when they have a problem. Meaning: they do not necessarily know of the history. If they did, I (again politely) believe they're likely to use a UFS+ZFS mix, or maybe a gmirror+UFS+ZFS mix (though the GPT/gmirror thing is... never mind...). So, how do you kernel guys debug a problem in this environment: - ZFS-only - Running -RELEASE (i.e. no source, thus a kernel cannot be
RE: Problems booting into ZFS on recent stable/9
Hi Cris, Do you still have the following file: /boot/zfs/zpool.cache ? I guess that with the kernel upgrade you have just replaced that :) This is the file that you can create with: zpool set cachefile=/boot/zfs/zpool.cache pool name Regards, Ivailo Tanusheff -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Chris Ross Sent: Monday, July 01, 2013 9:50 PM To: freebsd-stable@freebsd.org Cc: freebsd-spar...@freebsd.org Subject: Problems booting into ZFS on recent stable/9 I had a sparc64 (Netra X1) running a stable/9 from late March 2013. Actually, the kernel may've been a bit newer than that as I was working with folks to diagnose and repair some Netra-X1 specific issues. But, ZFS worked fine. I have two pools, zroot as a RAID1 (using equally sized partitions at the front of two large disks), and a zdata that is a large pool of the remaining space of both disks concatenated together. After installing a kernel from a build of [yesterday's] stable/9 today, I now get a failure when trying to boot, which can be seen at the end of this clip from the end of the boot messages below. Is anyone aware of a change in recent months that might've caused this, or have any idea what I may've done wrong? In google'ing I've seen a few posts talking about ways to import the zfs pool to adjust the cache file, but I'm not sure if that is or isn't my problem. I don't think I did anything specific with configuring cache files for either pool. Thoughts are welcome. I don't have physical access to the machine for quite a few more hours, but when I do should be able to net-boot into the earlier freebsd stable/9 that I originally installed onto this host, and can try a few more things. - Chris atapci0: AcerLabs M5229 UDMA66 controller port 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f at device 13.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: ATA channel at channel 0 on atapci0 ata3: ATA channel at channel 1 on atapci0 rtc0: Real-Time Clock at port 0x70-0x71 on isa0 uart0: 16550 or compatible at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2e8-0x2ef irq 43 on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add vfs.zfs.prefetch_disable=0 to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter tick frequency 5 Hz quality 1000 Event timer tick frequency 5 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 Root mount waiting for: usbus0 ugen0.1: AcerLabs at usbus0 uhub0: AcerLabs OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from zfs:zroot []... Mounting from zfs:zroot failed with error 2. Loader variables: vfs.root.mountfrom=zfs:zroot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS Panic after freebsd-update
On Tue, Jul 02, 2013 at 12:57:16AM -0700, Jeremy Chadwick wrote: But in the OP's case, the situation sounds dire given the limitations -- limitations that someone (apparently not him) chose, which greatly hinder debugging/troubleshooting. Had a heterogeneous setup been chosen, the debugging/troubleshooting pains are less (IMO). When I see this, it makes me step back and ponder the decisions that lead to the ZFS-only setup. As an observer (though one who has used ZFS for some time, now), I might suggest that this can at least -seem- like FUD about ZFS because the limitations don't necessarily have anything to do with ZFS. That is, a situation in which one cannot recover, nor even effectively troubleshoot, if there is a problem, will be a dire one, regardless of what the problem might be or where its source might lie. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL - Portland, OR USA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
