UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Matthew Dillon
dillon at apollo.backplane.com
Tue Sep 30 03:00:42 UTC 2008
:Completely agree. ZFS is the way of the future for FreeBSD. In my
:latest testing, the memory problems are now under control, there is just
:stability problems with random lockups after days of heavy load unless I
:turn off ZIL. So its nearly there.
:
:If only ZFS also supported a network distributed mode. Or can we
:convince you to port Hammer to FreeBSD? :-)
:
:- Andrew
Heh. No, you guys would have to port it if you want it, though I would
be happy to support it once ported. Issues are between minor and
moderate but would still require a knowledgeable filesystem person
to do. Biggest issues will be buffer cache and bioops differences,
and differences in the namespace VOPs.
--
But, IMHO, you guys should focus on ZFS since clearly a lot of work has
gone into its port, it works now in FBSD, and it just needs to be made
production-ready and a little more programming support from the
community. It also has a different feature set then HAMMER. P.S.
FreeBSD should issue a $$ grant or stipend to Pawel for that work,
he's really saving your asses. UFS has clearly reached its end-of-life.
Speaking of ZFS, you guys probably went through the same boot issues
that we are going through with HAMMER. I came up with a solution which
turned out to be quite non-invasive and very easy to implement.
* Make a small /boot UFS partition. e.g. 256M ad0s1a.
* Put HAMMER (or ZFS in your case) on the rest of the disk (ad0s1d).
* Adjust the loader to search both / and /boot, so /boot can be its own
partition or a sub-directory on root.
* Add a simple line to /boot/loader.conf to direct the kernel to the
proper root, e.g.
vfs.root.mountfrom="hammer:ad0s1d"
And poof, you're done. Then when the system boots it boots into a
HAMMER (ZFS) root, and /boot is mounted as small UFS filesystem under
it.
Miscellanious other partitions would then be pseudo-fs's under the
single HAMMER (or ZFS) root, removing the need to worry about reserving
particular amounts of space, and providing the needed backup and
snapshot separation domains.
Well, you guys might have already solved it. There isn't much to it.
I recall there was quite a discussion on trying to create redundant
boot setup on FreeBSD, such as boot-to-RAID setups, and having trouble
getting the BIOS to recognize it. There's an alternative solution...
having a separate, small /boot means you can boot from a small solid
state storage device whos MTBF is going to be the same as the PC
hardware itself. No real storage redundancy is needed and if your root
is somewhere else that gives you the option of putting more
sophisticated code in /boot (it being the full kernel) to properly
mount the root. I have 0 (ZERO) trust in BIOS-RAID or card-supported
RAID-enabled (such as with 3Ware) boot support. ZERO.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-stable
mailing list