FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-27-2010, 07:23 AM
Lisi
 
Default Linux filesystems was

On Tuesday 27 July 2010 08:10:15 Stan Hoeppner wrote:
> XFS which is superior to all other Linux filesystems.

Stan -

Have you the time to give a rationale for this?

I'm not in any way impugning your knowledge. But I am at the stage of
accepting the default that Lenny gives me, for no better reason than that the
developers chose it and it is there. It is time I understood better the
reasons for each file system. (I gave up Reiserfs because Reiser murdered
his wife - hardly a logical measure of how good his filesystem is!!)

Lisi


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007270823.05211.lisi.reisz@gmail.com">http://lists.debian.org/201007270823.05211.lisi.reisz@gmail.com
 
Old 07-27-2010, 08:51 AM
Stan Hoeppner
 
Default Linux filesystems was

Lisi put forth on 7/27/2010 2:23 AM:
> On Tuesday 27 July 2010 08:10:15 Stan Hoeppner wrote:
>> XFS which is superior to all other Linux filesystems.
>
> Stan -
>
> Have you the time to give a rationale for this?

Sure.

1. Best overall performance for most systems, large and small, and the FS
creation and mounting parameters are super configurable to match the system
hardware for best performance. One recent set of recent benchmarks
demonstrating so:
http://btrfs.boxacle.net/repository/raid/2010-04-14_2004/2.6.34-rc3/2.6.34-rc3.html

man mkfs.xfs
man mount

Older benchmarks:
http://www.debian-administration.org/articles/388
http://everything2.com/index.pl?node_id=1479435

In regard to this last benchmark, some(many?) of the default XFS filesystem
creation parameters and mounting parameters have changed. Note the testing
was performed in 2005. A lot changes in 5 years. Read all you can and ask
questions on the XFS mailing list before tweaking parameters based on what you
find in old forum posts and benchmarks such as this.

Guaranteed Rate I/O for streaming and other critical applications--unique to
XFS amongst all filesytems, ever, not just on Linux--this feature was born on
IRIX XFS for the broadcasting industry where video stutter was basically death
to a TV station or network such as CNN, CBS, etc. This single feature from
SGI allowed broadcast media to wholesale convert from tape to disk (this and
SGI FC storage arrays)

2. Commercial origin and backing. SGI is a fantastic technology compay:
http://oss.sgi.com/projects/xfs/

3. Maturity/history/longevity, IRIX birth in 1993, Linux birth 2001, included
in mainline in late 2003:
http://en.wikipedia.org/wiki/XFS
http://marc.info/?l=linux-kernel&m=107088371607817&w=2

4. Equal/superior user space toolset:
xfsprogs - includes online defragmentation tool xfs_fsr and online growth tool
xfs_growfs. No other stable Linux FS has an online defragmenter. Ext4 has
e4defrag but AFAIK it's not complete nor close to maturity or stability.
xfs_fsr has been both for a decade.

5. Very active developer community and thorough documentation:
http://xfs.org/index.php/Main_Page

> I'm not in any way impugning your knowledge. But I am at the stage of
> accepting the default that Lenny gives me, for no better reason than that the
> developers chose it and it is there. It is time I understood better the
> reasons for each file system. (I gave up Reiserfs because Reiser murdered
> his wife - hardly a logical measure of how good his filesystem is!!)

Debian will _always_ default to an EXT* filesystem--until the end of time.
Then again, I thought the same of LILO, so what do I know eh? But expert
install mode allows you whatever you want. I never cared for ReiserFS and
never used it. Hans actions are just further justification after the fact.

I've only used XFS on servers. I've never used it on laptops or desktops. I
know of many people who have, but they are die hard propeller heads and know
how to fix anything if/when it breaks. If you want to run XFS on a laptop or
desktop, especially on Debian, your only downside is going to be getting quick
help, if you get jammed, from folks on this list, or the community in general.
That process will probably not be as quick and fruitful as with EXT2/3
issues, simply because there are a lot less people using XFS, thus the pool of
helpers is much smaller.

If you're adventurous, take XFS for a spin. Partition a 100MB /boot and
install everything else on a big partition running XFS. And, learn the
utility set, and learn about XFS, just as you have (or should have) with
EXT2/3 and ReiserFS. As always, knowledge is power.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C4E9E29.4050702@hardwarefreak.com">http://lists.debian.org/4C4E9E29.4050702@hardwarefreak.com
 
Old 07-27-2010, 01:09 PM
Kelly Clowers
 
Default Linux filesystems was

