Tiny Core Base > Raspberry Pi

how to format a partition to xfs on piCore-9.0.3?

<< < (3/3)

bmarkus:
Apropó, most látom hogy mindketten budapestiek és UPC ügyfelek vagyunk :)

skyp:
Ez így van!  ;) Nem is tudtam, hogy a piCore főhadiszállás itthon van :)! Bár a nevedből rájöhettem volna!  :o
Szép napot!  :)

CentralWare:
Hello, @Béla!
I connected a pair of 512GB USB3.1 thumb drives to a RasPi4 (8GB) and in two separate SSH windows, and at roughly 5:15PM started mkfs.ext2 (I use non-journal for flash based drives out of habit) in each window and left to tend to business, expecting them to be a little while during format.

It's now 11:00PM and the format is at approximately 51% complete.  Both formats were cancelled.

After digging through the archives I finally found a copy of XFS(tools) in the 9.x repo, which seems to work just fine with 12.x filesystem-KERNEL support.  Format time: 2.27sec.  Did you ever give any additional thought to implementing XFS into core?  (It may not be a bad idea to update piCore's more recent repos with xfstools & dev?)  Any updates to your "checking out btrfs?"
Thanks!

bmarkus:
Hi Centralware,

It is an interesting question, thanks. While in the past mainstream distros used ReiserFS or XFS in the last years Ext4 become the de facto standard. It is small, have a good performance and safe in case of crashing. Ext4 journaling saved my life in few cases. Formatting time is just one thing, but the operational performance is more important. Ext4 is good choice in most cases, but for specific applications other file system may be better. For example MongoDB database works much better on XFS. I tested btrfs, it offers nearly the same performance as ext4, the big advantage is the additional built-in feature set like handling virtual volumes, etc. but it is big, including tools and these extra features are not required by average use cases so I dropped to include it in piCore

The beauty of piCore its flexibility. The system itself is in the boot mmcblk0p1 partition, mmcblk0p2 is just for the preinstalled tcz packages, not required by the system. Current boot system supports multiple initrd files. You can create a small initrd with the XFS or btrfs kernel modules and add it to the boot config. In such case these partitions will be recognized during boot, you can replace the default ext4 with XFS or btrfs partitions with the same preinstalled packages.


Regards,

Béla

CentralWare:
The flash drives here were all formatted EXT (EXT2 for what they're being used for, one of the 512GB drives is being used as a local TCL repo mirror; it's almost always read-only so safety shouldn't be too much of a concern), however, on a RasPi4 8GB it ended up taking 17.25 hours to complete formatting directly (the other unit was formatted with Lazy Init, took about five minutes for mkfs to release to the prompt, but assuming the background completion of the format still took 16+ hours.)  Here's our list:



* ZFS: Never tinkered with it; rumors online it's rather fragile (UPS required?) so I've leaned away from that one.
* XFS: From experience with Buffalo NAS units here, seems solid, but online rumors claim somewhat fragile with power outages.
* AFP: Never cared to plant an apple in Linux, they're for eating, not file storage!  Anyone experienced with AFPfs?
* EXT2: (IMO) better for flash and SSD drives, "tends" to flag read-only on a dirty boot, Okay speed, better when on a stripe volume.
* EXT3/4: Good for images and HDD, Decent write speed (journaling), best option for NFS (IMO)
* RFS: Experience is limited (never "beat" on it) but noticed a lag in R/W speed on RAID-5 compared to EXT4
* FAT: Okay if being used (mmcblk0p1) between Nix and Win, Flags R/O in power outage situations more times than not.
* NTFS: Fast format, Win compliant (mostly), permissions tend to be flaky; not really a Nix FS
* SquashFS should be turned into a full bootable file system! :^)
* NFS: EXT4 is my only choice, especially if there's unexpected outages/disconnections. RFS would be my second choice.
* AoE: RFS or EXT3 (we've had some odd behavior with EXT4 here and there where fsck is needed frequently.)
* iSCSI: The jury is out; we're still beating up on this one.

Navigation

[0] Message Index

[*] Previous page