# Unix Filesystem for harddisk for both FreeBSD + Linux?



## Spartrekus (Mar 7, 2018)

Hello,

Needs to format the USB external harddisk... Go for UFS with newfs or something else?

I am looking for a filesystem that would be highly compatible with both Linux and FreeBSD. It should be widely portable, i.e. available on most installation. So that the external harddisk could read user data files well on both platforms.

Which FS may you recommend?

EXT4: nope, it uses FUSE
EXT3: same as above.
UFS1 and UFS2: Linux can read/write well, but it isnt widely available.
JFS: Good but not always be available without installing it
NTFS: ? (just kidding).
...


----------



## Snurg (Mar 7, 2018)

I use ext2 for such cases.
Its geekiness factor is low, but even Windows can support it (there is some software for it, tried it once long long ago when I still had a Windows license, and it worked).


----------



## ralphbsz (Mar 8, 2018)

ZFS should work.  Never tried it myself on Linux, but I know lots of people who use it heavily.


----------



## abishai (Mar 8, 2018)

UFS support on linux was always dim. I believe, it can be mounted only readonly. NTFS is my choose for pendrives. And you get Windows support for free.


----------



## Spartrekus (Mar 10, 2018)

NTFS is made by Microsoft ... 

ZFS is of course very good, but it is not by default on Linux. You need to install then ZFS-FUSE, and it requires FUSE. This is terrible for kernel compiling.

Furthermose, EXT2 is not by default on FreeBSD.

So finally, Unix ??
There is no single compatible FS, available by default on both NetBSD, FreeBSD, or Linux. Even any single FS.  Can you really believe it?


----------



## Crivens (Mar 10, 2018)

My sometimes heavy handed approach to get data from one system to an other is using `tar` on a raw device. That is not "interactive" but gets the job done.


----------



## ralphbsz (Mar 10, 2018)

Sensible suggestion: Connect the external disk to an extra computer (might be as small as a Raspberry Pi), and run a file server (like NFS) on it.  Then you don't need to switch file systems.
Crazy suggestion: Run a small virtual machine on your computer; in that VM, run always the same OS, and use it as a "disk controller" which exports the disk via NFS.  Setting this up (with different hosts for the VM) would be a bit of extra work, but perhaps fun.


----------



## Maxnix (Mar 10, 2018)

Spartrekus said:


> Furthermose, EXT2 is not by default on FreeBSD.


EXT2 is, and limited support for EXT3 too (IIRC read-only). It's EXT4 that is not supported natively.


----------



## xchris (Mar 11, 2018)

Spartrekus said:


> So that the external harddisk could read user data files well on both platforms.



what's the size of the data files? You could use FAT32.


----------



## Spartrekus (Mar 11, 2018)

ralphbsz said:


> Sensible suggestion: Connect the external disk to an extra computer (might be as small as a Raspberry Pi), and run a file server (like NFS) on it.  Then you don't need to switch file systems.
> Crazy suggestion: Run a small virtual machine on your computer; in that VM, run always the same OS, and use it as a "disk controller" which exports the disk via NFS.  Setting this up (with different hosts for the VM) would be a bit of extra work, but perhaps fun.



I did, but after a power down., then again put back the nfs server, mount, and again copy ... (3 Tb is long). So, better to have a portable disk that can be either plug on Linux or BSD.

I wanted to have a good FS, without risk for data. EXT3 is definitely reliable. UFS2 too. Both are default FS, but wont be supported by default by Unix on both at the same time. (I mean of course read and write to work on it).

Better to have an image that does it... What about squashfs if no single FS is compatible for both linux / bsd ?


----------



## Maelstorm (Mar 13, 2018)

ralphbsz said:


> Sensible suggestion: Connect the external disk to an extra computer (might be as small as a Raspberry Pi), and run a file server (like NFS) on it.  Then you don't need to switch file systems.



I second this.  If this is a custom HD case, you can even place the Pi inside the case.  It powers on when you plug it in.  Run NFS and Samba on it, then it's compatible with pretty much everything.  As a plus, you can attach it to a network and access it like that.


----------