On Tue, Jul 27, 2010 at 01:51, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>
> Debian will _always_ default to an EXT* filesystem--until the end of time.

Nope, btrfs will replace ext3/4 as default soon enough.


Cheers,
Kelly Clowers


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTi=HGrOM682LBGMYPx44uqJ2Dg25jWXzhiVVAMZr@mail .gmail.com">http://lists.debian.org/AANLkTi=HGrOM682LBGMYPx44uqJ2Dg25jWXzhiVVAMZr@mail .gmail.com
 
Old 07-27-2010, 01:22 PM
Volkan YAZICI
 
Default Linux filesystems was

On Tue, 27 Jul 2010, Stan Hoeppner <stan@hardwarefreak.com> writes:
> 1. Best overall performance for most systems, large and small, and the FS
> creation and mounting parameters are super configurable to match the system
> hardware for best performance. One recent set of recent benchmarks
> demonstrating so:
> http://btrfs.boxacle.net/repository/raid/2010-04-14_2004/2.6.34-rc3/2.6.34-rc3.html
>
> man mkfs.xfs
> man mount
>
> Older benchmarks:
> http://www.debian-administration.org/articles/388
> http://everything2.com/index.pl?node_id=1479435
>
> In regard to this last benchmark, some(many?) of the default XFS filesystem
> creation parameters and mounting parameters have changed. Note the testing
> was performed in 2005. A lot changes in 5 years. Read all you can and ask
> questions on the XFS mailing list before tweaking parameters based on what you
> find in old forum posts and benchmarks such as this.
>
> Guaranteed Rate I/O for streaming and other critical applications--unique to
> XFS amongst all filesytems, ever, not just on Linux--this feature was born on
> IRIX XFS for the broadcasting industry where video stutter was basically death
> to a TV station or network such as CNN, CBS, etc. This single feature from
> SGI allowed broadcast media to wholesale convert from tape to disk (this and
> SGI FC storage arrays)
>
> 2. Commercial origin and backing. SGI is a fantastic technology compay:
> http://oss.sgi.com/projects/xfs/
>
> 3. Maturity/history/longevity, IRIX birth in 1993, Linux birth 2001, included
> in mainline in late 2003:
> http://en.wikipedia.org/wiki/XFS
> http://marc.info/?l=linux-kernel&m=107088371607817&w=2
>
> 4. Equal/superior user space toolset:
> xfsprogs - includes online defragmentation tool xfs_fsr and online growth tool
> xfs_growfs. No other stable Linux FS has an online defragmenter. Ext4 has
> e4defrag but AFAIK it's not complete nor close to maturity or stability.
> xfs_fsr has been both for a decade.
>
> 5. Very active developer community and thorough documentation:
> http://xfs.org/index.php/Main_Page

You are missing a very important point: Durability to power failures.
(Excuse me, but a majority of GNU/Linux users are not switched to a UPS
or something.) And that's where XFS totally fails[1][2]. And considering
my personal experiences, reiserfs is the fastest fs (among ext3 and xfs)
in terms of boot recovery phase times.


Regards.

[1] http://linux.derkeiler.com/Mailing-Lists/Debian/2008-11/msg00097.html
[2] http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files _after_recovery_when_I_unplugged_the_power.3F


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87bp9tuki8.fsf@alamut.alborz.net">http://lists.debian.org/87bp9tuki8.fsf@alamut.alborz.net
 
Old 07-27-2010, 02:43 PM
Aniruddha
 
Default Linux filesystems was

On Tue, Jul 27, 2010 at 3:22 PM, Volkan YAZICI <yazicivo@ttmail.com> wrote:



You are missing a very important point: Durability to power failures.

(Excuse me, but a majority of GNU/Linux users are not switched to a UPS

or something.) And that's where XFS totally fails[1][2].*

Ext3 has the same problems when not*properly*configured:
Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.
http://en.wikipedia.org/wiki/Ext3#No_checksumming_in_journal
For the record I use ext3, I*remember*XFS as not being reliable enough (with*power*failures etc).*
 
Old 07-27-2010, 03:41 PM
Aaron Toponce
 
Default Linux filesystems was

On 7/27/2010 1:23 AM, Lisi wrote:
> On Tuesday 27 July 2010 08:10:15 Stan Hoeppner wrote:
>> XFS which is superior to all other Linux filesystems.
>
> Stan -
>
> Have you the time to give a rationale for this?

Except XFS filesystems can't shrink, only grow. Sucks when you need to
resize partitions/volumes, and they're all XFS.

