Very Computer

--Dan

Quote:>Does anyone know if ReiserFS, the journaling filesystem, is: ready for
>prime time, has ACL support and is GPL'ed?  Also, is SGI going to
>release their journaling file system XFS under the GPL?

I suspect that if you looked at the web sites of the respective
projects, you might find find some indication as to their plans.

As for ACL support, I suspect that you're confused.  ACL support is
something that should certainly *not* be tied to a particular
filesystem, but rather be applied across all sorts of filesystems.  It
would be a most *terrible* thing if we had Reiserfs ACLs, a distinct
and different scheme for Ext3 ACLs, and then not have any ACL support
for Ext2 or XFS.

--
"I have  traveled the  length and breadth  of this country  and talked
with the best people, and can assure you that data processing is a fad
that won't  last out  the year".  --  Business books  editor, Prentice
Hall 1957

Sean

--
Hal B

--
            Linux helps those who help themselves

Quote:> As for ACL support, I suspect that you're confused.  ACL support is
> something that should certainly *not* be tied to a particular
> filesystem, but rather be applied across all sorts of filesystems.  It
> would be a most *terrible* thing if we had Reiserfs ACLs, a distinct
> and different scheme for Ext3 ACLs, and then not have any ACL support
> for Ext2 or XFS.

--Dan

--
In a world without walls and fences, who needs windows and gates ?
-- Martin

a) Journalling.
   What this indicates is that updates head into a journal/"redo log"
   before hitting the filesystem proper.

   Practical upshot:  If you reboot unexpectedly due to (say) power
   issues, there's no long fsck to hold you back.  On modern HUGE disk
   drives, running fsck can take a LONG time.  With Reiserfs, all that
   happens is that it replays the redo log to update the last few
   things that may have been changed on disk.  This takes a few
   seconds, not a few minutes.

b) Uses B-trees to represent directories.

   This guarantees O(log n) access time to files.  If you have
   directories with MANY, MANY files, as occurs on news servers, this
   can be a substantial improvement over the O(n) scan that can be
   required by Ext2.

c) Efficient storage of tiny files.

   The intent is to allow efficiently storing tiny files, so that the
   minimum consumption may be 50 bytes rather than being 2K or so.

   This makes it practical to construct applications that, instead of
   writing data out to one big file, and then having to parse it,
   create hierarchical information by writing out hordes of tiny
   files.  

   Parsers can go away, and you can get fast random access to update
   bits of data here and there.

   The COOL application is to use this to represent a database, where
   each record is a file.  Rather than the Windows Registry situation
   of the database being a fragile binary data structure sitting a
   little fearfully atop a filesystem, you use the robustness of the
   filesystem to keep the DBMS robust, and committing an update to a
   record can be done robustly in a SHELL SCRIPT via something as
   simple as:
      echo $NEWVALUE > $DBHOME/$MYTABLE/$KEY

   I'm not sure how efficient Reiserfs is, at this point, so this is
   not yet a strength...
--
MICROS~1:  Where do you  want to  go today?   Linux: Been  there, done
that.

Quote:> Also, is SGI going to
> release their journaling file system XFS under the GPL?

> --Dan