## obsigna (Mar 13, 2018)

Maxnix said:


> EXT2 is, and limited support for EXT3 too (IIRC read-only). It's EXT4 that is not supported natively.


Time goes on. According to ext2fs(5) on FreeBSD 11.1-RELEASE:


> DESCRIPTION
> The ext2fs driver will permit the FreeBSD kernel to access ext2, ext3,
> and ext4 file systems.  The ext4 support is read-only.



So it seems to me that the greatest common denominator between FreeBSD and Linux is EXT3.


----------



## ykla (Mar 14, 2018)

ZFS or fat 32​


----------



## Spartrekus (Mar 15, 2018)

ykla said:


> ZFS or fat 32​



zfs maybe, but it use fuse to compile on linux 

how to use ext3 well on a raspberry pi ? I havent found the package in freebsd ...


----------



## Phishfry (Mar 15, 2018)

Spartrekus said:


> how to use ext3 well on a raspberry pi ? I havent found the package in freebsd ...


It's in the base install.
`kldload ext2fs` Then mount.


```
root@E6420:~ # kldload ext2fs
root@E6420:~ # ls /dev/da*
/dev/da0    /dev/da0s1
root@E6420:~ # mount -t ext2fs /dev/da0s1 /mnt
root@E6420:~ # file -s /dev/da0s1
/dev/da0s1: Linux rev 1.0 ext3 filesystem data, UUID=de3dcbc9-a5c5-472a-9395-5756f84c26d6 (needs journal recovery) (large files)
```
I am using it in R+W mode and it works.


----------



## giahung1997 (Mar 16, 2018)

The most suitable FS for interchange between Linux and FreeBSD (only the two) is ZFS. For other BSD or Unix, it didn't exist. You must use Fuse, I prefer NTFS 3g for this situation.


----------



## vermaden (Mar 16, 2018)

You may also use encrypted volume with VERACRYPT (which is in Ports tree/packages) which should also work between FreeBSD and Linux.


----------



## sko (Mar 16, 2018)

giahung1997 said:


> The most suitable FS for interchange between Linux and FreeBSD (only the two) is ZFS. For other BSD or Unix, it didn't exist.



Actually it's FreeBSD, Linux and illumos - so I'd say its pretty much universal for all relevant OSes.
We're using ZFS on all our FreeBSD, smartOS and the 2 remaining Linux hosts here in the infrastructure, which works like a charm and simplifies many things, especially backups, A LOT. Back when one of my servers at home still ran debian and I had an old debian install on my laptop, I've also used ZFS either locally or on USB-Drives to transfer data between those.
TBH I wouldn't set up a linux host to boot from ZFS any more - it's just a pain and far from production-safe. But for transferring data on external drives via sneakernet between those OSes there's just nothing on this planet that can beat ZFS.


----------



## giahung1997 (Mar 16, 2018)

sko said:


> Actually it's FreeBSD, Linux and illumos - so I'd say its pretty much universal for all relevant OSes.
> We're using ZFS on all our FreeBSD, smartOS and the 2 remaining Linux hosts here in the infrastructure, which works like a charm and simplifies many things, especially backups, A LOT. Back when one of my servers at home still ran debian and I had an old debian install on my laptop, I've also used ZFS either locally or on USB-Drives to transfer data between those.
> TBH I wouldn't set up a linux host to boot from ZFS any more - it's just a pain and far from production-safe. But for transferring data on external drives via sneakernet between those OSes there's just nothing on this planet that can beat ZFS.


OpenBSD, NetBSD, Some Proprietary Unix... has ZFS? How Universal!


----------



## vermaden (Mar 16, 2018)

@sko
Add Mac OS X to that OpenZFS list, its supported too ... and Windows support is on its way.


----------



## obsigna (Mar 16, 2018)

IMHO, ZFS is not the file system of choice on a portable disk drive.

The OP is looking for an appropriate files system for his USB disk for exchanging data between Linux and FreeBSD, and in another post he revealed that he is going to use this on a Raspberry PI.

