Request Mechanism for more FS interoperability.

I have been on FreeBSD for about ~4 weeks now. This Sunday a breakage in Linux drove me to install FreeBSD on my primary drive, instead of keeping FreeBSD on a secondary drive for me to use.

I have 5 large format HDD's in my system that were all ext4. FreeBSD doesn't support ext4. Linux doesn't support UFS. My data became entrapped as a result.

Moving it to a NAS was so slow. I was looking at a ~48 hour period to move stuff in Linux to the NAS, and then about the same moving it from the NAS onto my reformatted UFS2 HDD's. I had to stop the process and go a different direction.

It is my humble opinion that this issue may be a stumbling block to others porting to FreeBSD as I have done. The way I solved it was going into Linux, breaking one of my mirrors apart, reformatting one of the HDD's in the mirror as ext2, copying the other ext4 mirror's data to the ext2 drive, rebooting FreeBSD, repartitioning/formatting the ext4 HDD into UFS, then using rsync copy the data in FreeBSD from the ext2 HDD to the UFS HDD.

I mean it is working.....but is it difficult. This really took a lot of my time. I was going to do it come hell or high water...Others may not be as tenacious.

I don't know how many other professionals like me are going to move a ton of data like this, and his clients to FreeBSD as I am. What I do know is that it would be an obstacle for anyone with data on an ext4 partition to get it into FreeBSD.

I mean the FreeBSD docs shows that XFS was supported. So I originally did the above procedure to XFS, only to reboot and find out that XFS support had been removed from FreeBSD 10.0. Forcing me to go back to linux, make the XFS drive EXT2, copy all that data back over (a 7 hour copy per large format HDD, that are mostly full). Then I was able to mount the ext2 drive in FreeBSD and rsync the files onto the new UFS drive.

So I am encouraging the devs to further develop the existing ext2 fs driver to include ext4 read capability. I am speaking about a stable, robust ext driver that speaks ext2, ext3, and ext4. Or some sort of fuse plugin for that matter. I don't need and I don't think other porters will need write capability...But safe, reliable read support for ext2-4 to me seems to make sense. It's a pathway that FreeBSD would provide to assist in Linux user's and linux based businesses (likemine) to move to FreeBSD.

This would have made my moving data from one fs to another a lot less painful, and certainly less time consuming.

In the end it is worth it.......I would just like to encourage the devs to come up with some less painful way to move data between ext* and UFS.

Having said that....ext2 read support in FreeBSD in my experience has been flawless, as is NTFS read support. But in all reality....Windows users are a lot less likely to dive into FreeBSD than a linux user.

There is compelling reason for Linux users to port to FreeBSD. It has been my observation in the last two years that Linux is becoming less stable than in years past. It seems the technology is being fragmented among competing paradigms and standards....And it is causing Linux as a technology operational issues. Issues that are costing me unrecoverable costs in servicing my clients. Issues that are costing my son's company (McAfee, all CentOS based) lots of operational issues as well. In the corporate world issues = Unrecoverable revenue $$.

my $0.02.

Sincerely and respectfully,

Dave
 
Have you tried NFS. It requires 2 operating systems running simultaneously, either 2 physical machines, or a physical machine and a VM, but it works on both GNU/Linux and FreeBSD without having to reformat anything.
 
NFS was slow as well......slower than the NAS. I built and dedicated an entire machine for this sole purpose.

My port over has been painful, but successful.

I am a seasoned (+30 yr) coder (remember the days of 8 bit assembly and punch cards?). For the last 20 years C, for the last 15 years C++. Formally educated in both, with a lot of commercial experience under my belt.

I just wrote a PM to wblock offering to help expand the ext2fs driver to include 3 & 4. . He seems to be well connected in the FreeBSD world, and has been extremely helpful to me personally in conducting my port. I asked him to help me connect to the right people.

I am new to FreeBSD, but not new to Linux, coding, or sys admining. I am close to 60 years old. I'm going to need some education on kernel modules for FreeBSD, and some education on the internals of ext2, 3, & 4..........But I did offer to write some code to address this, and possibly work in tandem with the current maintainer/author of the ext2fs kernel module to add this functionality so that we can ease the pain for others.....and make it easier for me to convert my existing Linux clients to FreeBSD. Converting them is going to be as difficult as it has been for me personally. Data-entrapment is certainly an obstacle.

Thank you for responding.



Sincerely and respectfully,


Dave
 
@dcbdbis

Use ZFS.

It works on FreeBSD, Linux, Solaris, Illumos (OpenSolaris), Mac OS X and even Windows (read only with zfs-win).
 
vermaden said:
@dcbdbis

Use ZFS.

It works on FreeBSD, Linux, Solaris, Illumos (OpenSolaris), Mac OS X and even Windows (read only with zfs-win).

I once tried to read my OpenSolaris ZFS drive from a FreeBSD machine, and was unsuccessful. Are you sure this is interoperable between various OS's?
 
XFS.

It's still an utter pain having to change your filesystem but both Linux and FreeBSD support XFS (I wasn't sure, but I just checked /usr/src/sys/gnu/fs/xfs). Although I'm not too sure if this module is provided by default (so with the GENERIC kernel).

But I think this is a very reasonable alternative. Quite frankly I've always preferred XFS over ExtX (2 and 3) back in my Linux days.
 
I was just about to post the same thing!

XFS was officially dropped in FreeBSD 10.

I've rebuilt my current kernel a couple of times to "polish" it specific for my system. sudo buildkernel KERNCONF=(YourCustomKernelName) and sudo installkernel KERNCONF=(Your CustomKernelName) on my system still builds all the kernel modules because I never know when I might need something.....After finishing my kernel builds, the XFS kernel module is not in the /boot/kernel tree.

