1 |
Hi, |
2 |
|
3 |
thank you very much for detailed review :) |
4 |
|
5 |
On Sat, 23 Jan 2016 20:13:33 -0500 Rich Freeman wrote: |
6 |
> > c) F2FS looks very interesting, it has really good flash-oriented |
7 |
> > design [3]. Also it seems to beat EXT4 on PCIe SSD ([3] chapter |
8 |
> > 3.2.2, pages 9-10) and everything other on compile test ([2] page 5) |
9 |
> > which should be close to the type of workload I'm interested in |
10 |
> > (though all tests in [2] have extra raid layer). The only thing |
11 |
> > that bothers me is some data loss reports for F2FS found on the |
12 |
> > net, though all I found is dated back 2012-2014 and F2FS have fsck |
13 |
> > tool now, thus it should be more reliable these days. |
14 |
> |
15 |
> So, F2FS is of course very promising on flash. It should be the most |
16 |
> efficient solution in terms of even wear of your drive. I'd think |
17 |
> that lots of short-term files like compiling would actually be a good |
18 |
> use case for it, Since discarded files don't need to be rewritten when |
19 |
> it rolls over. But, I won't argue with the benchmarks. |
20 |
> |
21 |
> It probably will improve as well as it matures. However, it isn't |
22 |
> nearly as mature as ext4 or xfs, so from a data-integrity standpoint |
23 |
> you're definitely at higher risk. If you're regularly backing up and |
24 |
> don't care about a very low risk of problems, It is probably a good |
25 |
> choice. |
26 |
|
27 |
I'll try to start with f2fs. If I'll have too much troubles with |
28 |
it, I'll fall back to ext4. Probably this is the best course of |
29 |
action now. |
30 |
|
31 |
It seems that f2fs is very active at development, they recently |
32 |
implemented the same ioctl() as ext4 for the native filesystem |
33 |
ecryption. While this is definitely not so well tested code, it is |
34 |
very promising. |
35 |
|
36 |
> > P.S. Is aligning to erase block size really important for NVMe? I |
37 |
> > can't find erase block size for this drive (Samsung MZ-VKV512) |
38 |
> > neither in official docs nor on the net... |
39 |
> |
40 |
> Unless the erase blocks are a single sector in size then I'd think |
41 |
> that alignment would matter. Now, for F2FS alignment probably matters |
42 |
> far less than other filesystems since the only blocks on the entire |
43 |
> drive that may potentially be partially erased are the ones that |
44 |
> border two log regions. F2FS just writes each block in a region once, |
45 |
> and then trims and entire contiguous region when it fills the previous |
46 |
> region up. Large contiguous trims with individual blocks being |
47 |
> written once are basically a best-case for flash, which is of course |
48 |
> why it works that way. You should still ensure it is aligned, but not |
49 |
> much will happen if it isn't I'd think. |
50 |
> |
51 |
> For something like ext4 where blocks are constantly overwritten I'd |
52 |
> think that poor alignment is going to really hurt your performance. |
53 |
> Btrfs might be somewhere in-between - it doesn't overwrite data in |
54 |
> place, but it does write all over the disk so it would be constantly |
55 |
> be hitting erase block borders if not aligned. That is just a |
56 |
> hand-waving argument - I have no idea how they work in practice. |
57 |
|
58 |
Is there any way to find erase block size aside from flashbench? |
59 |
I'll probably write Samsung support with data request as well, but |
60 |
I doubt they'll give me any useful information. |
61 |
|
62 |
Best regards, |
63 |
Andrew Savchenko |