You are suggesting the Zetabyte (1000^4 = 1000,000,000,000 GB) File System for this application, which leaves the RPI with 640 kB of memory for the rest of the operations -- I know, "No one will need more than 637 kB of memory ..." -- seriously??


----------



## vermaden (Mar 16, 2018)

obsigna said:


> IMHO, ZFS is not the file system of choice on a portable disk drive.


What is wrong with ZFS on USB drive? I use ZFS on 4 TB 2.5 USB drives and it works like a charm, it even has GELI below for the security ... and Yes, I use it also on Raspberry Pi 2.

Besicdes, ZFS provides data consistency that NTFS/FAT will not provide.


----------



## giahung1997 (Mar 18, 2018)

vermaden said:


> What is wrong with ZFS on USB drive? I use ZFS on 4 TB 2.5 USB drives and it works like a charm, it even has GELI below for the security ... and Yes, I use it also on Raspberry Pi 2.
> 
> Besicdes, ZFS provides data consistency that NTFS/FAT will not provide.


I've never have usage like you. But on Linux Btrfs (ZFS equivalent on Linux) on USB Disk is a nightmare


----------



## sko (Mar 18, 2018)

giahung1997 said:


> Btrfs on USB Disk is a nightmare



I corrected that sentence for you 
A FS that wasn't designed as being production safe from the beginning and whose devs plain out refuse to learn from errors of previous filesystems, should NEVER be trusted to hold any data. It's nothing more than an object lesson for the NIH syndrome.


----------



## Gray Jack (Mar 18, 2018)

Spartrekus said:


> zfs maybe, but it use fuse to compile on linux
> 
> how to use ext3 well on a raspberry pi ? I havent found the package in freebsd ...



I'm pretty sure that nowadays ZFS can be supported as a kernel module in Linux.
I'm not sure if most Linux distros have that as a package or support it with a modified kernel compilation, but I'm sure that Manjaro Linux supports ZFS as kernel module installing extra packages


----------



## ronaldlees (Mar 18, 2018)

I'd tend to agree with Snurg and obsigna  on this - for a couple reasons, the first being that if the drive is a portable USB drive, it may be connected to multiple computers that are themselves possibly portable, and not all of those devices may be OK with more powerful/complicated file systems.  I'd tend to use EXT2 or EXT3 in this circumstance.

EXT2 might not be a good option if there's very much writing (has no journaling), but may be OK for personal mainly read usage. For read/write, EXT3 has journaling, and might be better IMO.  Linux based cell phones use EXT3 or EXT4, and they all use some form of NAND based storage. Unfortunately, there's no EXT4 for FreeBSD.  No way I'd ever use *FAT* for this.  Eventually it would be nice to see BeFS ported for this purpose, as it has some great features.

Some EXT2/USB users are suggesting that fstab should be set to mount everything with "noatime" option.  No matter what, eventually all USB will fail, so should have a good backup plan.


----------



## silicium (Mar 18, 2018)

I will probably use ZFS, but how much work and knowledge of FreeBSD internals are needed to support write on XFS or EXT4 ?


----------



## vermaden (Mar 18, 2018)

sko said:


> I corrected that sentence for you
> A FS that wasn't designed as being production safe from the beginning and whose devs plain out refuse to learn from errors of previous filesystems, should NEVER be trusted to hold any data. It's nothing more than an object lesson for the NIH syndrome.


... and its used in production in many most critical for big companies environments, as / (root) filesystem and other filesystems under SLES (SUSE Linux) for SAP HANA deployments


----------



## vermaden (Mar 18, 2018)

silicium said:


> I will probably use ZFS, but how much work and knowledge of FreeBSD internals are needed to support write on XFS or EXT4 ?


Its easy (even automount) for EXT4, with writes using ex4 over fuse. From what I recall XFS is not usable on FreeBSD.


----------



## ralphbsz (Mar 19, 2018)

silicium said:


> ... how much work and knowledge of FreeBSD internals are needed to support write on XFS or EXT4 ?


Developing an in-kernel file system is very difficult.  Using fuse makes it just difficult; at least it takes much of the kernel programming out of the equation; still keeping file system data structures organized in one's brain is tough.  But developing a 100% compatible read-write implementation of an existing file system, in a case where the on-disk data structures and the invariants for updating them are not formally documented, but one has to read the existing code to determine the on-disk design, is extremely difficult.  It is a task that should probably be left to the original implementors of the file system, or to people who are in close contact with them.

(about BtrFs):


vermaden said:


> ... and its used in production in many most critical for big companies environments, as / (root) filesystem and other filesystems under SLES (SUSE Linux) for SAP HANA deployments


Btrfs is a machine for losing data.  I don't know what Suse was thinking when they made it the default.  But consider this: the /root file system is not of great importance.  If it is destroyed, one can reinstall, or restore from a backup.  The real user data for SAP Hana is not stored on the root file system of the servers (duh).


----------



## vermaden (Mar 19, 2018)

ralphbsz said:


> (about BtrFs):
> 
> Btrfs is a machine for losing data.  I don't know what Suse was thinking when they made it the default.  But consider this: the /root file system is not of great importance.  If it is destroyed, one can reinstall, or restore from a backup.  The real user data for SAP Hana is not stored on the root file system of the servers (duh).


You missed the part _"and other filesystems"_


----------



## giahung1997 (Mar 19, 2018)

sko said:


> I corrected that sentence for you
> A FS that wasn't designed as being production safe from the beginning and whose devs plain out refuse to learn from errors of previous filesystems, should NEVER be trusted to hold any data. It's nothing more than an object lesson for the NIH syndrome.


No, man. You gone too far. Btrfs only bad for USB. On HDD, I used Btrfs for one big root / and very pleased with btrfs subvol snapshot  Perhaps I've never come across the situation when send/receive over network is needed so I think Btrfs subvol snapshot is more than enough for me. One minor problem with Btrfs is very quickly slow down over time


----------



## sko (Mar 19, 2018)

giahung1997 said:


> No, man. You gone too far.


A FS where the documentation still warns about using a shipped and activated feature and the status of the bug for a long time just was (or still is??) "we have no idea why it destroys your data, but we still keep it" is a toy project at best, but not a file system that should be even considered being used on live systems.
Also: the fast performance degradation problem (IIRC caused by write holes and fragmentation) is as old as btrfs itself and hit me within a few weeks back when I tested it the first (and last) time (~3-4 years ago IIRC). If this still isn't fixed, btrfs is an even bigger dumpster fire than I imagined...



giahung1997 said:


> Perhaps I've never come across the situation when send/receive over network is needed


Wow, this is still not available for btrfs?? What's the point of features like snapshots and built-in data resiliency, if I can't make proper incremental backups preserving these safeguards and have to revert back to dump or tar?


Regarding SUSE:
I don't know why they still try to cope with that can of worms; even RH dropped their support for btrfs installations and they put some serious money in that project...
We have 2 3rd party application servers running with SLES in VMs - both use traditional ext3/4. I've had a chat with the support guy who did the last major upgrade for one of those over lunch, and he also talked a bit about their internal evaluations for using btrfs - essentially it caused way more problems than it could have ever solved for them, so they just abandoned any efforts using it. In fact they currently evaluate ZFS for user data on their bare-metal appliances and he was very interested in how we use ZFS within our infrastructure


----------



## vermaden (Mar 19, 2018)

sko said:


> Regarding SUSE:
> I don't know why they still try to cope with that can of worms; even RH dropped their support for btrfs installations and they put some serious money in that project...
> We have 2 3rd party application servers running with SLES in VMs - both use traditional ext3/4. I've had a chat with the support guy who did the last major upgrade for one of those over lunch, and he also talked a bit about their internal evaluations for using btrfs - essentially it caused way more problems than it could have ever solved for them, so they just abandoned any efforts using it. In fact they currently evaluate ZFS for user data on their bare-metal appliances and he was very interested in how we use ZFS within our infrastructure


From what I have heard Red Hat dropped BTRFS because Red Hat only has XFS developers and none BTRFS developers, so they could not modify/develop BTRFS the way they wanted, also they invested heavily in XFS already ...but XFS is dead end (no data consistency, no compression, no deduplication, nothing ...), but its like Red Hat works, they do not provide latest technology, they only change for subscriptions


