There are some options for NAND flash oriented file systems supported by kernel (I had recompiled kernel with this option), one is f2fs (Flash-Friendly File System),
I might try it in the future. Some smart phones already use it. I really know nothing about its behavior but there is plenty of info around.
For a full ext2 on flash you will loose journaling and you will have better life span, less write operations. But corruption is extremely likely with a power failure on ext2 and recover process might take long on fs check if successful.
Ext4 is a better option but with journaling on, you will have much more r/w operations in flash, reducing nand life, but you can disable journaling on ext4 (prone to failure also). Using save.dat this only happens once on exit so journaling seems a no problem option.
I had also booted nemesis with grub4dos for a parallel ssd/hdd installation, and converted an old ex3 partition to ext4 with full journaling.
I had also tried to mount save.dat with the "journal_data" option and see if there is some kind of file system stability improvement for loop1. This does not mean that it will be improved.
I will use the hdd for native saving persistence with full journaling and keep a save.dat alternative for flash for portability and easy r/w operations on windows.
I have done some ex4 fine tuning to see if there is any difference.
I am not sure but the default "data=ordered" ex4 option could be problematic when shutting the system down, because of the journal metadata delayed data allocation defaulting to 5 seconds. A performance reduction will be there though if you will use full journaling.
http://unix.stackexchange.com/questions ... ta-ordered
http://www.pointsoftware.ch/en/4-ext4-v ... on-is-bad/
Code: Select all
tune2fs -o journal_data /dev/loop1
or keep "data=ordered" and use "nodelalloc" to disable delayed allocation.
check ex4 attributes:
Code: Select all
dumpe2fs 1.42.13 (17-May-2015)
Filesystem volume name: <none>
Last mounted on: /memory/changes
Filesystem UUID: 60a78605-374e-43cf-9ce7-5b4acfb5d44e
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: journal_data user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 307200
Block count: 1228800
Reserved block count: 61440
Free blocks: 411959
Free inodes: 264571
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 252
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2048
Inode blocks per group: 256
RAID stride: 57329
Flex block group size: 16
Filesystem created: Sat May 28 14:08:07 2016
Last mount time: Tue Jun 21 14:12:29 2016
Last write time: Tue Jun 21 14:12:29 2016
Mount count: 4
Maximum mount count: -1
Last checked: Sat Jun 18 23:59:07 2016
Check interval: 0 (<none>)
Lifetime writes: 40 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 8b8f8a2a-380d-4654-96dc-28456d365df9
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 4096k
Journal length: 4096
Journal sequence: 0x00015b9b
Journal start: 2411
Code: Select all
root /home/guest # dmesg | grep 'mounted filesystem'
[ 2.846864] EXT4-fs (sdb5): mounted filesystem with journalled data mode. Opts: (null)
[ 7.305742] EXT4-fs (loop1): mounted filesystem with journalled data mode. Opts: (null)
So there might be some good reasons to keep save.dat solution around, there could be a shutdown script that will safely check successful save operations and the full size issue. There also could be an automated time interval and manual save operation independent of exit.