Al Boldi wrote:
Chris Allen wrote:
Francois Barre wrote:
2006/6/23, PFC <lists@xxxxxxxxxx>:
- XFS is faster and fragments less, but make sure you have a
good UPS
Why a good UPS ? XFS has a good strong journal, I never had an issue
with it yet... And believe me, I did have some dirty things happening
here...
- ReiserFS 3.6 is mature and fast, too, you might consider it
- ext3 is slow if you have many files in one directory, but
has more
mature tools (resize, recovery etc)
XFS tools are kind of mature also. Online grow, dump, ...
I'd go with XFS or Reiser.
I'd go with XFS. But I may be kind of fanatic...
Strange that whatever the filesystem you get equal numbers of people
saying that they have never lost a single byte to those who have had
horrible corruption and would never touch it again. We stopped using XFS
about a year ago because we were getting kernel stack space panics under
heavy load over NFS. It looks like the time has come to give it another
try.
If you are keen on data integrity then don't touch any fs w/o data=ordered.
ext3 is still king wrt data=ordered, albeit slow.
Now XFS is fast, but doesn't support data=ordered. It seems that their
solution to the problem is to pass the burden onto hw by using barriers.
Maybe XFS can get away with this. Maybe.
Thanks!
--
When you refer to data=ordered are you taking about ext3 user data
journaling?
While user data journaling seems like a good idea is unclear as what
benefits it really provides?
By writing all user data twice the write performance of the files system
is effectively halved.
Granted the log is on area of the disk so some performance advantages
show up due
to less head seeking for those writes.
As far us meta data jornaling goes it is a fundamental requirement that
the journal is
synced to disk to a given point in order to release the pinned meta
data, thus allowing
the meta data to be synced to disk.
The way most files systems guarantee file system consistency is to
either sync all
outstanding meta data changes to disk or to sync a record of what incore
changes
have been made to disk.
In the XFS case since it logs meta data delta to the log it can record more
change operations in a smaller number of disk blocks, ext3 on the other hand
writes the entire metadata block to the log.
As far as barriers go I assume you are referring to the ide write barriers?
The need for barrier support in the file system is a result of cheap ide
disks providing large write caches but not having enough reserve power to
guarantee that the cache will be sync'ed to disk in the event of a power
failure.
Originally when xfs was written the disks/raids used by SGI system was
pretty
much exclusively enterprise level devices that would guarantee the write
caches
would be flushed in the event of a power failure.
Note ext3,xfs,and reiser all use write barrier now fos r ide disks.
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