Further, XFS makes more system calls to the kernel than standard
Ext2/3/4. Export an XFS filesystem on LVM over NFS, and you'll get a
kernel oops on a 32-bit kernel. Trace it, and you'll see the plethora of
nested system calls XFS makes. You won't oops with Ext2/3/4 in the same
scenario. This can be mitigated by running a 64-bit system, if you have
the hardware to do so.

XFS has also had a history for randomly corrupting data. While this
might have improved over time, I don't trust it.

XFS does have dynamic inode allocation, and better data storage
algorithms than the Ext-family. It's also a good performer, but Ext4
give XFS a run for its money.

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O
 
Old 07-27-2010, 04:19 PM
Stan Hoeppner
 
Default Linux filesystems was

Volkan YAZICI put forth on 7/27/2010 8:22 AM:

> You are missing a very important point: Durability to power failures.
> (Excuse me, but a majority of GNU/Linux users are not switched to a UPS
> or something.) And that's where XFS totally fails[1][2].

> [1] http://linux.derkeiler.com/Mailing-Lists/Debian/2008-11/msg00097.html

1. Never quote forum or email posts as empirical or reliable evidence of
anything. They are opinion, unless they quote fact from reliable sources to
back that opinion (which I did in my original post). There are of course
exceptions to this rule of thumb, the main one being when the post is made by
a developer who is a recognized authority on the piece of software being
discussed. In the case of XFS this would be Dave Chinner, Alex Elder, Eric
Sandeen, Christoph Hellwig, and others. In the case of EXT2/3/4 this would be
Ted Tso, who happens, BTW, to work hand in hand with the XFS developers
because they rely on each others patches to other parts of the Linux kernel.
Not the last two entries:
https://kerneltrap.org/mailarchive/linux-fsdevel/2010/7/16/expand

In the case of Postfix this would be Wietse Venema and Viktor Duchovni. In
the case of Linux this would be Linus Torvalds, Marcelo Tosatti, Alan Cox,
Andrew Morton and others. Etc.

2. If you are going to quote opinions from unreliable sources, at least read
the entire thread before quoting it. In this case, again, your source
contradicts what you state, and then, oddly, himself:

"PS. Apparently they've improved some power-failure problems with XFS
since I used it, but then they also said that *before* I started using
it so I can't say I'd put any trust in that."

Aneurin Price admits he is aware of new changes that fix the problem, but then
discounts the fact and gives an anecdotal story as to why the fix isn't really
a fix.


> [2]
http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files _after_recovery_when_I_unplugged_the_power.3F

You didn't even read the information you linked to, which contradicts what you
state: The fix for this issue has been in mainline since May 2007, over 3
years ago.

"Q: Why do I see binary NULLS in some files after recovery when I unplugged
the power?

Update: This issue has been addressed with a CVS fix on the 29th March 2007
and merged into mainline on 8th May 2007 for 2.6.22-rc1."

> And considering
> my personal experiences, reiserfs is the fastest fs (among ext3 and xfs)
> in terms of boot recovery phase times.

So, given that XFS recovery of any size filesystem is less than one second,
reiserfs recovery is so much less than 1 second that you notice the
difference? From:
http://www.enterprisenetworkingplanet.com/netos/article.php/623661/XFS-Its-worth-the-wait.htm

"XFS also provides file system journaling. This means that XFS uses database
recovery techniques to recover a consistent file system state after a system
crash. Using journaling, XFS is able to accomplish this recovery in under a
second, regardless of the file system size."

> [1] http://linux.derkeiler.com/Mailing-Lists/Debian/2008-11/msg00097.html

Here you quoted misinformation, because the opinions were based on experience
the OPs had with the software before it was patched to fix the problem, i.e.
more than 3 years ago. You treated this as empirical evidence in your
argument against XFS. I have shown this to be incorrect.

> [2] http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files _after_recovery_when_I_unplugged_the_power.3F

You quoted this FAQ item solely based on the tile, without reading it, in your
effort to denounce XFS. The article clearly states the problem was fixed over
3 years ago, which you conveniently ignored.

>From now on, please get your facts straight, with proper documentation, before
trying to denounce a fantastic piece of FOSS into which many top-of-their-game
kernel engineers have put tens of thousands of man hours, striving to make it
the best it can be--and are wildly succeeding.

Join the xfs mailing list and you might learn something useful in place of
this trash you're talking about it. Better yet, read what Hans Reiser had to
say about XFS. He was totally enamored with it, and wanted to duplicate many
of its features:

http://www.osnews.com/story/69

