1 |
On Tue, Apr 23, 2013 at 11:39 PM, Hilco Wijbenga |
2 |
<hilco.wijbenga@×××××.com> wrote: |
3 |
> [...] So when I needed to install a |
4 |
> new machine, I looked around and settled on JFS. This box has been |
5 |
> running for about half a year now (so that includes several power |
6 |
> failures) without any problems. I certainly am very pleased with JFS |
7 |
> so perhaps you might want to consider it. |
8 |
|
9 |
|
10 |
I've also used (and still use) JFS on a lot of partitions (LVM |
11 |
actually), from my laptops (both rotating and SSD), desktop, VM's, |
12 |
etc. I've moved to it a few years ago after getting tired of all the |
13 |
Ext3 fsck's. |
14 |
|
15 |
Although JFS is quite "efficient", and didn't create too much |
16 |
trouble --- never lost an entire file-system, never corrupted data, |
17 |
etc. --- it does have a few quirks: |
18 |
|
19 |
* "empty files" after panics --- I think in this regard it's not |
20 |
JFS's fault, but actually badly written software, because things go |
21 |
like this: say you edit a file, save it, and immediately (a few |
22 |
seconds) get either a panic or power failure, the result is an empty |
23 |
file; the technical details are like this: some software first |
24 |
truncate the file, write to it, and close it, but don't sync the data, |
25 |
thus you end up with an empty file; as said I think JFS is correct |
26 |
here, because you don't get a mix of old and new data, etc.; however |
27 |
I've encountered this behavior in quite a few instances... |
28 |
|
29 |
* no TRIM support --- obviously really useful on SSD and |
30 |
virtualized disks; (although I remember there was some work done in |
31 |
this respect;) |
32 |
* not enough tooling --- you get only the `jfs-utils`, and that's |
33 |
kind of it... |
34 |
* small community --- if you have a question, you can use the |
35 |
mailing list, it's quite responsive, but there aren't many |
36 |
"data-points" so that you can easily find someone in a similar |
37 |
situation, thus with a solution... |
38 |
|
39 |
All in all, I've started gradually migrating my partitions on Ext4. |
40 |
|
41 |
|
42 |
I stay away for Btrfs for now. And to be frank I don't quite like |
43 |
Btrfs's, and ZFS's for that matter, approach of throwing together all |
44 |
the layers, from the file-system, to the RAID, to the block |
45 |
management, etc. I find the layered approach more appealing --- as in |
46 |
if something goes wrong you can poke around --- of having completely |
47 |
separated block device management (LVM), RAID (MD), and file-system. |
48 |
|
49 |
|
50 |
A... and for backup file-systems, I use Ext2. Why? My take on this is: |
51 |
* I don't need write or read performance; I don't mind long |
52 |
fsck's; (thus any file-system could fit in here, however see below;) |
53 |
* I do really need reliability and, most importantly, recovery in |
54 |
case s**t... |
55 |
|
56 |
Therefore Ext2 is a perfect match: |
57 |
* it is so old, that I guess by now most bugs have been found and squashed; |
58 |
* it is so old, that virtually any Linux (or Windows, FreeBSD, or |
59 |
most other knows OS's) are able to at least read it; |
60 |
* it is so old, that by now I bet there are countless recovery tools; |
61 |
* it is so simple (compared with others), that someone could just |
62 |
re-implement a reader for it, or recovery tools; |
63 |
|
64 |
Any feedback about the Ext2 for backups? (Hope I'm not wrong on this one...) |
65 |
|
66 |
Ciprian. |