DragonFly BSD
DragonFly kernel List (threaded) for 2004-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Background fsck

From: Gary Thorpe <gathorpe79@xxxxxxxxx>
Date: Fri, 23 Jan 2004 13:37:09 -0500

Dan Melomedman wrote:

Gary Thorpe wrote:

I think ext3 would be easiest (ext2 is already available across the BSD's), but not technically the best. I think ReiserFS wants to grow into a database or some unified name space so..... What I would be interested to know if implementing some of them under a BSD license might peeve the original owners?

Can't do it with ReiserFS (License? Documentation?) since they want to be paid to port it. They also want to be paid twenty-five dollars to ask them a question. They are full of it. It took them many developers and years to get where they are now, and their attitude towards stability issues is known to be "Oh, you made a back up, right?". They do use very novel ideas though obviously. It's great to be able to have scalable directories (millions of files). Email servers wouldn't need directory splits for their queues with this feature among many other uses.

I have also heard of problems with stability/data loss, but I didn't want to comment because I have never really tried it (or any of Linux's journaling options). This is another major issue with ReiserFS: it looks nice on paper but does it deliver? If it doesn't, there is not much point in trying to use it.

But there are also XFS and JFS to consider. Both are probably GPL though.

These deliver (i.e. have been proven on at lest the original platforms), but with these and ReiserFS I would expect resistance to a BSD-licensed implementation. Whether it would be anything more than a philosophical objection is something a lawyer would have to look into.

As someone else pointed out, I was more inclined towards using the GPLed versions of these file systems to generate specs and reimplement them for BSD. The problem with ext2/ext3/FFS is that the way they work is not the most modern: newer file systems can allocate inodes on demand, support extents, large directories, dynamic resizing (both increases and decreases in size), and faster operation (this is debatable for single-user systems). So in my thinking it would be nice to improve on all of these things if you are developing/porting a new file system.

But since ext2 has a BSD implementation and ext3 is based on ext2, this should be the easiest route. I have also read that the journaling implementation for ext3 is applicable to other file systems, so implementing it may make journaling for FFS possible as well (I think Sun and Apple already have implemented journaling/logging for FFS in Solaris and MacOS X respectively?).

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]