[IDEA] Question: is there plans to use F2FS?

[Exnor]

(22nd Jun, 2014 01:40 PM)mk01 Wrote:  

(24th May, 2014 09:33 PM)Exnor Wrote:  isn't the "typical" write cycle endurance of about near 10K for every bit address ? since every write and erase count as writing how much a mass market Sandisk SD card running 24/7 on xbian will last?

my first RPI SD card A-DATA - bought Jan 2013. Running my devel RPI ever since nonstop.

if you have real concern about data, do live mirror to another device / card / partition. or boot from networked mirrored storage via NFS.

and be on-topic. IriDium remembers right. Xbian-config can do a clone (that we all know). Xbian-config can do a clone to whatever partition type (fstype) you like and XBian without any change will boot from it and work correctly.

when doing partition->partition copy you put /dev/sda1 as dest (/dev/root is predefined source - booted system). this way dest fstype will be btrfs.

when you put f2fs:/dev/sda1 it will be formatted as fsf2.

"any" type is true and is not true, currently allowed is f2fs, ext4, nfs, file.. implementing any other would mean just make xbian-config recognise for instance "ext2" as valid.

---

(25th May, 2014 03:38 AM)Exnor Wrote:  Well you are right... its really nothing to worry about lol. I was just curious to see how F2FS performs and if it is really a benefit..

I elaborated few months back about that as well. There is nothing to be curious about - and it is not (benefit).

You won't see a difference. Ok, not really, f2fs and ext4 feel a bit snappier when running ssh console. Nothing else.

Thks MK01

[CurlyMo]

@mk01, how can users choose to run f2fs instead of btrfs? Can you just change the rootfstype to f2fs and the root to /dev/mmcblk0p2?

[mk01]

(23rd Jun, 2014 11:34 PM)CurlyMo Wrote:  @mk01, how can users choose to run f2fs instead of btrfs? Can you just change the rootfstype to f2fs and the root to /dev/mmcblk0p2?

yes
even I have the feeling that there is code in the xbianclone routine to update cmdline.txt accordingly ... have to recheck as that parts of code I implemented as sneak preview on someone's request very very long ago (month back) - and without zero mileage or feedback never returned back to it - although my VERY limited testing was doing what it should.

you can look at it /usr/local/include/xbian~g/modules/xbiancopy/main lines 50-100. and no, automatically is cmdline.txt changed only for NFS clone.

but it should work the way you posted. rootfstype=f2fs root=/dev/XXX and for sure rootflags needs to change definitely too. I would start with something like that (assuming clone is at /dev/mmcblk0p2)

Code:

root=/dev/mmcblk0p2 rootfstype=f2fs rootflags=rw

there is one problem with f2fs and that is 0 support from community. two years ago it was introduced, it made some noise, was tested by labs and it was said that the korean guys tried to implement some design concepts (which already existed on papers long ago) and terribly failed at some places. there have been recommended to take it back to labs and return in some years. Samsung put sources to git but obviously nobody likes Samsung.

Samsung changed licensing to GPL only this year and as I was now checking (unstable repos) sources for util-linux the support is still no ready (that means will not come to Debian in 1-2Y for sure).

We have f2fs tools, but this is too little to call it system support as without f2fs in libmount the filesystem is practically not existing for system. no blkid, no findmnt. no detection by udev no system events ...

XBian should boot and work but I remember that in the code there is no straight code around f2fs and on some places I simply implemented something like -> if it is not any other filesystem - but the system obviously booted - let's say we are on f2fs.

also keep in mind that f2fs on one hand it showed some "promising" speeds and low wearing, but on the other it was proven that it is faking SYNC writes even on system request (confirming sync to system but completely out of order internally).

I suppose that it was very handy and useful for Samsung in the fight with MS for setting up different contract in the area of charging FAT. What also could indicate the reason why only now it was GPL released - but let's say I'm only paranoid.

