| 1 |
On 7/20/06, Cliff Wells <cliff@×××××××.com> wrote: |
| 2 |
> Well, the other "well-known" bit of info is that ext3 gets much of its |
| 3 |
> "reliability" from syncing every 5 seconds. If you want to use XFS and |
| 4 |
> get that sort of data reliability, here's a bash script to add to |
| 5 |
> rc.local: |
| 6 |
> |
| 7 |
> ( while true; do sync; sleep 5; done )& |
| 8 |
|
| 9 |
Well, you laugh, but my /etc/sysctl.conf contains: |
| 10 |
|
| 11 |
vm.laptop_mode = 0 |
| 12 |
fs.xfs.xfssyncd_centisecs = 500 |
| 13 |
|
| 14 |
> You can also mount XFS in sync mode if you are paranoid, but be warned |
| 15 |
> that it keeps your disks *very* busy. |
| 16 |
|
| 17 |
Yeah. I would rather use ext3 with data=journal! |
| 18 |
|
| 19 |
> So I guess the real question is this: what qualifies as "FS |
| 20 |
> reliability". |
| 21 |
|
| 22 |
Right. "Sucks" is imprecise in most circles. |
| 23 |
|
| 24 |
But consider this...the entire value of a filesystem is the files it |
| 25 |
contains. A filesystem that fixes itself by doing the equivalent of |
| 26 |
"mkfs" on reboot from a crash will be both completely consistent, and |
| 27 |
completely useless. By anyone's definition, it would "suck". |
| 28 |
|
| 29 |
> cross-linked files and bad inode counts). Also, having to fsck a large |
| 30 |
> disk array is going to be quite painful. |
| 31 |
|
| 32 |
Yes, ext3 maintainers are well aware of this. Have you seen: |
| 33 |
|
| 34 |
http://infohost.nmt.edu/~val/fs_workshop/ |
| 35 |
|
| 36 |
And the lwn article: |
| 37 |
http://lwn.net/Articles/189547/ |
| 38 |
|
| 39 |
-Richard |
| 40 |
-- |
| 41 |
gentoo-user@g.o mailing list |
Archives