[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ogfs-dev]thinking about "clusterizing" etx3



Looks like a pretty good list.

I would add:  bottleneck for block allocation stats in ext3 superblock.  (see other mail).

I think it would be easy to put glock into its own module (combine it with harness).  It looks quite portable, believe it or not, and provides the glops hooks that we would need for interfacing with the ext3 filesystem.

In what ways does jbd need to be cluster aware?  (or are those items 1b - 1e?)

-- Ben --

Opinions are mine, not Intel's

> -----Original Message-----
> From: opengfs-devel-admin@lists.sourceforge.net
> [mailto:opengfs-devel-admin@lists.sourceforge.net]On Behalf Of Dominik
> Vogt
> Sent: Tuesday, September 23, 2003 6:51 AM
> To: opengfs-devel@lists.sourceforge.net
> Subject: [ogfs-dev]thinking about "clusterizing" etx3
> 
> 
> Can we come up with a complete list of issues that have to be
> solved in order to make etx3 cluster aware, with the side
> condition to keep as compatible with ext3 as possible?  Here is
> what I can think of right now:
> 
> 1. Journaling (jbd)
>    a) Make the jbd cluster aware
>    b) Optimise the jbd for clustered journaling
>    c) Allow multiple internal and/or external journals per file
>       system.
>    d) Assign journals to the nodes.
>    e) Concurrent journal recovery.
> 
> 2. Locking
>    a) Add a locking software layer.
>    b) Add a locking backend.
>    c) Carefully examine the possibilities for deadlocks.
>    d) Add callbacks from the locking layer to the file system
>       layer.
>    e) Node health monitoring.
>    f) Avoid the BLK right from the start.
>    g) Carefully tune node internal locking to allow for maximum
>       concurrency.
> 
> 3. Miscellaneous issues
>    a) Investigate page cache issues.
>    b) Investigate buffer cache issues.
>    c) Support for "exotic" operations like shared writable mmap.
>    d) Performance tuning.
>    e) One inode per inode block.
>    f) On-disk compatibility with ext2.
>    g) Inode addressing?
> 
> Did I miss something?
> 
> --
> 
> Thoughts on some individual items:
> 
> 3a, 3b, 3c) I think it is important to keep these issues in mind
>     right from the start.  Otherwise it is quite likely that we
>     reach a dead end.
> 
> 3e) We already talked about it and agreed that it is an important
>     thing to do to prevent deadlocks between multiple nodes.  But
>     I think that is wrong.  You can calculate the inode block
>     from a given inode number and lock the whole block.  This
>     might be bad for concurrency, but prevents all the nasty
>     deadlock issues.
> 
> 3f) The etx3 code could be hacked to allocate only one inode per
>     inode block without too much trouble.  Such a file system
>     would be completely compatible with ext3, i.e. the normal
>     etx3 driver can read and write it.  However, it has to stick
>     with the one-inode-per-block policy.  Otherwise clustered
>     performance of the file system would drop (see 3e).
> 
>     As the next step, one could think about allowing to use the
>     rest of the inode block for file data (like in ogfs).  I'm not
>     sure about the details, but it should be possible to maintain
>     compatibility with a modified version of the ext3 driver that
>     supports all three:  multiple inodes per block, one inode per
>     block, and one inode per block with file data.
> 
> Ciao
> 
> Dominik ^_^  ^_^
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opengfs-devel mailing list
> Opengfs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opengfs-devel
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opengfs-devel mailing list
Opengfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opengfs-devel


[Kernel]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Clusters]     [Linux RAID]     [Yosemite Hiking]     [Linux Resources]

Powered by Linux