You see,...I had originally tried XFS as stated in the above post. I know, I know, reformatting and then copying a bunch of stuff back over, only to repeat the process in FreeBSD to a UFS drive is a genuine P.I.A....Thus the impetus why I started this post.

Also understand, that although I had been working on a live FreeBSD install for a tad over a month......I am still cutting my teeth on FreeBSD. So I am chalking this up as a learning experience before I changout my clients.

I will tell you....Knowing what I know now.....porting my clients won't be so painful because I now know what is needed before a port-over is started, and I can plan and prepare for it before port-over day.

And the ext2 read support I experienced worked just fine.....checksums matched.

I would urge extreme caution with ZFS. Not that it is a bad file system , it's actually an outstanding file system....But I have read a lot, and I mean a lot of posts in various Linux forums where Linux's ZFS implementation is not always mountable in a FreeBSD environment...Because ZFS support in Linux is not mature at all and lacking a lot of feature set.

Like you, I also read about XFS support in the handbook. I've already mentioned to others that the handbook, really needs to be refreshed and updated. A significant portion of the handbook is outdated where older and incorrect information is still there, and new updated info is not. This is no flame....it's just what I experienced.

It's a volunteer organization, and I am sure in time they will get the docs squared away. I am just to junior to be of assistance myself in working through the docs. Right now, the handbook has become my Bible.


Thank you for responding,

Sincerely and respectfully,

Dave
 
Carpetsmoker said:
I once tried to read my OpenSolaris ZFS drive from a FreeBSD machine, and was unsuccessful. Are you sure this is interoperable between various OS's?

This means that OpenSolaris still existed by then, which was, about 2010?

Its 2014 now and Open ZFS Alliance is up and running since some time - http://open-zfs.org

dcbdbis said:
Because ZFS support in Linux is not mature at all and lacking a lot of feature set.
We use ZFS on Linux with OpenVZ in a production environment, under CentOS 6.5, works like a charm:

Code:
# zpool upgrade -v
This system supports ZFS pool feature flags.

The following features are supported:

FEAT DESCRIPTION
-------------------------------------------------------------
async_destroy                         (read-only compatible)
     Destroy filesystems asynchronously.
empty_bpobj                           (read-only compatible)
     Snapshots use less space.
lz4_compress                         
     LZ4 compression algorithm support.

The following legacy versions are also supported:

VER  DESCRIPTION
---  --------------------------------------------------------
 1   Initial ZFS version
 2   Ditto blocks (replicated metadata)
 3   Hot spares and double parity RAID-Z
 4   zpool history
 5   Compression using the gzip algorithm
 6   bootfs pool property
 7   Separate intent log devices
 8   Delegated administration
 9   refquota and refreservation properties
 10  Cache devices
 11  Improved scrub performance
 12  Snapshot properties
 13  snapused property
 14  passthrough-x aclinherit
 15  user/group space accounting
 16  stmf property support
 17  Triple-parity RAID-Z
 18  Snapshot user holds
 19  Log device removal
 20  Compression using zle (zero-length encoding)
 21  Deduplication
 22  Received properties
 23  Slim ZIL
 24  System attributes
 25  Improved scrub stats
 26  Improved snapshot deletion performance
 27  Improved snapshot creation performance
 28  Multiple vdev replacements

For more information on a particular version, including supported releases,
see the ZFS Administration Guide.

# cat /etc/redhat-release 
CentOS release 6.5 (Final)
 
wblock@ said:
XFS is no longer in FreeBSD 10, unfortunately. Lacked a maintainer, as I recall.
Did a quick check and indeed; now I also noticed.

Pretty weird, I have to say that the lack of information regarding this change is a bit annoying. Nothing is mentioned in /usr/src/UPDATING for example (all I could find was 20121018 which mentions non-MPSAFE filesystems). So I started looking around some more, I did manage to find the FreeBSD 10 wiki page but that also seems to hint at the removal of ReiserFS. Yet this module seems to be still available in FreeBSD 10 as far as I can tell (I can see the sources; haven't tried to build it).

So I guess when all else fails we still have ReiserFS, even though that was never much of a favourite of mine ;)
 
ShelLuser said:
wblock@ said:
XFS is no longer in FreeBSD 10, unfortunately. Lacked a maintainer, as I recall.
Did a quick check and indeed; now I also noticed.

Pretty weird, I have to say that the lack of information regarding this change is a bit annoying. Nothing is mentioned in /usr/src/UPDATING for example (all I could find was 20121018 which mentions non-MPSAFE filesystems). So I started looking around some more, I did manage to find the FreeBSD 10 wiki page but that also seems to hint at the removal of ReiserFS. Yet this module seems to be still available in FreeBSD 10 as far as I can tell (I can see the sources; haven't tried to build it).

So I guess when all else fails we still have ReiserFS, even though that was never much of a favourite of mine ;)

The removal of XFS due to being non-MPSAFE is documented in the wiki:

https://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS
 
XFS read support was working, but I always got a kernel panic when unmounting the drive again. So removing it was not that bad an idea. Also, If I remember correctly, Linux has "tuned" XFS somewhat, so I would suggest checking if the on-disk layout is affected by some of the changes they made before trying to de-crypt (re-animate) the old XFS code.

But when it comes to transfer large amounts of data between different systems of a POSIX flavour, you can always go back to the good old tape approach. Only, today you might not use a tape but a disk. You tar the files together and write that onto a raw device, and you can recover that data on any other system which supports directly reading that device and has a suitable tar (or zoo or whatever, a suitable tool that is on both systems).
 
Back
Top