tkaiser Posted July 3, 2015 Posted July 3, 2015 What to do to switch from ext4 to F2FS (one big caveat: Partition/filesystem resizing doesn't work with F2FS so this is only for you if you know the size of your SD card prior to building the image)? I tried the following so far: apt-get install f2fs-tools define size of f2fs partition in compile.sh (eg. for a 4 GB SD card use »SDSIZE="3600"«) adjust »BOOTSIZE=16« in lib/configuration.sh (line 26) replace »mkfs.vfat -n "$IMAGEVOLUME"« with »mkfs.ext4 -q« in lib/deboostrap.sh (line 66) replace »mkfs.ext4 -q« with »mkfs.f2fs« in lib/deboostrap.sh (line 67) add »-tf2fs« to mount option in lib/deboostrap.sh (line 68) comment »shrinking_raw_image "$DEST/output/$VERSION.raw"« out in lib/common.sh (line 463) change fstab entry to »echo "/dev/mmcblk0p2 / f2fs defaults,noatime,nodiratime,errors=remount-ro 0 0" >> $DEST/output/sdcard/etc/fstab« in lib/distributions.sh (line 105) comment »install -m 755 $SRC/lib/scripts/resize2fs $DEST/output/rootfs/$CHOOSEN_ROOTFS/etc/init.d« out in lib/distributions.sh (line 138) avoid partition resizing on first run by removing lines 89-101 in lib/scripts/firstrun But the Banana Pro I test with doesn't boot. I would assume that I have to modify boot.cmd (and exchange /boot/ with /)? Thx
Igor Posted July 3, 2015 Posted July 3, 2015 You probably only need to define where is root, customizing boot.cmd + recompile will be necessary. from root=/dev/mmcblk0p1 to root=/dev/mmcblk0p2
tkaiser Posted July 3, 2015 Author Posted July 3, 2015 Made some progress: I ended up with this boot.cmd: setenv bootargs console=tty1 root=/dev/mmcblk0p2 rootwait rootfstype=f2fs sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1 #-------------------------------------------------------------------------------------------------------------------------------- # Boot loader script to boot with different boot methods for old and new kernel #-------------------------------------------------------------------------------------------------------------------------------- if ext4load mmc 0 0x00000000 /.next then # sunxi mainline kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x49000000 /dtb/${fdtfile} ext4load mmc 0 0x46000000 /zImage env set fdt_high ffffffff bootz 0x46000000 - 0x49000000 #-------------------------------------------------------------------------------------------------------------------------------- else # sunxi android kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x43000000 /boot/script.bin ext4load mmc 0 0x48000000 /boot/zImage bootz 0x48000000 #-------------------------------------------------------------------------------------------------------------------------------- fi And I had to relink the kernel (since pointing to /boot/ does not work when /dev/mmcblk0p1 is / from U-boot's point of view: zImage -> vmlinuz-4.1.1-bananapipro But now I'm stuck at this point: Debian GNU/Linux 7 bananapipro ttyS0 bananapipro login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password: Enter new UNIX password: Retype new UNIX password: Authentication token manipulation error Debian GNU/Linux 7 bananapipro ttyS0 bananapipro login: Looks like for whatever reasons / is mounted read-only.
tkaiser Posted July 3, 2015 Author Posted July 3, 2015 I removed 'errors=remount-ro' from fstab that now looks like: /dev/mmcblk0p2 / f2fs defaults,noatime,nodiratime 0 0 /dev/mmcblk0p1 /boot ext4 defaults,noatime,nodiratime 0 0 And now I'm in: root@bananapipro:/bonnie# cat /etc/mtab /dev/root / f2fs rw,noatime,nodiratime,background_gc=off,nouser_xattr,noacl,noinline_data,active_logs=6 0 0 devtmpfs /dev devtmpfs rw,relatime,size=514128k,nr_inodes=128532,mode=755 0 0 tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=131072k,mode=755 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=131072k 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 /dev/mmcblk0p1 /boot ext4 rw,noatime,nodiratime,data=ordered 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=1048576k 0 0
tkaiser Posted July 3, 2015 Author Posted July 3, 2015 Some results (tested using "bonnie++ -u nobody" on a Banana Pro with kernel 4.1.1 and default settings): ext4 on slow Intenso TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 93 95 9875 19 6020 12 650 99 19163 13 38.5 3 Latency 236ms 27892us 6445ms 49584us 134ms 29474us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2059 20 +++++ +++ 932 10 1661 16 +++++ +++ 605 10 Latency 1632ms 10146us 4828ms 5130ms 10087us 5125ms ext4 on fast SanDisk "Extreme Pro" TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 96 99 21209 15 10929 8 675 99 28457 8 1737 63 Latency 92653us 18445us 2968ms 15123us 25312us 11677us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 6862 60 +++++ +++ 2151 14 5815 49 +++++ +++ 1545 10 Latency 137ms 2480us 1429ms 670ms 97us 1671ms f2fs on the same fast SanDisk "Extreme Pro" TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 116 99 20736 22 10241 18 664 99 27806 20 2012 147 Latency 196ms 5023ms 4332ms 41126us 119ms 36883us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2446 35 +++++ +++ 12308 87 2778 38 +++++ +++ 6677 83 Latency 13341us 1319us 9974us 10020us 154us 10824us
tkaiser Posted July 3, 2015 Author Posted July 3, 2015 And now with cpufreq settings changed to "performance" (the cpufreq defaults starting with kernel 4.0 are somewhat problematic if you're after storage performance since defaults means: ondemand without io_is_busy) f2fs with performance cpufreq governor on the same fast SanDisk "Extreme Pro" TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 117 99 18831 12 9967 8 675 100 28788 9 2037 75 Latency 70771us 29371us 5436ms 14823us 38940us 20005us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2446 31 +++++ +++ 12839 87 2762 37 +++++ +++ 6759 82 Latency 782us 847us 3372us 753us 85us 2021us
tkaiser Posted July 3, 2015 Author Posted July 3, 2015 I made a few other tests and noticed that using a very slow SD card the system behaved 'snappier' (at least this was my feeling maybe only driven by 'it has to be more snappy after hours of fiddling around'). But I wasn't able to get the performance gains others reported (eg. Phoronix). Maybe just a matter of methodogloy and more time (but I've enough) Anyway I patched your build system 'statically' and made a diff of the changes: http://pastebin.com/hidkugaG Would be better to make this stuff optional, eg. introducing ROOTFS=ext4|btrfs|f2fs -- but the main problem is that neither f2fs nor btrfs are resizeable and therefore an $SDSIZE value chosen too large will result in an image not able to write to SD card or NAND. So if $ROOTFS isn't set as ext4 the user should be asked for the size of his SD card (2, 4, 8, 16, ...) and then $SDSIZE should be set appropriately. Anyway. You/we have to fix the build system since setting $BOOTSIZE greater than 0 currently fails (wrong entries in boot.cmd/boot.scr, wrong symlink creation in patch/packaging-next.patch, wrong fstab contents). And since you're using mainline u-boot I would suggest switching from VFAT to ext4 in deboostrap.sh (line 66). BTW: In configuration.sh $CPUMAX should be set to "1080000" otherwise a fallback to 960MHz will happen (or maybe this is intended since with mainline 960000 is the maximum without patching arch/arm/boot/dts/sun7i-a20.dtsi?)
Igor Posted July 3, 2015 Posted July 3, 2015 This FAT boot partition is solved half way - scripts need to be adjusted manually, the rest works. I thought I left a note in configuration but I didn't Nice job. btrfs should be resizeable but not with resize2fs so this part is solvable. f2fs probably too. On the other hand I manage to write a script manual v1.0 I'll fix this asap. And since you're using mainline u-boot I would suggest switching from VFAT to ext4 in deboostrap.sh (line 66). Oh, this is intentionally. Some people want to have fat boot partition to be windows accessible. I'll rather do it configurable then. BTW: In configuration.sh $CPUMAX should be set to "1080000" otherwise a fallback to 960MHz will happen (or maybe this is intended since with mainline 960000 is the maximum without patching arch/arm/boot/dts/sun7i-a20.dtsi?) Not sure out of my head how is this on mainline.
tkaiser Posted July 4, 2015 Author Posted July 4, 2015 On the other hand I manage to write a script manual v1.0 Thx, great job. I hope the URL remains since I will link often to it Regarding the filesystems. In my opinion btrfs is only interesting for disk storage (SATA, USB) and for people who know what they do (creating snapshots, transferring these snapshots incrementally using 'btrfs send/receive' to other disks/machines and so on -- all this has drawbacks, for example getting a clue how much space is really available on the disk in question). So regarding btfrs this is more a candidate for nand-sata-install: Allowing to use btrfs for sda1 and recommending to partition the disk prior to that and to use a separate partition for / and for other/media data (since using snapshots this makes backing up everything way more easy). Regarding F2FS: It should be superiour compared to ext4 when used on NAND/SD Cards or other flash based media. But I'm still not convinced whether it's worth the efforts since the resizing problem remains. Would be great to be able to choose it optionally but I doubt that it's ready for your normal OS images. Regarding cpufreq stuff: This remains the same in mainline: You can adjust the sysfs values as you want but all values will be rounded down in 48 MHz steps. BTW: I will try to add a few additional operating points in arch/arm/boot/dts/sun7i-a20.dtsi to slightly 'overclock' some A20 boards: operating-points = < /* kHz uV */ 1200000 1600000 1152000 1550000 1104000 1500000 1056000 1450000 1008000 1450000 960000 1400000 912000 1400000 864000 1300000 720000 1200000 528000 1100000 312000 1000000 144000 900000 >; I'll report back if I find anything interesting (A20 specs say that 1.4V is max.)
onlinespending Posted December 4, 2015 Posted December 4, 2015 What to do to switch from ext4 to F2FS One solution that's perhaps easier, that doesn't require as much edits to the build environment, is to simply go through the usual compile.sh process (using the default ext4 for root) and convert post installation. This way you don't need to worry about partition resizing, and it gives you the option to encrypt root as well. You'll only want to ensure that the BOOTSIZE parameter is not 0, so that separate /boot and / partitions are created in the image. For the BananaPi, I used 16MB as you did. Once you've put the image on an SD card and gone through the initial boot, use a USB flash drive (or SATA drive) to temporarily mount as root. To do this, create a single ext4 partition on the USB drive, mount it (e.g. mount -t ext4 /dev/sda1 /mnt/usbdrv) and copy the contents of root to it (e.g. rsync -arx / /mnt/usbdrv). Now edit /boot/boot.cmd and set the root device as /dev/sda1 (assuming that's the partition you just copied root to). Rebuild the boot.scr (i.e. mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr) and reboot. You'll notice that the USB drive (or SATA) is now mounted as /root. This allows you to easily re-format the former root partition on the SD card (e.g. /dev/mmcblk0p2) as f2fs, with the ability to optionally encrypt the root partition using cryptsetup before you format it as f2fs. And it will preserve the size of the former ext4 partition, so no need to worry about the possible lack of f2fs resizing. Once you've mounted (e.g. to /mnt/sdcard) and copied the root files back over to the newly formatted /dev/mmcblk0p2 (e.g. rsync -arx / /mnt/sdcard) edit the /etc/fstab file on the sdcard to properly mount root using f2fs (e.g. /mnt/sdcard/etc/fstab) then you can just edit the /boot/bboot.cmd file to point back to /dev/mmcblk0p2, recreate boot.scr, take out the UBS flash drive, and reboot. If you do opt for encryption, you'll need to also edit crypttab (e.g. /mnt/sdcard/etc/crypttab) and edit the boot.cmd to reflect the use of an encrypted root (e.g. root=/dev/mapper/cryptroot cryptdevice=/dev/mmcblk0p2:cryptroot).
Recommended Posts