------=_Part_99785_31046053.1231253249375
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi
First I must say that tux3 is the coolest and cleanest (in many ways)
filesystem project I've seen sofar. I've seen a discussion thread about cool
features, so I add mine.
Clustered filesystem :
No grid or things like that, but the ability to maintain a coherent cache on
a single other host that have access to the same disk backend in order to
get a read only acces from this other host, and enable fast filesystem
takeover (Make the filesystem read/write on the "passive" host in 100ms or
less) with no data loss. This would be nice to be able to use tux3 as
backend for high availability luns, and might provide some "NVRAM" if you
assume that a each host of the cluster will not fail at the same time (each
single host could provide some memory to the other).
Filesystem freeze :
Get an utility that flush cache and return something when it's done, then
freeze IO on disk and throttle/stack in a memory buffer until it's full.
When it's full, return again something and resume normal operation, or
freeze IO until we ask to resume. This in order to take clean snapshots when
backend support versionning. Even if it's not necessary due to tux3 design,
it would be nice to be able to do it in order to ensure that some IO are
commited to disk, then get some time to do something to the disk backend,
with no impact on the filesystem side.
Choose bitmaps or extends at filesystem creation time :
Because you sometime know that fragmentation will be your worse foe (that
can happen if you keep a lot of versions), and you don't really care about
metadata weight. If we could just choose, even without any chance to change
this after creation time, it would be very very nice.
Thanks for your time reading this, and tell me if something does not make
sense, english is not my first language !
And thanks for all your efforts providing us a real modern linux filesystem
that deserve that name !
Michael
------=_Part_99785_31046053.1231253249375
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi
First I must say that tux3 is the coolest and cleanest (in many ways) filesystem project I've seen sofar. I've seen a discussion thread about cool features, so I add mine.
Clustered filesystem :
No grid or things like that, but the ability to maintain a coherent cache on a single other host that have access to the same disk backend in order to get a read only acces from this other host, and enable fast filesystem takeover (Make the filesystem read/write on the "passive" host in 100ms or less) with no data loss. This would be nice to be able to use tux3 as backend for high availability luns, and might provide some "NVRAM" if you assume that a each host of the cluster will not fail at the same time (each single host could provide some memory to the other).
Filesystem freeze :
Get an utility that flush cache and return something when it's done, then freeze IO on disk and throttle/stack in a memory buffer until it's full. When it's full, return again something and resume normal operation, or freeze IO until we ask to resume. This in order to take clean snapshots when backend support versionning. Even if it's not necessary due to tux3 design, it would be nice to be able to do it in order to ensure that some IO are commited to disk, then get some time to do something to the disk backend, with no impact on the filesystem side.
Choose bitmaps or extends at filesystem creation time :
Because you sometime know that fragmentation will be your worse foe (that can happen if you keep a lot of versions), and you don't really care about metadata weight. If we could just choose, even without any chance to change this after creation time, it would be very very nice.
Thanks for your time reading this, and tell me if something does not make sense, english is not my first language !
And thanks for all your efforts providing us a real modern linux filesystem that deserve that name !
Michael
------=_Part_99785_31046053.1231253249375--
