Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 May 2004 01:46:58 +0800
From:      Xin LI <delphij@frontfree.net>
To:        John Monkey <thegreatsagemonkey@yahoo.co.uk>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: The journalling file system saga
Message-ID:  <20040513174658.GA396@frontfree.net>
In-Reply-To: <40A34031.1040903@yahoo.co.uk>
References:  <40A34031.1040903@yahoo.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help

--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 13, 2004 at 10:30:25AM +0100, John Monkey wrote:
> [copied from freebsd-questions@]
>=20
> Ladies and Gents,
>=20
> The lack of a journalling file system for FreeBSD has been discussed=20
> over and over on the mailing lists. I have read and understood all the=20
> advocacy for softupdates and background fsck. Softupdates gives great=20
> performance benefits. Background fsck is useful, but with seriously=20
> degraded performance until it completes.

Personally, I'd prefer a optimization on Soft Updates, and the snapshot
code itself. Given the complexity of the code, this might be something
hard to do, however, I believe this is valuable. To tell the truth,
throughly read and attempt to optimize the Soft Updates is on my TODO list =
:-)

IIRC I believe that there is not "objection" for a journalling filesystem
to be exist in FreeBSD, however, it seems that there are too many people
has interest in other areas, and there are simply few people to have
interest and time to develop one for FreeBSD.

Porting NetBSD's LFS implementation might be a good idea, though, however,
I am not sure how much could be gained from this and whether it is
valuable to do so.

> I had to build a storage system this week with a capacity of 1.6TB.
> Regrettfully I decided to use Linux with XFS as the thought of waiting=20
> for fsck to complete in the event of a problem makes me wince. I=20
> experimented with FreeBSD, using two 800GB partitions and things like=20
> that, but in the end it comes back to the fsck if for any reason the=20
> machine goes down uncleanly.

Unfortunatelly, I think there exists something wrong with FreeBSD's
snapshot code, or somewhere else. This is hard (for me) to track down,
and I am looking for some way to trigger the problem.

I have encounted some problem on a production box, however, it is not
permitted to be down for a long time so I got nothing :-(

> I am a big advocate of FreeBSD. I have great reliability on our 60+=20
> FreeBSD machines. I'm ignoring all suggestions for UPSs and the like. I=
=20
> know all about that. That's not the point. The crux is FreeBSD needs a=20
> journalling file system, preferably IMHO based on UFS which we are all=20
> used to. Solaris has logging. It works fine for everything we use it=20
> for. It's a mount option, for those who don't know about it. In other=20
> words I can turn it on off. If I've had to turn away from FreeBSD for=20
> this requirement, I can imagine many other people will have too.

No idea. Maybe someone want to port some journalling file systems to
FreeBSD however I did not saw a mature implementation, nor in ports,
which provides the possiblity to port a GPL'ed file system to FreeBSD
kernel.

What's more, while it is true that journalling is much easier to implement,
it does not guarantee file system consistency well as SoftUpdates can,
when the latter is correctly implemented, and without a non-volatile
journalling storage.

> There's talk of XFS and Reiserfs ports and this and that, the legal=20
> issues of GPL code, blah blah blah. I see that Wasabi provide (sell) a=20
> journalling file system that "builds on the established and trusted=20
> Berkeley Unix Filesystem" [1]. I have no idea of the cost. The point is,=
=20
> it can be done.

I don't think the license is a real issue. It is possible to maintain
a kernel in ports, and even the base if it is not an essential component,
say, you don't have to install it before your kernel can run :-) The
most important problem might be there is not someone who have time to
invest into the port effort - there are needs, but nobody wants to work
for that.

> Let's look at the reality of getting a journalling file system into=20
> FreeBSD. What would it cost to commission someone who knows enough about=
=20
> file systems (preferably UFS IMHO) to write the code? Would anyone be=20
> prepared to contribute to a fund to get this done? How long would it=20
> take? Is anyone remotely interested in this? I would propose that those=
=20
> who put up the money get to decide how the journalling would be=20
> implemented. No ticket, no laundry

I think porting NetBSD's LFS implementation (which is similiar with FFS)
might be a good point to start.

Porting a filesystem to FreeBSD is not something so straightforward.
Taking NetBSD's LFS system as example, the VM system is quite different
between NetBSD and FreeBSD, which will make the port hard. I don't know
exactly how much will it cost, but I bet it will at least cost much time.

It will be our pleasure to see if FreeBSD has a journalling implementation,
however, (personally), it will be better to see a softupdates implementation
which outperforms, and that might be those who have interest in FS area.

Additionally I do not see so many reasons why we must have a journalling
filesystem implementation so impendently. There are more interesting
features in XFS and ReiserFS which does not depend on journalling which
I think is valuable to take part in a new file system.

Cheers,
--=20
Xin LI <delphij frontfree net>	http://www.delphij.net/
See complete headers for GPG key and other information.


--uAKRQypu60I7Lcqm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAo7SSOfuToMruuMARAgUjAJ9NOEfgrEXvaAdSBBYgcsbkwov3kQCghInu
vUIzY9OWArWM7Gm3oNjxoDU=
=u7p6
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040513174658.GA396>