Hans Reiser:
"XFS is an excellent file system, and there is an important area where XFS is
higher performance than we are...ReiserFS does a complete tree traversal for
every 4k block it writes, and then it inserts one pointer at a time into the
tree, which means that every 4k write incurs the overhead of a balancing of
the tree (which means it moves data around). For this reason, XFS has better
very large file performance...If you want to stream multi-media data for
Hollywood style applications, or use ACLs now rather than wait for Reiser4,
you might want to use XFS."

"This is an area we are still experimenting with. We currently do what ext2
does, and preallocate blocks. What XFS does is much better, they allocate
blocknrs to blocks at the time they are flushed to disk, and this allows a
much more efficient and optimal allocation to occur. We knew we couldn't do it
the XFS way...but reiser4 is being built around delayed allocation, and I'd
like to thank the XFS developers for taking the time to personally explain to
me why delayed allocation is the way to go."

--
Stan



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C4F0705.2050005@hardwarefreak.com">http://lists.debian.org/4C4F0705.2050005@hardwarefreak.com
 
Old 07-27-2010, 04:31 PM
Lisi
 
Default Linux filesystems was

On Tuesday 27 July 2010 09:51:53 Stan Hoeppner wrote:
> Lisi put forth on 7/27/2010 2:23 AM:
> > On Tuesday 27 July 2010 08:10:15 Stan Hoeppner wrote:
> >> XFS which is superior to all other Linux filesystems.
> >
> > Stan -
> >
> > Have you the time to give a rationale for this?
>
> Sure.

Thanks, Stan, for a lucid and erudite exposition. Much appreciated.

Lisi


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007271731.34069.lisi.reisz@gmail.com">http://lists.debian.org/201007271731.34069.lisi.reisz@gmail.com
 
Old 07-27-2010, 05:03 PM
Aniruddha
 
Default Linux filesystems was

On Tue, Jul 27, 2010 at 6:19 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:

Volkan YAZICI put forth on 7/27/2010 8:22 AM:



> You are missing a very important point: Durability to power failures.

> (Excuse me, but a majority of GNU/Linux users are not switched to a UPS

> or something.) And that's where XFS totally fails[1][2].



> [1] http://linux.derkeiler.com/Mailing-Lists/Debian/2008-11/msg00097.html


....*
*a fantastic piece of FOSS into which many top-of-their-game

kernel engineers have put tens of thousands of man hours, striving to make it

the best it can be--and are wildly succeeding.

That's was very*informative, thanks. You got me curious and I will test XFS on my home system. To be honest I am still *little wary of using XFS in a production*environment. For years now I have heard stories of power failures with catastrophic results when using XFS. Anyone who using XFS in a*mission*critical production*environment? Anyone has*experience*with*that?*
 
Old 07-27-2010, 05:19 PM
Volkan YAZICI
 
Default Linux filesystems was

On Tue, 27 Jul 2010, Stan Hoeppner <stan@hardwarefreak.com> writes:
> Volkan YAZICI put forth on 7/27/2010 8:22 AM:
> 1. Never quote forum or email posts as empirical or reliable evidence of
> anything.

You're right, my bad.

> You quoted this FAQ item solely based on the tile, without reading it,
> in your effort to denounce XFS. The article clearly states the problem
> was fixed over 3 years ago, which you conveniently ignored.

I read the very same sentence, but AFAIK, default kernel for xfs bundled
with lenny doesn't have that fix.

> From now on, please get your facts straight, with proper
> documentation, before trying to denounce a fantastic piece of FOSS
> into which many top-of-their-game kernel engineers have put tens of
> thousands of man hours, striving to make it the best it can be--and
> are wildly succeeding.
>
> Join the xfs mailing list and you might learn something useful in
> place of this trash you're talking about it.

About a year ago, in a similar rush to yours, I ported two of our
PostgreSQL database servers to XFS. During testing period, I even
couldn't *recover* the / fs after the very first power failure test.
Whole testing period took 1 week and the result was negative. This is my
experience with XFS, and not much more thrash than your technical
knowledge. And instead of being a technology zealot, you'd be better put
forward some real world case scenarios. Try unplugging your xfs machineS
that many timeS, and let's discuss this topic again. Yep, my findings
might be deprecated, but I don't know any others investigating the same
subject with recent versions.

BTW, I still couldn't understand your temper and rudeness. I just share
my experience, and try it, it works.


Regards.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sk34u9j7.fsf@alamut.alborz.net">http://lists.debian.org/87sk34u9j7.fsf@alamut.alborz.net
 

Thread Tools




All times are GMT. The time now is 09:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org