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
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. :)

--Stephen


-
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:0.146 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site