[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
On Thursday 28 November 2002 14:49, Pete Hatton wrote:
Quoting andy@xxxxxxxxxxxxxxxxxxxxxx:Aha... I think I might be putting a journaling filesystem on my home directory, the article says you don't need a journalised file system on read only filesystems (/usr /bin etc.) what about security updates, and installing new software, would I be better with a journalised file system everywhere, and would I notice a difference in performance against ext2fs (got an 850Hz Athalon, and fast ide hard drive).On /usr filesystems it's not updated that often. In this case the read performance should be the same whether it's ext2 or ext3. Howevever ext3 vs ext2 on a 5 year old P233-MMX box, i did spot a big difference in one case when using MySql. I had a 20meg 12,000 record database to import, whuich had a few fulltext indexes. On a ext2 it took about 3 minutes. On a ext3 system I gave up waiting (After 30mins)
ext3 has (IIRC) three modes and these are often poorly understood. Most journaling filesystems (caveat: the one I'm *really* familiar with is IBM's AIX JFS) just journal the filesystem metadata (the inode tables, bitmaps, directory blocks and suchlike) but not the data inside files. This isn't a bad compromise, really - most people can deal with losing uncommitted data when a machine crashes provided they don't lose files, and those that can't (because they're running transactions) install database software to sort that out (i.e. they effectively journal just the data they need journalled). The advantage of a JFS is that in the result of a power failure you're more-or-less guaranteed to be able to recover the filesystem metadata (although I have seen them fail in the past) and it's going to be much faster than using fsck because you don't need to analyse the metadata, just apply the updates. (fsck on some modern disks can take *days*.) ext3 is a piece of work ! It has 3 modes : Writeback - This works the way most JFSs work - it journals metadata updates, gives you reliable fsck functionality with very little overhead, and prevents you losing filesystems when the power goes. Ordered - extends that. Journals metadata, but doesn't apply it until the data has been written to the disk. More data integrity at the expense of efficiency, and you'll still lose some data when the lights go out, it's just that the files that you recover will have consistent data in them. Might not be the consistent data you *want*, but it will be consistent. Journal - journals data *and* metadata, and for large atomic updates (like importing a database !!) it'll be *horribly* inefficient. But it does *sound* nice, so I bet there are a lot of slow systems out there on desks... Default on this (RH8) system is Ordered. I think I may change that ... jd -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.