1 |
On Thu, Apr 1, 2010 at 10:09 PM, <meino.cramer@×××.de> wrote: |
2 |
> [ ... snip ... ] |
3 |
> |
4 |
> So I have a lot of docs (specs of microcontrollers, howtos, programm |
5 |
> and source code docs...etc) on my disk. |
6 |
> This one part. |
7 |
|
8 |
|
9 |
I've seen that nobody mentioned JFS yet... :) |
10 |
|
11 |
In some benchmarks the best FS for most tasks is either XFS and |
12 |
JFS, but it seems that JFS has less CPU and memory usage. So for small |
13 |
and medium files I would say it's best. (I think it was on Tom's |
14 |
Hardware site?) |
15 |
|
16 |
I'll also describe my history on the issue: initially I've only |
17 |
used ReiserFS until something (not the hard drive) just snapped and |
18 |
I've almost lost all my data. At that moment I've migrated to Ext3. |
19 |
|
20 |
But Ext3 has the problem of needing constant (usually once a moth) |
21 |
checking (I know this is optional or tunable but it seems it is |
22 |
recommended) which for large file systems takes incredibly long (60GB |
23 |
HDD takes about 2 or 3 minutes... So imagine what would to to 1TB...) |
24 |
|
25 |
So I got angry again and moved to JFS... And I'm using JFS for |
26 |
about two years without major incidents... (Only once I've lost the |
27 |
contents of a configuration file due to a power interruption but this |
28 |
is because of the editor.) |
29 |
|
30 |
So as a conclusion for this task I would recommend JFS (I also |
31 |
have 200GB of documentation which covers about 100 thousand files I |
32 |
guess.) |
33 |
|
34 |
Also see at the end for my notes on journaled file systems. |
35 |
|
36 |
|
37 |
> Then: I often transer videos from my DVB-T-receiver/recorder to my |
38 |
> harddisk to cut out the advertising and to transcode the videos to |
39 |
> somethings better than "ts" (transport streams), |
40 |
> This is another part. |
41 |
|
42 |
|
43 |
Although JFS could handle this, maybe a file system specially |
44 |
designed for this would do best: Ext4 with it's extent feature. (But |
45 |
be aware that by just using a file system is not enough... The |
46 |
software also has to be specially crafted if you want high |
47 |
performance. Just see the `fallocate` and `fadvise` system calls.) |
48 |
|
49 |
|
50 |
> Then I plan to have two roots this time: One to experiment with and |
51 |
> one "good and stable"-version which is used/updated/... "strictly as |
52 |
> recommended". Filesizes and usage do vary here...take a look at your |
53 |
> own roots ;))) |
54 |
|
55 |
|
56 |
:) This sounds like my setup: 160GB HDD from my laptop has the |
57 |
following layout: |
58 |
* GPT partition table (not MBR) -- this gives me more partitions |
59 |
without needing the "extended" partition feature of MBR; |
60 |
* 2 boot partitions of 512MB (maybe 1GB would have been better) -- |
61 |
one for current usage (Grub 0.97 with GPT patches) and one for |
62 |
experimentation; these are Ext2 for safety and compatibility; |
63 |
* 3 root partitions of 4GB (I should have made them 8GB) -- one |
64 |
for the current operating system, and two for future upgrades / |
65 |
experimentation; currently JFS and maybe also so in the future; |
66 |
* 1 swap of 8GB (encrypted with random password with the help of dm-crypt); |
67 |
* rest of the HDD as one big partition with LVM; (large extents 256MB); |
68 |
* from the LVM I have partitions for personal data (/home) and |
69 |
other things -- everything is JFS; |
70 |
|
71 |
|
72 |
> Then I want something encrypted, either as a partition or as a files |
73 |
> (carrying a encrypted fs), which I can copy to dvd and will be able |
74 |
> to mount this dvd and use it without to have to copy the whole dvd |
75 |
> first to harddisk before using it... |
76 |
> Currently I am using encfs...(outdated?). What can I do use instead? |
77 |
> This is for personal things like letters, photos, texts ... etc. |
78 |
> Files vary from some kb up to about 2GByte (guessed). Most of them |
79 |
> smaller than 200MByte |
80 |
|
81 |
|
82 |
As someone noted maybe EncryptFS (in kernel one) would be |
83 |
better... (It's an install option in Ubuntu so I would say it's mature |
84 |
enough.) |
85 |
|
86 |
But for this encrypted purpose I would use dm-crypt with |
87 |
`aes-xts-essiv:sha256` encryption. (In the past I've used LoopAES but |
88 |
I had some minor issues with kernel building as it's not in the |
89 |
vanilla kernel...) |
90 |
|
91 |
|
92 |
> Last thing: I have a lot iof copies of code from svn repositories because |
93 |
> I like to have the "bleeding edge" of some projects (do you know the |
94 |
> new Blender 2.50??? :O) |
95 |
|
96 |
|
97 |
I also have a lot of repositories on JFS and everything works nice. |
98 |
|
99 |
|
100 |
> This implies a lot of compile work. This will be the only case where |
101 |
> files are created as often as read. |
102 |
|
103 |
|
104 |
For temporary folders while compiling I would recommend to |
105 |
instruct your build scripts to build inside /tmp where you have tmpfs |
106 |
mounted... It's blazingly fast... |
107 |
|
108 |
|
109 |
And some notes about journaled file systems: they journal |
110 |
meta-data (that is file creation, deletion, rename, etc), not data |
111 |
(that is the contents)... (Of course there are a few (Ext3 maybe?) |
112 |
file systems that have the option to also journal data...) |
113 |
|
114 |
What does this mean: well when you edit a file and save it and |
115 |
then cut the power, the file still exists (the meta-data), but the |
116 |
contents could (and usually is) wrong: either no content (like I've |
117 |
encountered once with JFS), either mixed content (old and new)... |
118 |
|
119 |
So the fineprint here is: no journaled file system is safe... They |
120 |
are all safe if you also use fsync (which forces everything to go on |
121 |
disk)... This is why I say that the fault for the file content lost is |
122 |
from the editor: |
123 |
* it opened the file by truncating it => 0 length; |
124 |
* it wrote to it and closed it; |
125 |
* it DIDN'T `fsync`-ed it which means that the data still remained |
126 |
in the buffer cache; |
127 |
* and when the power was lost so was the data in the buffer cache; |
128 |
|
129 |
Another fine-print about file system performance -- memory helps a |
130 |
lot... I've upgraded my laptop from 2GB to 4GB of RAM and with some |
131 |
fine-tuning the file operations are more snappier... The fine-tuning |
132 |
included delaying the write-back to about 3 minutes or until 1GB of |
133 |
data is dirty... Which means that if my laptop loses power or I need |
134 |
to hard power-off it I'll lose a great deal of data... |
135 |
|
136 |
Hope I was of some help, |
137 |
Ciprian. |
138 |
|
139 |
P.S.: The following link could give you some insight on the |
140 |
journaled file system problems (not only about ReiserFS) |
141 |
http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc |