Supported File Systems

jnbek

jnbek

Good day:
I was reading Linux Filesystems on the Handbook and was confused and moderately shocked that ext2 is the ONLY Linux file system that is fully supported read/write. Is this for real? What filesystems can I write to on a Linux machine, that I can read and write to on a FreeBSD machine? (As in a multi-boot environment or taking a drive from a Linux machine to a FreeBSD machine, etc). Fuse is not really an option, but it seems Fuse support for read/write filesystems is pretty poor as well. Why is this the case? Why hasn't ext4 been ported or why is XFS support 'incomplete', or ReiserFS; why is this also incomplete? Just doesn't seem to make sense to me that I have to use ext2 or fat file systems, both of which have been long superseded by superior or at the very least, more modern filesystems. x(
 
Simple answer: FreeBSD is not Linux, the implementations of ext3 and ext4 are so Linux specific that porting them to FreeBSD would be a major undertaking because of the differences in the internal implementations between FreeBSD and Linux. There's also the licensing issue, none of the FreeBSD developers would agree to include any GPL licenced code into the FreeBSD kernel. This would exclude using the Linux implementations as a basis for FreeBSD implementations, everything would have to be written from scratch.

And really, you can not seriously call ZFS less advanced or modern than what Linux has to offer?
 
Well, I'm aware that FreeBSD is not Linux, I've been using FreeBSD quite a bit longer than I have Linux, and ZFS is a great modern piece of software, that Linux support exists for, but is less than optimal for my particular case. I have a FreeBSD server, that the motherboard is going bad on, and I just need to get my data off the machine quickly, I don't have time to set up a ZFS drive, install ZFS on my Linux machine, etc etc etc. I just want to format a drive to a FileSystem that both systems can read, copy all the data to it, take said drive, make a second backup on the Linux machine on a third drive (Redundancy never hurt anyone). Then I can take down the dying system and commence building a new server. I *could* copy the files to the Linux machine using NFS, sure, but network latency would slow the process. I just want to copy the files as fast as possible. It should be noted that all the files need to remain available during the server migration, and all i have to work with are Linux desktops, so one of the Linux desktops will have to become the 'NFS' hub, so my thoughts were, using FreeBSD create a Linux FS on a spare drive, cp the whole mess over, yank said drive from the dying machine, and stick the drive into one of the Linux desktops, export the paths, and be done with it. Then once the new server is ready, yank the drive, stick it into the new server, then cp the mess back, on a fresh RAID array. I suppose I can understand the FreeBSD Devs concern with licensing, but that just aggravates me even more... This is all supposed to be 'free' software, but i don't feel very 'free' when I can't use one thing anywhere i want to.. if i want read/write EXT4 on FreeBSD, i should be 'free' enough to do so.. even if i have to extract the source into /usr/src and [CMD="make obj;make depend;make;make install"]make obj;make depend;make;make install[/CMD] it myself..
 
Depending on your network speed rsync can copy things quite fast.

Personally I use a USB hard drive formatted with good old Fat32 for backups, but also use it to cart files around that can be read by other systems (Mac, Windows, BSD, Linux). Not the most robust solution, but if it has a blowout it was only backups, and I just replace or reformat the drive as needed.
 
Yeah, I wish a thumb drive would work, only I'm dealing with just shy of a terabyte of data ;-)
 
FUSE support has greatly improved in the past year or so. And there's now support for a lot of filesystems via FUSE:
Code: 
#psearch fuse
deskutils/fusenshi        A Post-it(R) like application with network support
devel/diffuse             A graphical N-way diff and merge tool written in python
devel/libconfuse          Configuration file parsing library
devel/py-fusefs           FUSE Python bindings
emulators/fuse            Free Unix (Sinclair ZX-)Spectrum Emulator
emulators/fuse-utils      Utilities from the Free Unix Spectrum Emulator
graphics/fusefs-gphotofs  Mount PTP camera as a file system
sysutils/archivemount     Mount archives with FUSE
sysutils/fusefs-afuse     An automounting file system implemented in user-space using FUSE
sysutils/fusefs-chironfs  A FUSE based filesystem with replication at the filesystem level
sysutils/fusefs-cryptofs  A encrypted filesystem for FUSE
sysutils/fusefs-curlftpfs Mount remote ftp directories
sysutils/fusefs-encfs     An encrypted pass-through FUSE filesystem
sysutils/fusefs-ext4fuse  EXT4 implementation for FUSE
sysutils/fusefs-funionfs  Union filesystem for the FUSE driver
sysutils/fusefs-fur       FUSE-based filesystem for Windows CE based devices
sysutils/fusefs-fusexmp_fh Dummy driver from fusefs-libs example
sysutils/fusefs-gnome-vfs Interface between FUSE and the Gnome VFS 2.0
sysutils/fusefs-gstfs     On-demand, transcoding filesystem (using GStreamer pipeline)
sysutils/fusefs-gunzip    Fuse.gunzip provides transparent decompression of gzip compressed files
sysutils/fusefs-httpfs    Fuse-based http filesystem
sysutils/fusefs-ifuse     Mount iPod Touch / iPhone directories over USB
sysutils/fusefs-kmod      Kernel module for fuse
sysutils/fusefs-libs      FUSE allows filesystem implementation in userspace
sysutils/fusefs-mhddfs    Multi HDD [FUSE] File System
sysutils/fusefs-ntfs      Mount NTFS partitions (read/write) and disk images
sysutils/fusefs-pod       FUSE-based filesystem for iPod
sysutils/fusefs-rar2fs    Mount rar archives as filesystem
sysutils/fusefs-s3fs      FUSE-based file system backed by Amazon S3
sysutils/fusefs-smbnetfs  Mount smb shares (Fuse filesystem)
sysutils/fusefs-sqlfs     SQLite backed FUSE file system
sysutils/fusefs-sshfs     Mount remote directories over ssh
sysutils/fusefs-unionfs   FUSE based implementation of the well-known unionfs
sysutils/fusefs-wdfs      Mount remote WedDAV directories with Fuse
sysutils/fusefs-wikipediafs Mount mediawikis

Note that ext4 is listed in the above.

The ext2 filesystem support that ships with the FreeBSD kernel will read ext3 filesystems in ext2 mode (ie, no journal).
 
Yup the ext support in FreeBSD is really meant as a temporary solution to mount and move files to FreeBSD native filesystems (i.e. ufs or zfs).

It's not really meant for day in and day out usage. FUSE looks interesting btw.
 
You could simply use tar for this. Set the output file to the raw disc device /dev/sdX on Linux for example. The tar format should be what you need to copy your files, and why would you need a file system to store a single file? On FreeBSD then you can restore from the whole disc as input.
 
jnbek said:
Fuse support for read/write filesystems is pretty poor as well. Why is this the case? Why hasn't ext4 been ported or why is XFS support 'incomplete', or ReiserFS; why is this also incomplete? Just doesn't seem to make sense to me that I have to use ext2 or fat file systems, both of which have been long superseded by superior or at the very least, more modern filesystems. x(
Click to expand...

Too many questions...if you don't like you can also use your-operating-system-of-choice.
Besides that, while not exporting data via a regular backup (tar, zip, bzip2, ...) or exporting it via network?
 
@jnbek

FAT is supported by FreeBSD, exFAT is supported over FUSE by a port.

EXT2 and EXT3 (without journal) is suported by FreeBSD, EXT4 is supported over FUSE by a port.

NTFS R/O is supported by FreeBSD, NTFS R/W is supported over FUSE by port.

Linux LVM is suported by FreeBSD by kldload'ing appreciate kernel module not loaded by default.

UFS1 and UFS2 are FreeBSD's native filesystems, ZFS is also fully supported for pools up to v28.

ReiserFS R/O is supported by FreeBSD.
 
XFS is (was?) also supported RO, but machine panics at umount.
 
One last thing: judging from the options mentioned above you probably won't go with FAT, but if you do, remember that FAT-16 has a filesize limit of 2 GB. Few files are that big, but DVD images, encryption containers and virtual machines do come to mind...

Fonz
 
You must log in or register to reply here.
Back
Top