What's up with XFS in linux-2.5? I've seen some patches sent to the list
but I havn't seen any replies from linus.. What needs to be done to finally
merge it?
--
L1: khromy ;khromy(at)lnuxlab.ath.cx
I've noticed this too. And I must say, ITS QUITE FUCKING RUDE OF LINUS.
khromy wrote:
> What's up with XFS in linux-2.5? I've seen some patches sent to the list
> but I havn't seen any replies from linus.. What needs to be done to
> finally
> merge it?
>
> I've noticed this too. And I must say, ITS QUITE FUCKING RUDE OF LINUS.
Fix your capslock and be so kind as to refrain from posting more comments
of such immense value here thankyou.
On Tue, 10 Sep 2002 06:08:06 +1000
Wade <[email protected]> escribi?:
> I've noticed this too. And I must say, ITS QUITE FUCKING RUDE OF
> LINUS.
Well, you have the patches, so you can't say that you can't use it. If
you don't like you can make a branch from the 2.5 kernel including xfs.
But personally i don't mind if xfs is not included, I assume that
there's some reason for not merging it, and i'd be glad to hear the
reasons for not merging it, insteand of blaming to Linus "The evil
non-merger" Torvalds
>
> khromy wrote:
> > What's up with XFS in linux-2.5? I've seen some patches sent to the
> > list but I havn't seen any replies from linus.. What needs to be
> > done to finally
> > merge it?
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi,
On Mon, 9 Sep 2002, khromy wrote:
> What's up with XFS in linux-2.5? I've seen some patches sent to the list
> but I havn't seen any replies from linus.. What needs to be done to
> finally merge it?
It has been stated quite regularly that XFS
a) doesn't always work like it should yet
b) involves some changes which Linus doesn't like in particular, for
pretty good reasons.
Go read the archives on that if you want more.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
Thunder from the hill <[email protected]> writes:
> Hi,
>
> On Mon, 9 Sep 2002, khromy wrote:
> > What's up with XFS in linux-2.5? I've seen some patches sent to the list
> > but I havn't seen any replies from linus.. What needs to be done to
> > finally merge it?
>
> It has been stated quite regularly that XFS
> a) doesn't always work like it should yet
That's quite bogus. While not being perfect XFS just works fine for lots
of people in production and performs very well for a lot of tasks.
> b) involves some changes which Linus doesn't like in particular, for
> pretty good reasons.
I think that's FUD too. That last patch had 6 lines or so of changes
to generic code, everything else was already merged.
I guess it just ended up in Linus' spam filters, like some other things...
-Andi
Linus has proudly declared himself to be a non-patch accepting bastard many
times in the past.
This has the interesting side effect of spurring debate and flame wars
about the joys and horrors of
ac-rmap-xfs-O1-devfs-lvm-xfs-lowlat-preempt-blah blah patchsets. This is
a Good Thing(tm).
You should thank Linus for being Linus, and also thank those who
actively maintain alternate branches of the kernel.
On 09/09, Wade said something like:
> I've noticed this too. And I must say, ITS QUITE FUCKING RUDE OF LINUS.
>
> khromy wrote:
> > What's up with XFS in linux-2.5? I've seen some patches sent to the list
> > but I havn't seen any replies from linus.. What needs to be done to
> > finally
> > merge it?
--
Shawn Leas
[email protected]
If toast always lands butter-side down, and cats always land on
their feet, what happen if you strap toast on the back of a cat
and drop it?
-- Stephen Wright
On Mon, 2002-09-09 at 17:20, Shawn wrote:
> XFS needs a sponser. Who amung Linus's circle of trust cares to comment
> or re-evaluate?
>
> If no one, I guess it's a moot point.
Christoph Hellwig (hch) is working on the patches... I cannot speak for
Linus, but I think most of us trust him. I do.
Robert Love
XFS needs a sponser. Who amung Linus's circle of trust cares to comment
or re-evaluate?
If no one, I guess it's a moot point.
On 09/09, Andi Kleen said something like:
> Thunder from the hill <[email protected]> writes:
>
> > Hi,
> >
> > On Mon, 9 Sep 2002, khromy wrote:
> > > What's up with XFS in linux-2.5? I've seen some patches sent to the list
> > > but I havn't seen any replies from linus.. What needs to be done to
> > > finally merge it?
> >
> > It has been stated quite regularly that XFS
> > a) doesn't always work like it should yet
>
> That's quite bogus. While not being perfect XFS just works fine for lots
> of people in production and performs very well for a lot of tasks.
>
> > b) involves some changes which Linus doesn't like in particular, for
> > pretty good reasons.
>
> I think that's FUD too. That last patch had 6 lines or so of changes
> to generic code, everything else was already merged.
>
> I guess it just ended up in Linus' spam filters, like some other things...
>
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Shawn Leas
[email protected]
I planted some bird seed. A bird came up. Now I don't know
what to feed it.
-- Stephen Wright
On Tue, 10 Sep 2002, Wade wrote:
> I've noticed this too. And I must say, ITS QUITE FUCKING RUDE OF LINUS.
If you think you can do things better you should fork Wadix ;)
Linus might not be the easiest user interface and I've had some
problems too in the past, but everybody will have to admit that
the current system just works in the long run.
cheers,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: [email protected] [email protected]
Quoting Thunder from the hill <[email protected]>:
>
> It has been stated quite regularly that XFS
> a) doesn't always work like it should yet
I use XFS on a number of production servers, and it has always served me well.
The only problem is of course getting a kernel that supports XFS. I'm glad many
of the more mainstream linux distributions are starting to have support for XFS
support "out of the box", but I feel until it's in the mainline kernel many
people will never even have a chance to try it.
-------------------------------------------------
sent via KingsMeade secure webmail http://www.kingsmeadefarm.com
In the long run, for sure. I'm not saying Linus needs to be replaced,
but his _manners_ could do with some work. Those XFS guys have worked
quite hard to make the merge fairly painless, and Linus wont even
comment (that I've seen, see
http://marc.theaimsgroup.com/?l=linux-kernel&m=103118187002156&w=2).
BTW: I'm only a lurker, I don't even use XFS :-)
[ _XXX_ is (C) 2002 Linus Torvalds. ]
Rik van Riel wrote:
> On Tue, 10 Sep 2002, Wade wrote:
>
>
>>I've noticed this too. And I must say, ITS QUITE FUCKING RUDE OF LINUS.
>
>
> If you think you can do things better you should fork Wadix ;)
>
> Linus might not be the easiest user interface and I've had some
> problems too in the past, but everybody will have to admit that
> the current system just works in the long run.
>
> cheers,
>
> Rik
Keep in mind Linus gets flooded by patches on a constant basis and also
needs to focus on getting core functions working again so I wouldn't be
supprised if he hasn't had time to deal with XFS yet.
Hes also known for just deleting his mail que when it gets overloaded so
he may not have even read the messages in question.
Gerhard
On Tue, 10 Sep 2002, Wade wrote:
> Date: Tue, 10 Sep 2002 16:23:48 +1000
> From: Wade <[email protected]>
> To: [email protected]
> Subject: Re: XFS?
>
> In the long run, for sure. I'm not saying Linus needs to be replaced,
> but his _manners_ could do with some work. Those XFS guys have worked
> quite hard to make the merge fairly painless, and Linus wont even
> comment (that I've seen, see
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103118187002156&w=2).
>
> BTW: I'm only a lurker, I don't even use XFS :-)
>
> [ _XXX_ is (C) 2002 Linus Torvalds. ]
>
> Rik van Riel wrote:
> > On Tue, 10 Sep 2002, Wade wrote:
> >
> >
> >>I've noticed this too. And I must say, ITS QUITE FUCKING RUDE OF LINUS.
> >
> >
> > If you think you can do things better you should fork Wadix ;)
> >
> > Linus might not be the easiest user interface and I've had some
> > problems too in the past, but everybody will have to admit that
> > the current system just works in the long run.
> >
> > cheers,
> >
> > Rik
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
At 04:20 PM 9/9/2002 -0500, Shawn wrote:
>XFS needs a sponser. Who amung Linus's circle of trust cares to comment
>or re-evaluate?
>
>If no one, I guess it's a moot point.
(see below)
>On 09/09, Andi Kleen said something like:
> > Thunder from the hill <[email protected]> writes:
> >
> > > Hi,
> > >
> > > On Mon, 9 Sep 2002, khromy wrote:
> > > > What's up with XFS in linux-2.5? I've seen some patches sent to the
> list
> > > > but I havn't seen any replies from linus.. What needs to be done to
> > > > finally merge it?
> > >
> > > It has been stated quite regularly that XFS
> > > a) doesn't always work like it should yet
> >
> > That's quite bogus. While not being perfect XFS just works fine for lots
> > of people in production and performs very well for a lot of tasks.
> >
> > > b) involves some changes which Linus doesn't like in particular, for
> > > pretty good reasons.
> >
> > I think that's FUD too. That last patch had 6 lines or so of changes
> > to generic code, everything else was already merged.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Mike
I'm not sure what this is intended to communicate.
The question was specifically regarding filesystem support, so I'll
assume you meant to point out that XFS does not always work like it
should.
Then, am I incorrect that since almost all of XFS that's left to merge
is XFS code and not changes to the kernel at large?
If this is correct, could I then make the assumption that merging XFS
would be minimally impactful for those kernel user who do not enable it?
Linus incorporated reiserfs long before it "always functioned as it is
supposed to", so I find myself wondering where your point was.
(see below) and "^^^^^^^^^^^^^" don't fully cover your thoughts I'm
afraid.
On 09/10, Mike Galbraith said something like:
> At 04:20 PM 9/9/2002 -0500, Shawn wrote:
> >XFS needs a sponser. Who amung Linus's circle of trust cares to comment
> >or re-evaluate?
> >
> >If no one, I guess it's a moot point.
>
> (see below)
>
> >On 09/09, Andi Kleen said something like:
> > > Thunder from the hill <[email protected]> writes:
> > >
> > > > Hi,
> > > >
> > > > On Mon, 9 Sep 2002, khromy wrote:
> > > > > What's up with XFS in linux-2.5? I've seen some patches sent to the
> > list
> > > > > but I havn't seen any replies from linus.. What needs to be done to
> > > > > finally merge it?
> > > >
> > > > It has been stated quite regularly that XFS
> > > > a) doesn't always work like it should yet
> > >
> > > That's quite bogus. While not being perfect XFS just works fine for lots
> > > of people in production and performs very well for a lot of tasks.
> > >
> > > > b) involves some changes which Linus doesn't like in particular, for
> > > > pretty good reasons.
> > >
> > > I think that's FUD too. That last patch had 6 lines or so of changes
> > > to generic code, everything else was already merged.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> -Mike
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Shawn Leas
[email protected]
I got food poisoning today. I don't know when I'll use it.
-- Stephen Wright
On Tue, 2002-09-10 at 15:23, Shawn wrote:
> If this is correct, could I then make the assumption that merging XFS
> would be minimally impactful for those kernel user who do not enable it?
Yes, and I think it will go in. It has just not made it passed Linus's
filters yet, but it will - hch knows what he is doing.
Robert Love
Hi,
On Tue, 10 Sep 2002, Shawn wrote:
> Linus incorporated reiserfs long before it "always functioned as it is
> supposed to", so I find myself wondering where your point was.
It was my point, actually. I was referring to some crashes caused by XFS,
however, they seem resolved. I also want to be commonly known as not
hating XFS. It seems pretty cool.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Tue, 10 Sep 2002 14:23:47 -0500, Shawn <[email protected]> wrote:
>I'm not sure what this is intended to communicate.
>
>The question was specifically regarding filesystem support, so I'll
>assume you meant to point out that XFS does not always work like it
>should.
>
>Then, am I incorrect that since almost all of XFS that's left to merge
>is XFS code and not changes to the kernel at large?
>
>If this is correct, could I then make the assumption that merging XFS
>would be minimally impactful for those kernel user who do not enable it?
>
>Linus incorporated reiserfs long before it "always functioned as it is
>supposed to", so I find myself wondering where your point was.
If memory serves, Linus incorporated reiserfs after several major
distributors started including it. Linus seems to pay a lot of
attention to distributions in areas where he isn't so much interested.
So does Redhat/Suse/??? ship XFS yet?
john
John Alvord wrote:
>
>
>If memory serves, Linus incorporated reiserfs after several major
>distributors started including it. Linus seems to pay a lot of
>attention to distributions in areas where he isn't so much interested.
>
>So does Redhat/Suse/??? ship XFS yet?
>
>john
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Mandrake does if I remember right.
XFS is cool, and their allocation at flush innovation has influenced
reiser4 deeply. I wish them well.
Hans
> So does Redhat/Suse/??? ship XFS yet?
Don't know about RedHat & others, but SuSE _does_ ship XFS.
-Nick
> So does Redhat/Suse/??? ship XFS yet?
>
> john
>
Mandrake has had XFS support in the default boot kernel since 8.0. AFAIK, Suse
and Slackware also have XFS capable kernels now too.
-------------------------------------------------
sent via KingsMeade secure webmail http://www.kingsmeadefarm.com
and you know something is mainstream when slackware includes it.
said as a longtime slackware user :-)
I know slackware 8.1 included XFS, I don't think it was in 8.0.
David Lang
On Tue, 10 Sep 2002, Joe Kellner wrote:
> Date: Tue, 10 Sep 2002 16:17:52 -0400
> From: Joe Kellner <[email protected]>
> To: John Alvord <[email protected]>
> Cc: [email protected]
> Subject: Re: XFS?
>
>
> > So does Redhat/Suse/??? ship XFS yet?
> >
> > john
> >
>
> Mandrake has had XFS support in the default boot kernel since 8.0. AFAIK, Suse
> and Slackware also have XFS capable kernels now too.
>
>
>
> -------------------------------------------------
> sent via KingsMeade secure webmail http://www.kingsmeadefarm.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> > So does Redhat/Suse/??? ship XFS yet?
>
> Mandrake has had XFS support in the default boot kernel since 8.0. AFAIK, Suse
> and Slackware also have XFS capable kernels now too.
Slackware lets you use a special install kernel that has XFS [1] compiled in
and that the installer can take advantage of. However, you have to provide
your own XFS vmlinuz for actually booting into the new system, as Slackware
rightly continues to use bare Marcelo(tm) kernels.
[1] and JFS, too.
T.
> > So does Redhat/Suse/??? ship XFS yet?
>
> Don't know about RedHat & others, but SuSE _does_ ship XFS.
RedHat apparently doesn't want any more trouble than absolutely
necessary and only provides ext[32] installs by default. SuSE and
Mandrake can't -- *IMHO* -- be considered sensible distributions.
T.
On Tue, 2002-09-10 at 17:18, Nick LeRoy wrote:
> > So does Redhat/Suse/??? ship XFS yet?
>
> Don't know about RedHat & others, but SuSE _does_ ship XFS.
>
I should probably keep out of the discussion and I am not presenting
this as an argument for inclusion, but for an incomplete list of XFS
users and distribution including it look here:
http://oss.sgi.com/projects/xfs/xfs_users.html
Steve
>>>>> "Joe" == Joe Kellner <[email protected]> writes:
>> So does Redhat/Suse/??? ship XFS yet?
>>
>> john
>>
Joe> Mandrake has had XFS support in the default boot kernel since
Joe> 8.0. AFAIK, Suse and Slackware also have XFS capable kernels now
Joe> too.
FWIW so does debian.
--
Dr Peter Chubb [email protected]
You are lost in a maze of BitKeeper repositories, all almost the same.
Thunder from the hill wrote:
> Hi,
>
> On Tue, 10 Sep 2002, Shawn wrote:
>
>>Linus incorporated reiserfs long before it "always functioned as it is
>>supposed to", so I find myself wondering where your point was.
>
>
> It was my point, actually. I was referring to some crashes caused by XFS,
> however, they seem resolved. I also want to be commonly known as not
> hating XFS. It seems pretty cool.
>
> Thunder
I know of some rather large projects that use it with mandrake... But I
can't be specific. ;)
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
Why won't this topic die?
Cheers, Dean McEwan. Currently hacking KGI, which I don't understand, oh and ask me about OpenModemTalk...
On Wed, 11 Sep 2002 10:31:07 +1000 Peter Chubb <[email protected]> wrote:
In article <[email protected]> you wrote:
> Slackware lets you use a special install kernel that has XFS [1] compiled in
so does debian do support XFS:
http://www.physik.tu-cottbus.de/~george/woody_xfs/
Greetings
Bernd
At 02:23 PM 9/10/2002 -0500, Shawn wrote:
>I'm not sure what this is intended to communicate.
(sigh)
If "everything else" the XFS team has asked for has gone in, it seems
unlikely that
sponsorship is needed.
-Mike
On Tue, Sep 10, 2002 at 03:18:31PM -0700, Nick LeRoy wrote:
> > So does Redhat/Suse/??? ship XFS yet?
>
> Don't know about RedHat & others, but SuSE _does_ ship XFS.
>
Yes it does. I'm guessing the one in 8.0 is an older
version because i found it performs abysmally. It seemed
stable enough but i used it for backups with lots of file
creation and deletion and my jobs took about 10 times longer
to run than on ext2 or JFS (also included in the 2.4.18+
SuSE 8.0) For other use it is probably fine. I look
forward to trying newer versions.
While i'm talking about it online resize including shrinkage
is a fairly high priority for me. Any journaling filesystem
without that feature is going to be a second-rater. So
without it XFS is unlikely to become a primary filesystme
choice for me. That said, i'm glad to see variety in the
journaling filesystems and look forward to XFS getting in
mainline so we can use whatever filesystem that best meets
our needs. This of course means that we will need decent,
independent, comparisons of the filesystems.
And think about this: In almost all other OSs of substance
you have one or two basic filesystem types and if you want
journaling you have to pay extra for it. And journaling
filesystems don't have to be fast, there is very little real
competition.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Wednesday 11 September 2002 01:43, jw schultz wrote:
Not that I'm trying to keep this thread alive or anything..
> Yes it does. I'm guessing the one in 8.0 is an older
> version because i found it performs abysmally. It seemed
> stable enough but i used it for backups with lots of file
> creation and deletion and my jobs took about 10 times longer
> to run than on ext2 or JFS (also included in the 2.4.18+
> SuSE 8.0) For other use it is probably fine. I look
> forward to trying newer versions.
I wasn't making any claims to have _tried_ it or anything. I simply stated
that it's _there_ and, I think, supported. Personally, I've switched to
Reiserfs (thanks, Hans!), which I'm _really_ happy with. Yeah, I should
investigate the other options, but, honestly, there isn't a lot of neccessity
to.
> And think about this: In almost all other OSs of substance
> you have one or two basic filesystem types and if you want
> journaling you have to pay extra for it. And journaling
> filesystems don't have to be fast, there is very little real
> competition.
I'm not sure if you're saying that this is a bad thing or a good thing. FWIW,
I think this is a wonderful feature, albeit potentially confusing to a Newbie
For my O2 running IRIX I get XFS whether I like it or not, for Solaris I get
UFS no matter how much it sucks (I'm not really saying that it does; I don't
have much knowledge of it to be honest). This multitude of choices really
causes competition between them, and makes them all better in the long run.
Think about this: Namesys is working on Reiserfs v4.0. v4.0. Hell - it's
only been incorporated into the mainstream kernel for less than a year (at
least by my recollection), yet it keeps advancing. I have _no_ idea what UFS
version Solaris 8 is using (admittedly at least somewhat due to ignorance --
I use Solaris because I have a good ol' SPARCprinter which alas is not
supported by Linux), or whether they've bother to do development on it to
make it better, faster, etc. Yet, _we_ get this advancement all the time.
Isn't it great?!
Ok, time to step off my soapbox and get back to work.
-Nick
Which is why I pointed out that the issue at hand was not regarding the
everything else, but in fact the actual filesystem support.
As far as why the rest is still pending, I was just offering ideas.
A lot of this thread is advocacy as opposed to substantive conversation
about the how and/or why/why not of inclusion of XFS into mainline.
Fankly, there is no /real/ answer except "Linus has not weighed in on
the current question".
I lost my ability to invest emotions in either side of huge kernel
debates when the devfs and lvm wars happened.
On 09/10, Mike Galbraith said something like:
> At 02:23 PM 9/10/2002 -0500, Shawn wrote:
> >I'm not sure what this is intended to communicate.
>
> (sigh)
> If "everything else" the XFS team has asked for has gone in, it seems
> unlikely that
> sponsorship is needed.
>
> -Mike
--
Shawn Leas
[email protected]
I went to the eye doctor and found out I needed glasses for reading. So,
I got some flip-up contact lenses.
-- Stephen Wright
On 9 Sep 2002, Andi Kleen wrote:
> Thunder from the hill <[email protected]> writes:
>
> > Hi,
> >
> > On Mon, 9 Sep 2002, khromy wrote:
> > > What's up with XFS in linux-2.5? I've seen some patches sent to the list
> > > but I havn't seen any replies from linus.. What needs to be done to
> > > finally merge it?
> >
> > It has been stated quite regularly that XFS
> > a) doesn't always work like it should yet
>
> That's quite bogus. While not being perfect XFS just works fine for lots
> of people in production and performs very well for a lot of tasks.
More to the point, a quick scan of LKML will show that there are fixes for
ext3 and reisser on a regular basis, so one must assume that they don't
always work as they should either. XFS is in a number of distributions,
and is stable for users.
> > b) involves some changes which Linus doesn't like in particular, for
> > pretty good reasons.
>
> I think that's FUD too. That last patch had 6 lines or so of changes
> to generic code, everything else was already merged.
Does that mean he should only dislike it a little because it's small? At
this stage I would hope he will at least tell you why it wasn't accepted,
since XFS is a desirable feature for many people (as evidence vendors
providing it).
I'd like XFS, I think it's a good feature politically, hopefully it will
not just drop just as it's becoming stable for non-critical production
use.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 2002-09-11 at 16:12, Bill Davidsen wrote:
> More to the point, a quick scan of LKML will show that there are fixes for
> ext3 and reisser on a regular basis, so one must assume that they don't
> always work as they should either. XFS is in a number of distributions,
> and is stable for users.
Thats never been the big concern. The problem has always been that XFS
was very invasive code so it might break stuff for people who dont
choose to use experimental xfs stuff. Thats slowly improving
Nick LeRoy wrote:
>
>
>
>Think about this: Namesys is working on Reiserfs v4.0. v4.0. Hell - it's
>only been incorporated into the mainstream kernel for less than a year (at
>least by my recollection), yet it keeps advancing. I have _no_ idea what UFS
>version Solaris 8 is using (admittedly at least somewhat due to ignorance --
>I use Solaris because I have a good ol' SPARCprinter which alas is not
>supported by Linux), or whether they've bother to do development on it to
>make it better, faster, etc. Yet, _we_ get this advancement all the time.
>Isn't it great?!
>
>
>
I think you'll really like v4, it is a complete rewrite from scratch,
and far better in every way. :)
Hans
Quoting Hans Reiser <[email protected]>:
> I think you'll really like v4, it is a complete rewrite from scratch,
> and far better in every way. :)
>
> Hans
>
But will it un-delete my customers files that they accidently deleted and they
want me to get back? :)
-------------------------------------------------
sent via KingsMeade secure webmail http://www.kingsmeadefarm.com
Joe Kellner wrote:
>Quoting Hans Reiser <[email protected]>:
>
>
>
>
>
>>I think you'll really like v4, it is a complete rewrite from scratch,
>>and far better in every way. :)
>>
>>Hans
>>
>>
>>
>
>
>But will it un-delete my customers files that they accidently deleted and they
>want me to get back? :)
>
>-------------------------------------------------
>sent via KingsMeade secure webmail http://www.kingsmeadefarm.com
>
>
>
>
If you write the appropriate plugin, yes....;-)
At 09:55 AM 9/11/2002 -0500, Shawn wrote:
>Which is why I pointed out that the issue at hand was not regarding the
>everything else, but in fact the actual filesystem support.
I was just trying to say that everything _appears_ to be on track from my
(remote) perspective. I've noticed no gripes from the XFS team, only
evidence that development continues. If there are 6 lines of generic code
changes left, that means a lot has happened.
>As far as why the rest is still pending, I was just offering ideas.
>
>A lot of this thread is advocacy as opposed to substantive conversation
>about the how and/or why/why not of inclusion of XFS into mainline.
Advocacy without technical meat sucks.
>Fankly, there is no /real/ answer except "Linus has not weighed in on
>the current question".
Hey, maybe he's trying to convince (blackmail;) them to port some bandwidth
guarantee stuff ;))))) (I hope that's enough smilies)
>I lost my ability to invest emotions in either side of huge kernel
>debates when the devfs and lvm wars happened.
I love it when the heavyweights square off (oooo:). Unfortunately, that often
leads to a bunch of dipsticks hollering "food fight!" ;-)
-Mike
On Wed, 11 Sep 2002, Hans Reiser wrote:
> I think you'll really like v4, it is a complete rewrite from scratch,
> and far better in every way. :)
Same disk layout or a new one ?
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
On Wednesday 11 September 2002 19:08, Hans Reiser wrote:
> I think you'll really like v4, it is a complete rewrite from scratch,
> and far better in every way. :)
I don't speak as developer, but I really hope it follows the Linux
CodingStyle this time. Code review would get much benefit, making v4
even better.
On Wed, 2002-09-11 at 11:03, Alan Cox wrote:
> Thats never been the big concern. The problem has always been that XFS
> was very invasive code so it might break stuff for people who dont
> choose to use experimental xfs stuff. Thats slowly improving
Alan -
The last patch Christoph posted against 2.5 is not the least bit
invasive. Excluding documentation and configuration files, these are
the changes:
o 1 new process flag: +#define PF_FSTRANS 0x00100000
o 1 new CTL_VM name: + VM_PAGEBUF=18
o 1 new CTL_FS name: + FS_XFS=17
o 1 exported symbol: +EXPORT_SYMBOL(mark_page_accessed);
and of course an addition to fs/Makefile:
+obj-$(CONFIG_XFS_FS) += xfs/
That's it. The rest is under fs/xfs.
(2.4 is more invasive, but this thread started out talking about XFS in
2.5).
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
[email protected] SGI, Inc. 651-683-3102
On Wed, 11 Sep 2002 13:13:24 -0400
"Joe Kellner" <[email protected]> wrote:
>
> But will it un-delete my customers files that they accidently deleted and they
> want me to get back? :)
>
Do what the mac does, use mv when people type rm... ;)
Remco
On Wed, Sep 11, 2002 at 08:20:36AM -0700, Nick LeRoy wrote:
> On Wednesday 11 September 2002 01:43, jw schultz wrote:
>
> > And think about this: In almost all other OSs of substance
> > you have one or two basic filesystem types and if you want
> > journaling you have to pay extra for it. And journaling
> > filesystems don't have to be fast, there is very little real
> > competition.
>
> I'm not sure if you're saying that this is a bad thing or a good thing. FWIW,
Unless you like tyrany choice is a good thing(TM). Trust
me, i don't like tyrany.
> I think this is a wonderful feature, albeit potentially confusing to a Newbie
> For my O2 running IRIX I get XFS whether I like it or not, for Solaris I get
> UFS no matter how much it sucks (I'm not really saying that it does; I don't
> have much knowledge of it to be honest). This multitude of choices really
> causes competition between them, and makes them all better in the long run.
On Solaris and some other platforms you can, with lots of
money, buy a license to run the Veritas journaling
filesystem. It comes with a license manager and you have to
get license keys to mount the filesystems. Ever had a
filesystem not come up after a reboot because the license
expired, i have (ouch, i told management to renew the
license). Is veritas fast? I don't know. They hype the
journaling, not speed. And what are you going to benchmark
against?.
Recently Veritas announced they were going to support Linux.
I'm curious to see how they fare in a shootout with the
other journaling filesystems. Of course i wouldn't taint MY
kernel to run it when i have four others to choose from.
> Think about this: Namesys is working on Reiserfs v4.0. v4.0. Hell - it's
> only been incorporated into the mainstream kernel for less than a year (at
> least by my recollection), yet it keeps advancing. I have _no_ idea what UFS
> version Solaris 8 is using (admittedly at least somewhat due to ignorance --
> I use Solaris because I have a good ol' SPARCprinter which alas is not
> supported by Linux), or whether they've bother to do development on it to
> make it better, faster, etc. Yet, _we_ get this advancement all the time.
> Isn't it great?!
Fantastic. And that is largly without competition. Just
wait and watch what the JFS and XFS developers do to improve
their products to keep up.
As for UFS, the only thing they can do to it is to adjust
the block allocation heuristics. Something i'm sure they
have done to death for the TPC benchmarks they live and die
by.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Wed, 2002-09-11 at 19:55, Eric Sandeen wrote:
> The last patch Christoph posted against 2.5 is not the least bit
> invasive. Excluding documentation and configuration files, these are
> the changes:
As I said its improving
> > I'm not sure if you're saying that this is a bad thing or a good thing.
> > FWIW,
>
> Unless you like tyrany choice is a good thing(TM). Trust
> me, i don't like tyrany.
I like the way you phrased that...
> On Solaris and some other platforms you can, with lots of
> money, buy a license to run the Veritas journaling
> filesystem. It comes with a license manager and you have to
> get license keys to mount the filesystems. Ever had a
> filesystem not come up after a reboot because the license
> expired, i have (ouch, i told management to renew the
> license). Is veritas fast? I don't know. They hype the
> journaling, not speed. And what are you going to benchmark
> against?.
Wow.. I thought it was a pain in the ass when we had licencing problems with
ClearCase.
> Recently Veritas announced they were going to support Linux.
> I'm curious to see how they fare in a shootout with the
> other journaling filesystems. Of course i wouldn't taint MY
> kernel to run it when i have four others to choose from.
Why, oh, why would anybody _pay_ for something like that when there's a
plethora of excellent filesystems for Linux already?!
> Fantastic. And that is largly without competition. Just
> wait and watch what the JFS and XFS developers do to improve
> their products to keep up.
At least there seems to be active & open development on them.
Thanks for the reply!
-Nick
On Wed, Sep 11, 2002 at 02:21:46PM -0700, jw schultz wrote:
> On Wed, Sep 11, 2002 at 08:20:36AM -0700, Nick LeRoy wrote:
> > On Wednesday 11 September 2002 01:43, jw schultz wrote:
> > I think this is a wonderful feature, albeit potentially confusing to a Newbie
> > For my O2 running IRIX I get XFS whether I like it or not, for Solaris I get
> > UFS no matter how much it sucks (I'm not really saying that it does; I don't
> > have much knowledge of it to be honest). This multitude of choices really
> > causes competition between them, and makes them all better in the long run.
>
> On Solaris and some other platforms you can, with lots of
> money, buy a license to run the Veritas journaling
> filesystem. It comes with a license manager and you have to
> get license keys to mount the filesystems. Ever had a
> filesystem not come up after a reboot because the license
> expired, i have (ouch, i told management to renew the
> license). Is veritas fast? I don't know. They hype the
> journaling, not speed. And what are you going to benchmark
> against?.
Against UFS, of course [1] :-) Their hype is "our journal is faster than
UFS", which is probably true. They have extent-based allocation,
which is good for their greatest hype - performance with databases
(see all the marketing shredder-food about [Cached] QuickIO).
They have hot resizing, which fast as hell (again, compared to UFS),
they have snapshots, which are cool. And don't forget the GFS capability,
which I am yet to see in action. [2]
So in Solaris world, for large filesystems, Veritas is the winner. I am
really looking forward to seeing how will they do in the OpenSource
world.
[1] Actually they benchmark Oracle on raw devices vs. Cached QuickIO, too.
[2] Even tough the options are expensive, in my experience all of them
work perfectly.
--
Kind regards,
Robert Varga
------------------------------------------------------------------------------
[email protected] http://hq.sk/~nite/gpgkey.txt
On Thu, Sep 12, 2002 at 01:01:38AM +0200, Robert Varga wrote:
> On Wed, Sep 11, 2002 at 02:21:46PM -0700, jw schultz wrote:
> > On Wed, Sep 11, 2002 at 08:20:36AM -0700, Nick LeRoy wrote:
> > > On Wednesday 11 September 2002 01:43, jw schultz wrote:
> > > I think this is a wonderful feature, albeit potentially confusing to a Newbie
> > > For my O2 running IRIX I get XFS whether I like it or not, for Solaris I get
> > > UFS no matter how much it sucks (I'm not really saying that it does; I don't
> > > have much knowledge of it to be honest). This multitude of choices really
> > > causes competition between them, and makes them all better in the long run.
> >
> > On Solaris and some other platforms you can, with lots of
> > money, buy a license to run the Veritas journaling
> > filesystem. It comes with a license manager and you have to
> > get license keys to mount the filesystems. Ever had a
> > filesystem not come up after a reboot because the license
> > expired, i have (ouch, i told management to renew the
> > license). Is veritas fast? I don't know. They hype the
> > journaling, not speed. And what are you going to benchmark
> > against?.
>
> Against UFS, of course [1] :-) Their hype is "our journal is faster than
> UFS", which is probably true. They have extent-based allocation,
Comparing Veritas FS against UFS is like comparing apples
and steak. Their goals are so diffent it is rediculous.
My comment is that with no apples-apples comparisons (or at
least apples-pears) who knows how good it is.
> which is good for their greatest hype - performance with databases
> (see all the marketing shredder-food about [Cached] QuickIO).
> They have hot resizing, which fast as hell (again, compared to UFS),
> they have snapshots, which are cool. And don't forget the GFS capability,
> which I am yet to see in action. [2]
>
> So in Solaris world, for large filesystems, Veritas is the winner. I am
> really looking forward to seeing how will they do in the OpenSource
> world.
Don't get me wrong, feature-wise Veritas FS is a great
product. Their hot resizing (including shrink) is a
must-have feature. I never had a lick of problems with it
despite flaky GbIX (Gibabit FCAL Interface transceivers).
> [1] Actually they benchmark Oracle on raw devices vs. Cached QuickIO, too.
> [2] Even tough the options are expensive, in my experience all of them
> work perfectly.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
>> So does Redhat/Suse/??? ship XFS yet?
>>
>> john
>>
>
>Mandrake has had XFS support in the default boot kernel since 8.0.
>AFAIK, Suse
>and Slackware also have XFS capable kernels now too.
for what its worth, MSC.Linux supports it on IA32 and IA64 :-)
In my opinion the non-inclosure in the mainline kernel is the most
important reason not to use XFS (or any other FS). Which in turn
massively reduces the tester base. It is a shame, because for some type
of applications it performs great, or better than anything else.
Martin
--
Martin Knoblauch
Senior System Architect
MSC.software GmbH
Am Moosfeld 13
D-81829 Muenchen, Germany
e-mail: [email protected]
http://www.mscsoftware.com
Phone/Fax: +49-89-431987-189 / -7189
Mobile: +49-174-3069245
>> > So does Redhat/Suse/??? ship XFS yet?
>>
>> Don't know about RedHat & others, but SuSE _does_ ship XFS.
>>
>
>
>I should probably keep out of the discussion and I am not presenting
>this as an argument for inclusion, but for an incomplete list of XFS
>users and distribution including it look here:
>
>
>http://oss.sgi.com/projects/xfs/xfs_users.html
>
>
>Steve
Steve,
[shameless plug to follow]
you may add MSC.linux (http://www.msclinux.com) to your list. We
support it since day one. Probably not a mainstream reference, but we
are working in an application field that can make good use of XFS.
[end of shamelse plug]
Your list of users is great, but without mainstream support its growth
will be severely limited.
OK, but I understand people are working to change that for 2.6 :-)
Cheers
Martin
--
Martin Knoblauch
Senior System Architect
MSC.software GmbH
Am Moosfeld 13
D-81829 Muenchen, Germany
e-mail: [email protected]
http://www.mscsoftware.com
Phone/Fax: +49-89-431987-189 / -7189
Mobile: +49-174-3069245
> In my opinion the non-inclosure in the mainline kernel is the most
> important reason not to use XFS (or any other FS). Which in turn
> massively reduces the tester base. It is a shame, because for some type
> of applications it performs great, or better than anything else.
On the other hand, filesystem corruption bugs are one of the worst type to suffer from. We absolutely don't want to include filesystems without at least a reasonable proven track record in the mainline kernel, and therefore encourage the various distributions to use them, incase any bugs do show up. Look how long a buffer overflow existed in Zlib unnoticed.
EXT2 is a very capable filesystem, and has *years* of proven reliability. That's why I'm not going to switch away from it for critical work any time soon.
John.
>> In my opinion the non-inclosure in the mainline kernel is the most
>> important reason not to use XFS (or any other FS). Which in turn
>> massively reduces the tester base. It is a shame, because for some
type
>> of applications it performs great, or better than anything else.
>
>
>On the other hand, filesystem corruption bugs are one of the worst type
>to suffer from. We absolutely don't want to include filesystems
>without at least a reasonable proven track record in the mainline
>kernel, and therefore encourage the various distributions to use them,
>incase any bugs do show up. Look how long a buffer overflow existed in
>Zlib unnoticed.
>
If enclosure in "major" distribuitons defines mainline for you, I have
to agree. Otherwise, how do you get "a proven track record in
mainline" without having it in the mainline kernel ? :-)
In any case, one could always mark XFS as "experimental" for some time.
>
>EXT2 is a very capable filesystem, and has *years* of proven
>reliability. That's why I'm not going to switch away from it for
>critical work any time soon.
sure, if you can live with the fsck time on your 200 GB (or bigger)
filesystem after the occasional crash.
Martin
--
Martin Knoblauch
Senior System Architect
MSC.software GmbH
Am Moosfeld 13
D-81829 Muenchen, Germany
e-mail: [email protected]
http://www.mscsoftware.com
Phone/Fax: +49-89-431987-189 / -7189
Mobile: +49-174-3069245
> >> In my opinion the non-inclosure in the mainline kernel is the most
> >> important reason not to use XFS (or any other FS). Which in turn
> >> massively reduces the tester base. It is a shame, because for some
> type
> >> of applications it performs great, or better than anything else.
> >
> >
> >On the other hand, filesystem corruption bugs are one of the worst type
> >to suffer from. We absolutely don't want to include filesystems
> >without at least a reasonable proven track record in the mainline
> >kernel, and therefore encourage the various distributions to use them,
> >incase any bugs do show up. Look how long a buffer overflow existed in
> >Zlib unnoticed.
>
> If enclosure in "major" distribuitons defines mainline for you, I have
> to agree. Otherwise, how do you get "a proven track record in
> mainline" without having it in the mainline kernel ? :-)
Sorry, I meant we should be wary about what is moved from being development code to non-development code in the stable kernel.
> In any case, one could always mark XFS as "experimental" for some time.
Exactly, I think we should.
The distributions will 'mirror' that, by including support, but not making it obvious unless you poke around looking for it - so it gets the new feature out to the more users, but doesn't present it as just another option for newbies to select without realising what they are doing.
> >EXT2 is a very capable filesystem, and has *years* of proven
> >reliability. That's why I'm not going to switch away from it for
> >critical work any time soon.
>
> sure, if you can live with the fsck time on your 200 GB (or bigger)
> filesystem after the occasional crash.
But Linux doesn't crash... :-)
John.
On Thu, 2002-09-12 at 16:53, [email protected] wrote:
> > In any case, one could always mark XFS as "experimental" for some time.
>
> Exactly, I think we should.
>
I disagree. Ask the people who are using it in anger (which I am) and I
think you'll find they don't think the code quality warants an
"experimental" tag.
>
> > >EXT2 is a very capable filesystem, and has *years* of proven
> > >reliability. That's why I'm not going to switch away from it for
> > >critical work any time soon.
> >
So does XFS. It just happens to be measured in IRIX years.
-tony
Hi,
On Thu, 12 Sep 2002 [email protected] wrote:
> But Linux doesn't crash... :-)
I'm running 2.4.19-rc5-aa1 on reiserfs on some twenty workstations,
neither of which ever crashed...
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
[email protected] wrote:
[...]
>> sure, if you can live with the fsck time on your 200 GB (or bigger)
>> filesystem after the occasional crash.
>
>But Linux doesn't crash... :-)
Just pull the power cable out of your PC and see what happens.
Bernd
--
Bernd Petrovitsch Email : [email protected]
g.a.m.s gmbh Fax : +43 1 205255-900
Prinz-Eugen-Stra?e 8 A-1040 Vienna/Austria/Europe
LUGA : http://www.luga.at
Quoting Thunder from the hill <[email protected]>:
> Hi,
>
> On Thu, 12 Sep 2002 [email protected] wrote:
> > But Linux doesn't crash... :-)
>
> I'm running 2.4.19-rc5-aa1 on reiserfs on some twenty workstations,
> neither of which ever crashed...
>
Alot of hosting companies employ the "pull the plug" method of solving problems.
This isnt good on non journaling filesystems. (It's not good period, but thats
not going to change anytime soon).
-------------------------------------------------
sent via KingsMeade secure webmail http://www.kingsmeadefarm.com
> > > sure, if you can live with the fsck time on your 200 GB (or bigger)
> > > filesystem after the occasional crash.
> > >
> > But Linux doesn't crash... :-)
> >
> Just pull the power cable out of your PC and see what happens.
OK, hang on a minute... Ah, here it is, right... OK, this is what happens, ready...
NO CARRIER
Hi,
On Thu, 12 Sep 2002, Joe Kellner wrote:
> Alot of hosting companies employ the "pull the plug" method of solving
> problems. This isnt good on non journaling filesystems. (It's not good
> period, but thats not going to change anytime soon).
I don't see where reiserfs isn't journaling.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
Hi,
On Thu, 12 Sep 2002, Bernd Petrovitsch wrote:
> >But Linux doesn't crash... :-)
>
> Just pull the power cable out of your PC and see what happens.
The UPS starts beeping.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
Quoting Thunder from the hill <[email protected]>:
> Hi,
>
>
> I don't see where reiserfs isn't journaling.
>
That was speaking of EXT2, not ReiserFS. Sorry for the confusion.
-------------------------------------------------
sent via KingsMeade secure webmail http://www.kingsmeadefarm.com
Hans Reiser wrote:
> Nick LeRoy wrote:
>
>>
>>
>>
>> Think about this: Namesys is working on Reiserfs v4.0. v4.0. Hell -
>> it's only been incorporated into the mainstream kernel for less than a
>> year (at least by my recollection), yet it keeps advancing. I have
>> _no_ idea what UFS version Solaris 8 is using (admittedly at least
>> somewhat due to ignorance -- I use Solaris because I have a good ol'
>> SPARCprinter which alas is not supported by Linux), or whether they've
>> bother to do development on it to make it better, faster, etc. Yet,
>> _we_ get this advancement all the time. Isn't it great?!
>>
>>
>>
> I think you'll really like v4, it is a complete rewrite from scratch,
> and far better in every way. :)
>
> Hans
What blows my mind (from someone that only watches kernel development)
is how one project, XFS, a filesystem basically "done" is excluded from
the mainline kernel while ReiserFS is getting a "complete rewrite from
scratch".
Maybe I don't get it cause I'm just watching... ;)
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
Bryan Whitehead writes:
> Hans Reiser wrote:
> > Nick LeRoy wrote:
> >
> >>
> >>
> >>
> >> Think about this: Namesys is working on Reiserfs v4.0. v4.0. Hell -
> >> it's only been incorporated into the mainstream kernel for less than a
> >> year (at least by my recollection), yet it keeps advancing. I have
> >> _no_ idea what UFS version Solaris 8 is using (admittedly at least
> >> somewhat due to ignorance -- I use Solaris because I have a good ol'
> >> SPARCprinter which alas is not supported by Linux), or whether they've
> >> bother to do development on it to make it better, faster, etc. Yet,
> >> _we_ get this advancement all the time. Isn't it great?!
> >>
> >>
> >>
> > I think you'll really like v4, it is a complete rewrite from scratch,
> > and far better in every way. :)
> >
> > Hans
>
> What blows my mind (from someone that only watches kernel development)
> is how one project, XFS, a filesystem basically "done" is excluded from
> the mainline kernel while ReiserFS is getting a "complete rewrite from
> scratch".
>
> Maybe I don't get it cause I'm just watching... ;)
Then you missed "reiserfs inclusion into the kernel" soap opera.
And besides, reiserfs in mainline to no extent means reiser4 in mainline
(unfortunately).
>
> --
> Bryan Whitehead
Nikita.
> SysAdmin - JPL - Interferometry Systems and Technology
> Phone: 818 354 2903
> [email protected]
>
Bryan Whitehead wrote:
>>
>
> What blows my mind (from someone that only watches kernel development)
> is how one project, XFS, a filesystem basically "done" is excluded
> from the mainline kernel while ReiserFS is getting a "complete rewrite
> from scratch".
>
> Maybe I don't get it cause I'm just watching... ;)
>
Keep in mind Linus ignored reiserfs for a long time and then just
merged it in. I think it was 2.4.1 or so.
> > > >EXT2 is a very capable filesystem, and has *years* of proven
> > > >reliability. That's why I'm not going to switch away from it for
> > > >critical work any time soon.
> So does XFS. It just happens to be measured in IRIX years.
Don't forget you're talking four megabytes of ported code.
By the way, just out of curiosity, would someone kindly have a go at
summarizing what's going on inside XFS that would justify its sources
being almost six times the size of reiserfs? I have read the XFS
feature list carefully, however, I still fail to see where the great
difference is.
T.
On Thu, 12 Sep 2002, Nikita Danilov wrote:
> Then you missed "reiserfs inclusion into the kernel" soap opera.
>
> And besides, reiserfs in mainline to no extent means reiser4 in mainline
> (unfortunately).
No, that's probably a good thing. I don't care how good any programming
team might be, an implementation written from scratch probably should burn
in for a while before going in anywhere it might be used for production.
And with all respect to the group, a 4th rewite from scratch in only a few
years suggests that the ratio of coding to designing is pretty high.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thu, 12 Sep 2002 [email protected] wrote:
> > In my opinion the non-inclosure in the mainline kernel is the most
> > important reason not to use XFS (or any other FS). Which in turn
> > massively reduces the tester base. It is a shame, because for some type
> > of applications it performs great, or better than anything else.
>
> On the other hand, filesystem corruption bugs are one of the worst type
> to suffer from. We absolutely don't want to include filesystems without
> at least a reasonable proven track record in the mainline kernel, and
> therefore encourage the various distributions to use them, incase any
> bugs do show up. Look how long a buffer overflow existed in Zlib
> unnoticed.
Given that the IDE code in 2.5 wrote random bad data not only in the
mounted filesystems but on other partitions and even drives, if we are
dropping things which have an unreasonable track record, we should drop
IDE for sure ;-)
This is a development kernel, the rules for what goes in should be far
more open than the stable series. IMHO both JFS (AIX) and XFS (IRIX)
should be in, because they will not be solid until users actually use
them, and better that be in a development kernel.
>
> EXT2 is a very capable filesystem, and has *years* of proven
> reliability. That's why I'm not going to switch away from it for
> critical work any time soon.
One might note that both JFS and XFS have been around since xiafs was the
Linux f/s of choice. It's all relative. If you want old and grotty, go
back to minix f/s.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> > > In my opinion the non-inclosure in the mainline kernel is the most
> > > important reason not to use XFS (or any other FS). Which in turn
> > > massively reduces the tester base. It is a shame, because for some type
> > > of applications it performs great, or better than anything else.
> >
>
> > On the other hand, filesystem corruption bugs are one of the worst type
> > to suffer from. We absolutely don't want to include filesystems without
> > at least a reasonable proven track record in the mainline kernel, and
> > therefore encourage the various distributions to use them, incase any
> > bugs do show up. Look how long a buffer overflow existed in Zlib
> > unnoticed.
>
> Given that the IDE code in 2.5 wrote random bad data not only in the
> mounted filesystems but on other partitions and even drives, if we are
> dropping things which have an unreasonable track record, we should drop
> IDE for sure ;-)
Things have certainly changed, (for better or worse, I'm not sure), since the 1.3.X days when a development kernel was generally still pretty stable.
> This is a development kernel, the rules for what goes in should be far
> more open than the stable series. IMHO both JFS (AIX) and XFS (IRIX)
> should be in, because they will not be solid until users actually use
> them, and better that be in a development kernel.
Totally agreed. I was talking about the stable kernel.
> > EXT2 is a very capable filesystem, and has *years* of proven
> > reliability. That's why I'm not going to switch away from it for
> > critical work any time soon.
>
> One might note that both JFS and XFS have been around since xiafs was the
> Linux f/s of choice.
Not for Linux, though - I'm talking about years of Linux stability.
> It's all relative. If you want old and grotty, go back to minix f/s.
That's why I qualified my above comment with 'is a very capable filesystem' :-).
I know what you mean, but I was just pointing out that EXT-2 balances proven reliability in the stable kernel, features, and performance VERY well, infact what other OS family can make that claim? BSD is the only one I can think of. Oh, sure FAT has been around forever, but it's somewhat lacking in the features department.
John.
On Fri, Sep 13, 2002 at 07:53:31AM -0400, Bill Davidsen wrote:
> This is a development kernel, the rules for what goes in should be far
> more open than the stable series. IMHO both JFS (AIX) and XFS (IRIX)
> should be in, because they will not be solid until users actually use
> them, and better that be in a development kernel.
JFS is in isnt it?
> One might note that both JFS and XFS have been around since xiafs was the
> Linux f/s of choice. It's all relative. If you want old and grotty, go
> back to minix f/s.
Ah, you remember xiafs. Perhaps the first big flamewar on the kernel
mailing list.
Jim