lkml.org 
[lkml]   [1998]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: LVM / Filesystems / High availability
Stephen C. Tweedie wrote:
>
> Hi,
>
> In article <Pine.LNX.3.96.980619205345.20873A-100000@nightshade.ml.org>,
> <greg@nightshade.ml.org> writes:
>
> > Perhaps an intelgent thing to do would be to have the FS support
> > 'extended metadata'. There could be a pointer at the end of the
> > metadata block to some 'extmetadata' node someplace. At the node there
> > could be n where n<256 key=value pairs. This could be used to store
> > ACLs, compression info, and such. (pref things that arn't needed every
> > file access) There could also be some syscalls so that userspace apps
> > could add/remove/view these things..
>
> For kernel-internal data structures such as ACLs and POSIX capability
> masks, 2.3 ext2fs should support such things. However, that will be
> integrated tightly into the filesystem and will not be exported through
> the VFS. Starting to push this higher up the stack just breaks Unix
> semantics in loads of really unhelpful ways. We already have well
> defined APIs for ACLs and capabilities, plus we have a requirement that
> the kernel enforces these features. Together, that justifies a
> kernel-mode solution. For general user-mode metadata, we really do want
> a user-mode solution (eg. dot files and dot directories). Reiserfs's
> efficient small file handling should make a kernel mode solution
> unnecessary. :)
I'd really appreciate if you could point me to the current ext2fs ideas
and what will be in 2.3.

>
> --Stephen

Vadim

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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