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