Richard Freeman on 22 Oct 2010 17:41:54 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Recent Linux file system benchmarks

On 10/22/2010 04:55 PM, Claude M. Schrader wrote:
> Oracle, for example, can be pointed at a raw disk. It will then format the
> disk and create the DB files on top of its own format. It's supposed to
> be more efficient, since it removes one layer of caching I believe.

This makes sense since the application already provides fully ACID
transactions/etc and so anything the filesystem tries to do for data
protection on top of that is just extra redundancy.  Plus, the app would
be forced to sync everything anyway to guarantee its own ability to
rollback/etc, so the filesystem layer just adds overhead.

If anything filesystems need to catch up to good databases - they're
already way ahead in terms of data protection.

I still haven't gotten a chance to read the original article but I'm
looking forward to it.  It doesn't surprise me to hear that btrfs has
some performance issues.  First, it is still pretty new and therefore
not well-optimized.  Second, it is COW, which means that it is going to
be slower at some things other filesystems do quickly, and faster at
other things that filesystems do slowly.  If you had snapshotting turned
on at the filesystem (or lower) layer and used btrfs snapshotting you'd
probably find that btrfs would actually go faster than without
snapshotting, and just about anything else would go way slower.
Snapshotting is essentially free (actually, negative cost) with COW.

I'm hoping to get enough life out of my current RAID that my next data
migration will be to btrfs.  I wouldn't do it yet, but maybe in a year
it will be ready.  It would be nice if they added a stripe+parity option
- right now it only does mirroring which of course is wasteful with many

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --