Subject: Re: Summer of code ideas
To: None <tls@rek.tjls.com>
From: Johan A.van Zanten <johan@giantfoo.org>
List: netbsd-users
Date: 03/24/2007 16:19:46
Thor Lancelot Simon <tls@rek.tjls.com> wrote:
> On Fri, Mar 23, 2007 at 09:35:26PM -0500, Johan A.van Zanten wrote:
> To be blunt, if you don't understand the difference between a filesystem
> like FFS with transaction journaling added and a log-structured filesystem,
> you're probably not competent to design tests that expose any meaningful
> metric of performance between two kinds of filesystems.
That's fair. I do understand the difference between a journaled FS and a
logging FS. But the last time i spent any significant amount of getting
into the nuts and bolts of this was in 2001, when McKusick was teaching a
FreeBSD internals class at the small company where i was working, and i
picked his brain as much as i could about kernel schedulers, file systems,
pretty much anything.
Obviously, things have changed a lot in 6 years.
But given that NetBSD has no journaled FS, what else did Bill hope i
would use in a "NetBSD-based" comparison? Perhaps i should have just
ignored Bill's original "Do you have any recent references? Specifically
NetBSD-based ones?" as an inherently flawed question because there is no
sutiable JFS on NetBSD. I still don't really understand why he asked for
recent NetBSD-based reference if it's impossible to produce them.
> You'd need to test Solaris FFS and NetBSD FFS without journaling or soft
> updates, then, for the same workload on the same hardware, Solaris FFS
> with journaling and NetBSD FFS with soft updates.
This is a good idea, but unfortunately, i don't currently have the time
to do this comparison correctly. It would involve a lot of hardware
reconfiguration for me, and some of it is time consuming, because Solaris
and NetBSD don't always support the same I/O adapters. Also, time will be
in very short supply for me for the next few months.
> The problem of course is that you might well find enough disparity in
> performance in the first step that you could not extract a meaningful
> number. To actually be guaranteed useful results, you would have to have
> FFS journaling and soft update implementations of good quality that you
> could run in the _same_ kernel, on the same hardware.
Yes, this is the sort of thing i meant when in my last message i said:
"It seems like this would be an inherently inaccurate comparison due
to the different ways the various OSes buffer and cache data, not to
mention things like default block sizes for writes, or file system
clusters."
So we seem to be back to where we were when all of this started. It'd
be a great idea to add ZFS to NetBSD, but some have suggested that's more
work than could be reasonably be expected of a student to complete for a
Summer of Code project, and IIRC, someone mentioned a licenseing issues
that means it might have to be re-written for NetBSD.
Another option would be to add journaling to FFS. I don't know how
difficult this would be, but it seems like it would be more difficult than
porting the working FreeBSD background fsck code, which was what Dieter
and i were suggesting.
I think it was in response to that idea that Bill brought up
performance and asked for NetBSD-based numbers.
-johan