Richard Freeman on 22 Oct 2010 17:41:54 -0700 |
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 disks. Rich ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|