('x-unknown' encoding is not supported, stored as-is)
I just read through the reiserfs source again. The only change that occurs to
ANY core functionality is the read_inode2 functionality. Which could easily
have a CONFIG_MAGIC_READ_INODE_COOKIE_OR_SOMETHING put around it. So including
the ReiserFS patch would not affect anyone who disables it, as per JFFS, and
earlier statements. So, the previous arguments about JFFS LEGITIMIZE ReiserFSs
inclusion since it doesn't affect users who don't want it.
The memory pressure issues are non-issues to the people allready using
ReiserFS. Even if ReiserFS is compiled into the kernel, the issues will not
affect a user until they mount a ReiserFS partition. And if they are doing
that, they probably know what they are doing.
So forgive my ignorance what are the missing technical merits here? Writing a
journaling FS on top of Linux's VM without patching it directly is at least a
major technical accomplishment -- I definately know this...
So, in summa, we're changing the VM that affects EVERY subsytem in the kernel
during the 2.4 release, and refuse to integrate a patch that gives people an
optional subsystem. Sounds like a feature freeze to me! Smells like something
else...
Mike
On Wed, Aug 09, 2000 at 07:28:27PM -0300, Rik van Riel wrote: > On Wed, 9 Aug
2000, Matthew Wilcox wrote: > > On Wed, Aug 09, 2000 at 08:28:40PM +0100, Adam
Sampson wrote: > > > Please could you have another "accident" and add
reiserfs,
then? > > > > as i understand it, reiserfs (just like all journalling > >
filesystems) requires changes to the core kernel code which are > >
unacceptable at this point. but my understanding may be flawed. > > The
journaling filesystems can lock up under heavy VM load. > (Yes, I know you can
reboot faster... ;) > > The solution requires pinned page reservations by the
>
journaled filesystems, which requires some VM support. > > Also, we need a way
of telling the filesystem to flush > out some dirty pages, since with the
write
ordering > constraints journaling has, the VM subsystem can no > longer just
write out any dirty page, but has to rely > on the filesystem's cooperation. >
> Once the current (minimal intrusion) multiqueue VM is > done, I'll work on
getting the necessary support for > the journaling filesystems in. > > Don't
hold your breath, however. The VM part of the > needed support may be ready in
time for 2.4.0, but > that doesn't mean the journaling filesystems themselves
>
will be added any time soon. > > Maybe they'll be added later, when 2.4 is
known to be > stable, maybe it'll be added only in the kernel RPMs > shipped
by
the Linux distributors... > > regards, > > Rik > -- > "What you're running
that
piece of shit Gnome?!?!" > -- Miguel de Icaza, UKUUG 2000 > >
http://www.conectiva.com/ http://www.surriel.com/ > > > - > To unsubscribe
from
this list: send the line "unsubscribe linux-kernel" in > the body of a message
to majordomo@vger.rutgers.edu > Please read the FAQ at
http://www.tux.org/lkml/
---------------------------------------------- Michael Zappe
<zapman@interlan.net>
Chief Architect, Filesystems Interlan Communications 111 Corning Drive Cary,
NC
27511
"The sorcerer is a Simple Realist: the world is real--but then so must
consciousness be real since its effects are so tangible. The dullard finds
even
wine tasteless but the sorcerer can be intoxicated by the mere sight of
water."
--Hakim Bey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:19 EST