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
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