Linked by Joel Dahl on Sun 25th Apr 2010 19:25 UTC
FreeBSD Today Jeff Roberson committed his patches to FreeBSD 9 for adding journaling to UFS. No more background fsck after unclean shutdowns! This is a major landmark in the history of UFS, with 11000 new lines of code (and about 2000 removed). Much of the work was done in collaboration with Kirk McKusick, the original author of FFS and Softupdates, under sponsorship form Yahoo!, Juniper and iXsystems. Jeff's blog contains quite a lot of technical information of his work. There's also information on the FreeBSD mailing lists.
Thread beginning with comment 420758
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: UFS?
by Mr.Manatane on Mon 26th Apr 2010 07:29 UTC in reply to "RE: UFS?"
Member since:

I hope not. ZFS has too many problems, we used it in production for many years.

It just sucks ...

Reply Parent Score: -1

RE[3]: UFS?
by aargh on Mon 26th Apr 2010 07:46 in reply to "RE[2]: UFS?"
aargh Member since:

I modded you down as a troll because without providing any examples or links that's what you are.

Reply Parent Score: 4

RE[4]: UFS?
by Mr.Manatane on Mon 26th Apr 2010 13:12 in reply to "RE[3]: UFS?"
Mr.Manatane Member since:

You want proof ?

ok bastard (I call you bastard because you moderate me wihtout knowing ZFS)...

first, try to use it with high level of I/O and not you the computer under your bed ...


- you CAN'T remove a disk. No problem you say ? I say no. Try to migrate your LUN from one bay to another and you are doomed. Try to consolidate your LUNs with less and bigger one ? You can't. And don't tell me it's coming, they are saying that since 5 years now ...

- copy-on-write fragment the filesystem over the time and guess what ? You can't do anything about it. No tool (and prefetch don't do it for high I/O).

- ZFS just kill your san: our storage team told us it was eating 30% of the total I/O only for one host.

- Mirroring with ZFS is crap. ZFS only knows that a mirror is corrupted when it tries to access the data and it will only correct the corrupted data he tries to access. (great no ? what just happens if you lose the good one ?).

The only way to detect that the disk is corrupted if you don't access this data is to use scrub, which kill you disks / san (cf over). And yes it happens to lose a good disk and then it came back (ie you lose a path on a san). Now to resync your disk you have remove it and take it back, but it has to resync everything from scratch...

And I don't speak about ZFS cache problems we had, and the problems we got with those crappy solaris zones...

Reply Parent Score: -1