[CurlyMo]

Is this something for the wiki?

[mk01]

the independency on rootfstype yes, xbian-config doing copies with diff FS yes, my attacks on f2fs - probably not.

[Exnor]

(25th Jun, 2014 04:00 AM)mk01 Wrote:  

(23rd Jun, 2014 11:34 PM)CurlyMo Wrote:  @mk01, how can users choose to run f2fs instead of btrfs? Can you just change the rootfstype to f2fs and the root to /dev/mmcblk0p2?

yes
even I have the feeling that there is code in the xbianclone routine to update cmdline.txt accordingly ... have to recheck as that parts of code I implemented as sneak preview on someone's request very very long ago (month back) - and without zero mileage or feedback never returned back to it - although my VERY limited testing was doing what it should.

you can look at it /usr/local/include/xbian~g/modules/xbiancopy/main lines 50-100. and no, automatically is cmdline.txt changed only for NFS clone.

but it should work the way you posted. rootfstype=f2fs root=/dev/XXX and for sure rootflags needs to change definitely too. I would start with something like that (assuming clone is at /dev/mmcblk0p2)

Code:

root=/dev/mmcblk0p2 rootfstype=f2fs rootflags=rw

there is one problem with f2fs and that is 0 support from community. two years ago it was introduced, it made some noise, was tested by labs and it was said that the korean guys tried to implement some design concepts (which already existed on papers long ago) and terribly failed at some places. there have been recommended to take it back to labs and return in some years. Samsung put sources to git but obviously nobody likes Samsung.

Samsung changed licensing to GPL only this year and as I was now checking (unstable repos) sources for util-linux the support is still no ready (that means will not come to Debian in 1-2Y for sure).

We have f2fs tools, but this is too little to call it system support as without f2fs in libmount the filesystem is practically not existing for system. no blkid, no findmnt. no detection by udev no system events ...

XBian should boot and work but I remember that in the code there is no straight code around f2fs and on some places I simply implemented something like -> if it is not any other filesystem - but the system obviously booted - let's say we are on f2fs.

also keep in mind that f2fs on one hand it showed some "promising" speeds and low wearing, but on the other it was proven that it is faking SYNC writes even on system request (confirming sync to system but completely out of order internally).

I suppose that it was very handy and useful for Samsung in the fight with MS for setting up different contract in the area of charging FAT. What also could indicate the reason why only now it was GPL released - but let's say I'm only paranoid.

Thks for the info.

[mk01]

(3rd Jul, 2014 02:21 AM)Exnor Wrote:  Thks for the info.

@both

have you seen last release info at raspbmc ?

Code:

Reverted to ext4 as the default filesystem for Raspbmc. ext4 provides better data redundancy and is more compatible with Linux systems for those wishing to backup or transfer data.

so more polite said it doesn't work.

[Exnor]

Quote:

Code:

Reverted to ext4 as the default filesystem for Raspbmc. ext4 provides better data redundancy and is more compatible with Linux systems for those wishing to backup or transfer data.

so more polite said it doesn't work.

Hmm nop... since i got xbian running the way i like, i totally disregarded the other solutions lol. Xbina is my favorite, so i did not read the release info on raspbmc...

Well that's a shame that F2FS got nowhere ... in theory (for what i understand) it would be useful for flash memory... but since the tech is getting better i think maybe it might not be needed after all.

[mk01]

@Exnor

one general deal stopper is there too - F2FS and similar FSs (what you mean) is specifically designed for NAND technologies (and storage media which work like that). but manufacturers tried for years to adapt the firmwares to avoid the common problems (wearing out etc) so now we have storage medias which are intern NAND (the core hw), but in between is so much layers of faked operations & virtualisation that even filesystem which is specifically designed for them doesn't have direct access to the core HW anymore.

Simply they mostly internally work completely different from what is being reported to system (speaking generally about sticks, general use SSDs etc).