----------



## Maelstorm (Mar 19, 2018)

If you are looking for a common file system between both Linux and FreeBSD, there are some options.  Many seem to like ZFS.  That's all well and good, but now I am going to give you the one that is guaranteed to work on FreeBSD, Linux, and even Windows and Mac OSX if you choose, as they all support it relibly...

That file system is FAT-32.  You cannot go wrong with it.  It's supported everywhere.  All the BSD's support it.  The Linux kernel supports it so over 200 Linux distributions have it.  Max OSX has it for interoperability with preformatted flash drives.  Windows supports it because...well...Microsoft originated it.  I think they all support FATex also which is getting pretty common on larger thumb drives.

One other thing...  You will find that the performance of a USB interfaced harddisk is not very good.  I did this for awhile and decided to start using the firewire interface.  Even though the USB spec says it's faster, in practice FireWire is faster because FW uses DMA data transfers while USB uses PIO transfers.  I don't know if this has changed over the years.  Better yet, some machines have an external SATA port you could connect the HD to.  That's the best of both worlds: Portability and performance.  I use a bare HD with a hot-swap bay to d backups and take my data with me.


----------



## Spartrekus (Mar 19, 2018)

I am not so sure about using FUSE: good or evil. 

(On a Raspberry, yeah, Model III b)


----------



## aragats (Mar 19, 2018)

vermaden said:


> Its easy (even automount) for EXT4, with writes using ex4 over fuse.


I always had problems with Ext4 in FreeBSD: wrong permissions, long delays (on SD cards)... It wasn't straight forward...


----------



## Spartrekus (Mar 19, 2018)

aragats said:


> I always had problems with Ext4 in FreeBSD: wrong permissions, long delays (on SD cards)... It wasn't straight forward...



The problem with ext2 is that one cannot store large files, such as hdd backups (gzip after dd).


----------



## Crivens (Mar 20, 2018)

I think you mean FAT here. Anyway, there is split() to solve that.


----------



## Spartrekus (Mar 20, 2018)

Crivens said:


> I think you mean FAT here. Anyway, there is split() to solve that.



Thank you. Besides it is not normal that EXT2 is still in the Linux distributions, because it is very old. Today EXT4 rules Linux planet. EXT2 may disappear from general public kernels, just because it is old.  
(Linus will still pack it into to compile oneself for custom Linux kernel).


----------



## giahung1997 (Mar 20, 2018)

sko said:


> A FS where the documentation still warns about using a shipped and activated feature and the status of the bug for a long time just was (or still is??) "we have no idea why it destroys your data, but we still keep it" is a toy project at best, but not a file system that should be even considered being used on live systems.
> Also: the fast performance degradation problem (IIRC caused by write holes and fragmentation) is as old as btrfs itself and hit me within a few weeks back when I tested it the first (and last) time (~3-4 years ago IIRC). If this still isn't fixed, btrfs is an even bigger dumpster fire than I imagined...
> 
> 
> Wow, this is still not available for btrfs?? What's the point of features like snapshots and built-in data resiliency, if I can't make proper incremental backups preserving these safeguards and have to revert back to dump or tar?



Uhm,, Linux user like me don't worry about document much. Just follow the tutorial on an random blog on the internet or distro wiki, distro forum and everything done. I've never read the document myself, mainly I read only the tuts and examples, many other like me  So I never know what btrfs document contains 

About send/receive. It is my fault, btrfs can send/receive over network via a pipe with ssh, so does zfs, but it can't resume like zfs, you have to use a wrapper script for that job. Just because I've never use this so I don't know for sure. Btrfs is much full featured now


----------



## tingo (Mar 20, 2018)

"old" also means tested, proven, stable, working.
"new" very often means unstable, not tested enough, unreliable.


----------



## Spartrekus (Mar 21, 2018)

tingo said:


> "old" also means tested, proven, stable, working.
> "new" very often means unstable, not tested enough, unreliable.



Under Linux, old means replacement: example SystemV


----------

