Dieter Nützel wrote:
>>>>Should EVMS be included, the team will make it our top priority to
>>>>resolve the disputed design issues. If the ruling should be that some of
>>>>our design decisions must change, so be it, we will comply. Certainly
>>>>some changes can not be done by the 20th or 31st, however I feel
>>>>the team can handle most changes before 2.6 ships.
>>>>
>>>>
>>>Thats good to hear. Right now the debate appears to be - "users: please
>>>add EVMS" "hackers: oh my god no" - so you got the feature set right it
>>>seems
>>>
>>>
>>Obvious point:
>>
>>* Linus can always thaw the tree after 31st just for one addition, if
>>something _really_ needs to be added for 2.6
>>
>>
>
>Beside EVMS there is another one: Reiser4
>Getting such an FS "for free" is worth it.
>http://www.namesys.com/v4/v4.html
>
>Hans, can you please send a summary of the "new" FS limits?
>PB/EB, etc.? ;-)
>
>Regards,
> Dieter
>
>
>
The new size limits are those of the Linux VFS layer (we use 64 bit
numbers most places so that if we port to another architecture, or ia64
becomes viable....). I don't think anyone will find them motivating.
Dramatic performance gains while offering transactional FS operations
(wandering logs work, woohoo!), plugins, scalability due to per node
locking, obsoleting a whole slew of traditional database tree algorithms
for better performance, those are motivating. Wait for Linux Journal to
come out, it will have the benchmarks, and you'll see what I mean by
dramatic. It will be good enough that we can focus mostly on getting
the semantics in place for the competition with OFS.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:44 EST