Fwd: file systems

2011-04-21 Thread Heddle Weaver
Sorry. This one should have gone to the list also.

-- Forwarded message --
From: Heddle Weaver weaver2wo...@gmail.com
Date: 21 April 2011 22:13
Subject: Re: file systems
To: Stan Hoeppner s...@hardwarefreak.com




On 20 April 2011 19:57, Stan Hoeppner s...@hardwarefreak.com wrote:

 Heddle Weaver put forth on 4/19/2011 6:58 PM:

  XFS is excellent for large file sizes - graphics, music, videos, etc, but
  ext3/4 are better for a range of file sizes and therefore better for a

 This is simply not true.  Modern XFS is just as performant with small
 files as EXT3/4, especially with multiuser or highly parallel workloads.
  EXTx traditionally has had two advantages over XFS:

 1.  Workloads with zero or low parallelism
 2.  Metadata write heavy operations

 The first typically holds true for many single threaded workloads.
 That's fine.  XFS was designed for single threaded workloads, but high
 bandwidth multithreaded workloads.

 The second evaporated when Dave Chinner introduced delayed logging last
 year.  Today XFS metadata operations are on par with all Linux
 filesystems, and surpass all others with many workloads.

 Apparently you've not used XFS for maildir storage.  It's throughput is
 quite a bit better than EXT3/4.  Based on the file types you mention
 above, it would appear you are strictly a desktop Linux user.  This
 would explain your lack of knowledge of XFS and your penchant for
 repeating misinformation.  It would also explain and your preference for
 EXTx.

  smaller operation, which is what the O.P. seems to be describing.

 XFS is just as applicable to a small operation as a large one.  For
 instance, it is the premier filesystem used in building MythTV servers.
  A DVR is a pretty small operation.  XFS is the only Linux filesystem
 with a defrag utility, and an online one at that.  This is beneficial to
 all operations, regardless of size.  XFS has a far richer set of
 management tools than any other Linux filesystem.

 You simply can't go wrong with XFS on any size server, assuming you
 first read the basic documentation and the XFS FAQ.

  In case of
  mishap, they fall back to ext2.

 I'm not sure exactly what you mean by this.  I doubt you are either.

*http://tinyurl.com/3tu3ww9

*And this example is somewhat dated, but illustrates one such instance:*

**http://tinyurl.com/3qjtj82

*

 What kind of mishap would require converting the EXT3/4 filesystem
 back to EXT2?

  Performance is trivial, as any file system can be tuned.

 This statement clearly demonstrates your lack of filesystem architecture
 knowledge.


I've done it a number of times. No lack of knowledge in this regard at all.
You might have to reassess this one as well.


  Just as you can't tune a Ford Pinto to outrun a Ferrari, you
 can't tune EXTx to outperform XFS in highly parallel workloads.


That particular parallel simply doesn't work. Cars?

Your religious fervor does you credit, but beware of crucifixion. Yours and
others.
Regards,

Weaver.
-- 

Religion is regarded by the common people as true,
by the wise as false,
and by the rulers as useful.

— Lucius Annæus Seneca.

Terrorism, the new religion.





-- 

Religion is regarded by the common people as true,
by the wise as false,
and by the rulers as useful.

— Lucius Annæus Seneca.

Terrorism, the new religion.


Re: Fwd: file systems

2011-04-21 Thread Andrew McGlashan

Hi,

Heddle Weaver wrote:

*http://tinyurl.com/3tu3ww9


That's a pretty old reference, but an interesting read.

Important note:
These tests were done with a 2.4 kernel. They should be repeated to see 
if they still apply with modern 2.6.18+ kernels in use today.




*And this example is somewhat dated, but illustrates one such instance:*

**http://tinyurl.com/3qjtj82


That's pretty old too but to me seems much less worthwhile reading.

In any case, I would say that both of those references are too old to be 
of much real use to any argument today.


--
Kind Regards
AndrewM

Andrew McGlashan
Broadband Solutions now including VoIP


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4db04070.1030...@affinityvision.com.au