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

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.

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).

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

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.

And yet after a year, normal usage cracked the screen (weak point surround the front button.)

YMMV? Mine has been used and abused every day for over 2 years :S

You beat me to it! The Galaxy S was an ok phone, as it came stock. OK that is, if you liked waiting - a lot! But once I flashed a custom firmware onto it, I would have sworn I had a brand new phone! Then I read more about RFS, which only made me more angry at Samsung for crippling a great phone. Luckily my Galaxy S2 exhibits no such symptoms and is a great phone. I'm looking forward to upgrading to the S3 now.

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.

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..."

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

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

I am not saying there are not people within the giant Samsung company capable of this. I am sure there are.

I am saying they will be working against a strong "Samsung is good at hardware, but not at software" reputation.

Yeah. Kies is slow as hell (more than iTunes on windows.. it says a lot, because iTunes on windows is not a shiny example of good software.) and TouchWiz is slowing down Android, sometimes destroying the battery and is otherwise a design sin, it's far more uglier than the stock UI, it's got better recently (S3, Note 10.1 etc.) but it still has some badly copied parts from iOS that doesn't really match Android's aesthetics, like the custom keyboard. The Samsung keyboard has an identical color scheme to iOS's virtual keyboards, it looks good on iOS because the rest of the interface is similar but it feels like total shit on Android and really it just proves that Samsung actually deserved to get bitchslapped in the courts by Apple because even an Android fan like myself could find too many similarities between what Samsung did to Android (it was worse for past devices) and iOS. Stock Android doesn't look like iOS, but TouchzWiz used to, and some parts of TouchWiz still do to this day (like the keyboard I mentioned).

I love Android, and I like some of Samsung's hardware but I wish they'd shut their whole software division down and just put stock android on their phones and tablets. Stop writing code, and stop designing your custom UI, because you SUCK at this job.

Exactly - Apple and Microsoft have struggled mightily with file systems. I've never heard anyone put Samsung in their league in terms of software...

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?

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.

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.

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

Thankyou.

How large percentage of the storage space can you use before you enter garbage collection hell?

Thanks, that's an awesome summary, and good to know. :)

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.

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.

> 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.

You want writes to flash to be as sequential as possible. Random writes to flash result in more wear and worse performance due to GC overhead.

Log-structured file systems tend to write data sequentially since the writes append to the log (yes - that's a gross over simplification).

File systems like ext4 maintain separate data structures for data and metadata and generate more random writes.

LFS recudes seeks on writes but requires more seeks on reads. This was bad for general purpouse use so they didn't become popular with rotating media.

It's a perfect fit for flash, because there read seeks are (almost) free, and the overwrite-less, sequential writes are a perfect fit. Flash only supports read, erase, and write-on-erased operations, the exact set that LFS uses.

That article is pretty light on the details, but one thing to note is that most sd card storage is relatively poor at random seeks, having been optimized for media type usage.

The cost of random seeks is still going to be lower than on hard drives, which is what most current filesystems were optimized for.