| From: | Miguel Mendez <flynn@xxxxxxxxxxxxxxxxxx> |
| Date: | Wed, 29 Dec 2004 10:54:11 +0100 |
On Tue, 28 Dec 2004 13:03:20 -0800 (PST) Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote: Hi Matt, > The concepts aren't new but my recollection is that most > journaling implementations are directly integrated into the > filesystem and this tends to limit their flexibility. Making the > journaling a kernel layer and taking into account forward-looking > goals really opens up the possibilities. Forward-looking is not > something that people are All this work on the VFS layer looks very exciting and I agree with most of what you've said, specially the "Solaris did it that way" comment. To get to the point, I have a couple of questions about this implementation. Where will the log reside? As a special file in /, at the end of the partition, in another section of the disk? I take a transparent migration from normal UFS to journaled UFS will be provided, at least I hope so :) Are you going to do this as a "black box" or provide an API for tuning/configuring? I had this idea of writing a journaling FS for FreeBSD some time ago, even wrote some code and one of my ideas was to provide a mechanism of hinting the FS with what you wanted to with the file (IIRC VxFS has some of this functions). The idea was that you could open any file and issue a set of ioctl calls saying e.g. I want RAW access to this file, no buffer cache involved (this one I called direct i/o), or I want that this file deleted in a secure way, or I want that a kernel event is generated whenever an unauthorized user/program attempts to access the file. Stuff like that. A problem I found was that concurrent access to the logging system exposes new problems you might not have taken into account when first designing such subsystem, but I'm sure you've thought about that already. What's your solution for a mutex-less concurrent access to the log? Is it possible to do without mutexes at all? Other stuff I wanted to implement, but isn't really related to logging, was alternate streams (like NTFS has) and rich metadata, like BeFS had. What do you think about that? I remember someone (maybe you) talking about per cylinder group dirty flags on UFS some time ago, to reduce fsck time. This could also be a nice addition, although this is definitely FS-dependent code. Like I've said, this looks very interesting and exciting area to work in. :) Cheers, -- Miguel Mendez <flynn@xxxxxxxxxxxxxxxxxx> | lea gfx_lib(pc),a1 http://www.energyhq.es.eu.org | moveq #0,d0 PGP Key: 0xDC8514F1 | move.l 4.w,a6 I reject all mail from hosts that use SORBS | jsr -552(a6)
Attachment:
pgp00007.pgp
Description: PGP signature