lkml.org 
[lkml]   [2002]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] mount flag "direct" (fwd)
Date
Hi!

Thanks for the comment!

On Tue, 3 Sep 2002, Peter T. Breuer wrote:

> > Rationale:
> > No caching means that each kernel doesn't go off with its own idea of
> > what is on the disk in a file, at least. Dunno about directories and
> > metadata.

> And what if they both allocate the same disk block to another
> file, simultaneously ?

I see - yes, that's a good one.

I assumed that I would need to make several VFS operations atomic
or revertable, or simply forbid things like new file allocations or
extensions (i.e. the above), depending on what is possible or not.

This is precisely the kind of objection that I want to hear about.

OK - reply:
It appears that in order to allocate away free space, one must first
"grab" that free space using a shared lock. That's perfectly feasible.

Thank you.

Where could I intercept the block allocation in VFS?

> A mount option isn't enough to achieve your goal.
>
> It looks like you want GFS or OCFS. Info about GFS can be found at:

No, I don't want ANY FS. Thanks, I know about these, but they're not
it. I want support for /any/ FS at all at the VFS level.

> http://www.opengfs.org/
> http://www.sistina.com/ (commercial GFS)

> Dunno where Oracle's cluster fs is documented.

I know about that too, but no, I do not want ANY FS, I want /any/ FS.
:-)

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.087 / U:1.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site