

Samsung Creates New File System F2FS For Linux, Good News For Android - mtgx
http://www.muktware.com/4485/samsung-creates-new-file-system-f2fs-linux-good-news-android

======
JonnieCache
Hopefully they'll do a better job than last time they tried this: the galaxy S
had a custom filesystem called RFS, in reality it was just fat32 with crappy
journaling bolted on. It totally crippled the phone, causing a lengthly block
every time a file was closed. It would also fight with the chips own wear
levelling algorithms. It sucked. If you owned that phone and thought it
sucked, with loads of UI lag, it was because of samsung's custom filesystem,
which was also supposedly optimised for NAND.

<http://forum.xda-developers.com/showthread.php?t=799931>

~~~
ntkachov
I owned that phone, it did suck.

The only good thing about that phone (besides the screen) is that it was
nearly unbreakable and had a great custom Rom scene. Almost all of the roms
replaced the file system.

~~~
pserwylo
And it still has a lot of custom rom support.

I'm writing from my Galaxy S with CM10 (Jellybean) now. Naturally, it uses Ext
(3?) partitions, and resizes the cache partition so I can download apps larger
than 30mb from the play store (another interesting file system choice from
Samsung).

~~~
richworks
I need to ask, what HN app are you using?

~~~
pserwylo
Just the <https://news.ycombinator.com> website.

I use the Opera labs browser. Opera, because despite some parts I don't like,
it's the best I've seen at reflowing text to fit the screen (perfect for HN).
The labs version, because it supports extensions, and it is the only way I can
get something like Ghostery to block trackers while I'm browsing on the phone.

Do you have a particular HN app you recommend?

I was using <http://ihackernews.com> for a while, because of its mobile-
friendly HTML, but it doesn't really offer anything in addition to regular HN
with a good browser. Double tapping zooms to a good size, reflows the text,
and snaps the scrolling to the new width, so most sites just feel like a
"mobile app" anyhow.

Cheers.

------
johansch
File systems are extremely fickle things requiring the utmost attention to
detail and quality. There is an impedance mismatch between that and most
people's image of Samsung-produced software.

~~~
randallu
I don't think that's a very reasonable thing to say. Samsung-LSI (which is the
"Samsung" in question here) consistently makes better BSPs than, say, TI or
nvidia (with their big WinCE-like layer inside the kernel).

Samsung Mobile has a reputation for making poor quality Android UIs (though
they also have a few other OS projects going on; the EFL one and something
else).

Also, Samsung-LSI generally makes better SoCs than the other guys (normally
the bus works properly, etc). If you wanted to pick on them in a constructive
way then you could say "I hope they clean up their mess in arch/arm..."

~~~
zobzu
You must not have looked at samsung's source for their recent flagship phones.

~~~
__alexs
Samsung-LSI is part of Samsung's semiconductor division, it has little to do
with the their consumer electronics section.

------
shuzchen
That's interesting, because every android device I've encountered (4-5
different models) have used YAFFS, which is also a NAND-friendly filesystem.
Anybody know what the difference is?

~~~
nuclear_eclipse
As far as I know, YAFFS is not a journaled filesystem, and is really just a
simple filesystem comparable in feature set to FAT32. F2FS looks like it's
trying to bring the features of EXT3 to a flash-friendly implementation.

~~~
cokernel_hacker
YAFFS is a log-structured filesystem, just like F2FS. Log-structuring gives
you a data organization protocol. This protocol gives you an implicit crash-
recovery story, there is no need for additional journaling on top of it.

Journalling is used when some blocks on the disk are scheduled to be
overwritten. Instead, the blocks are written in a separate location (the so-
called journal). At a later point in time, the data blocks get overwritten.
Once the data is safely on the disk (via Forced Unit Access (FUA) or a flush
track cache-type operation) we can then truncate the journal.

Log-structured systems do not do this. Instead, the achieve crash safety via
never overwriting data; they always write elsewhere (into something called
'the log'). Eventually, too much of this log is filled with garbage, stale
data. This is when 'cleaning' occurs. However, cleaning is expensive and slow.
You must read a large amount of data, figure out what is alive/dead, and then
write it all out.

F2FS's contribution to FS design seems to be handling this cleaning operation
in a more graceful manner.

~~~
sturadnidge
Possibly the most succinct explanation of log-structured vs journaling
filesystems I have ever read.

Thankyou.

------
jackowayed
Can anyone explain why a log-structured file system is a good fit for flash?
It seems that a lot of the benefits of an LFS are that it reduces disk seeks.

~~~
hristov
It has to do with the way flash does writes. In flash it actually takes longer
to overwrite a bit of data, than to write that bit on a 'blank', or previously
initialized cell.

Furthermore if you are going to overwrite something in flash it usually
behooves you to overwrite an entire block at a time. For these reasons flash
systems tend to try to often write changes in a log manner, wait for a lot of
changes to pile up and then incorporate those changes back into the original
by rewriting entire blocks. The log can be placed in an initialized section of
the memory where overwrites are not necessary.

~~~
Tuna-Fish
> Furthermore if you are going to overwrite something in flash it usually
> behooves you to overwrite an entire block at a time.

Well, all block devices are written a block at a time. The way flash differs
is that there are two internal block sizes -- called pages (4-8kB), and
eraseblocks (256kB-4MB).

There are two states a page can be in: clear, or used. You can write at a page
granularity, but only to clear pages. To clear used pages, you need to clear
the entire eraseblock at a time. Eraseblock sizes are now limited by
fundamental physical limits -- on every NAND node shrink from now, the
eraseblocks are going to double in size. And they are already really huge in
modern devices.

------
sigzero
Hopefully it works better than their legal team. /s

