Moving to btrfs

[Dimtar]

Hi all.

 

I am having unraid crashing problems and I believe it's to do with the file system. I would like to convert all the disks in my server from rfs to btrfs.

 

Does anyone have any suggestions on the quickest way to do this?

[NAS]

Personally I would use XFS

[BRiT]

I would not use btrfs for array drives. I might use btrfs for the cache drive, but that's debatable now that docker is done via a loopback image.

 

I'd go with xfs.

[SSD]

Whether you are moving to XFS or BTRFS (I am moving to XFS personally), there is no quick and easy method.

 

What I did was started with a new disk of the largest size in my array formatted with the new FS (XFS for me).

 

I use Teracopy in move mode (Teramove) using my Windows workstation. Teramove will copy the file (determining its hash code in the process), and afterwards read the destination file to determine its hash code. Only if the hash codes match does Teramove delete the source file start the next file. Thus your move is self verifying. It DOES take longer, but I am confident that the move worked properly (see below for a known risk). Once the disk is moved completely, reformat the now empty disk to the new FS, and then began the process of Teramoving the next disk to it. Repeat until all of the disks are moved over. At the end you should have an empty disk left over.

 

Note that difference file systems have different amounts of housekeeping, so if you fill your disks to the brim, you may not have enough space for the last few files to fit on the new FS. You can deal with this preemptively, by moving some files to a less full disk to leave at least a few gigs of free space on your source disk before you start the move, or just let it go and clean up if it fails near the end.

 

There is a suspected bug (I am about 90% confident based on personal experience) that if you are copying a file at the time the destination disk is red-balled by unRAID, the file it was copying will be corrupted. If you are moving the files from disk to disk (the fastest method), you would never know. The Teramove will detect that this happened and stop, and will NOT delete the source file. (Note that if anyone has this happen, please contact me via PM. I would ask you to run some tests on the source and target files to try and verify this is indeed a bug).

[StevenD]

I had problems with BTRFS on my cache.  I reformatted it to XFS and I havent had a single hang.

[Dimtar]

Hi all.

 

Thanks a bunch for the help, looks like I am moving everything to XFS. I am clearing some data now to make my life easier but it will probably take a month or more to do this.

 

How does this sound as an idea?

Stop array.

Remove a drive from array.

Start array.

rsync data from removed drive to array

Format drive to XFS

Stop array

Add newly formatted XFS drive to array

Start array

 

Repeat?

 

bjp999 mentioned corrupt files etc., I figure if I use rsync it should cover most of these and if they are corrupt I would rather leave them on the drive that is about to be formatted. The aim of this all is to get rid of whatever corrupt data I have.

[SSD]

Hi all.

 

Thanks a bunch for the help, looks like I am moving everything to XFS. I am clearing some data now to make my life easier but it will probably take a month or more to do this.

 

How does this sound as an idea?

Stop array.

Remove a drive from array.

Start array.

rsync data from removed drive to array

Format drive to XFS

Stop array

Add newly formatted XFS drive to array

Start array

 

Repeat?

 

bjp999 mentioned corrupt files etc., I figure if I use rsync it should cover most of these and if they are corrupt I would rather leave them on the drive that is about to be formatted. The aim of this all is to get rid of whatever corrupt data I have.

 

How are you going to remove a drive from the array (your second step)? Removing a disk from the protected array is very time consuming requiring a new parity build. And in order to easily add a disk to the protected array you would have to preclear it, another very time consuming task. You would do better copying the data from the one disk (the one you were planning to remove) to your others disks in your array without removing it from the array. Then you can reformat the disk to XFS. That is much easier and faster than removing and later re-adding the disk.

 

And how does rsync avoid possible corruption if a disk fails during a copy? And how are you removing existing corrupt files? (Corrupt file are impossible to detect accurately without having good md5 or similar data on your files or having a good backup of all your data.) Re-read my post. Using some form of integrity check as part of the copy (move) process is needed. I am not sure rsync had that functionality, but if it does I will be very interested.

[Dimtar]

I've since adjusted how I am going to do things.

 

My cache drive has just been removed from the array and its going to be my temp drive. I will use rsync to move files to it and then back after I format each drive for XFS.

[jbrodriguez]

you know, we should alll be moving to btrfs ... if it does scrubbing the same way zfs does, we at the least get bit rot protection ... no ?

[NAS]

the general consensus is that XFS is more reliable than BTRFS. Certainly if you look on this forum with a relatively small number of users you see almost no XFS problem posts and almost every FS problem post is related to BTRFS in some way.

 

Anacdotal perhaps but if you follow any linux news channels you tend to see the same pattern emerging.

 

BTRFS is brilliant technology but for me it is no where near ready to "set and forget"

[jonp]

the general consensus is that XFS is more reliable than BTRFS. Certainly if you look on this forum with a relatively small number of users you see almost no XFS problem posts and almost every FS problem post is related to BTRFS in some way.

 

Anacdotal perhaps but if you follow any linux news channels you tend to see the same pattern emerging.

 

BTRFS is brilliant technology but for me it is no where near ready to "set and forget"

OpenSUSE is using btrfs now as there default filesystem. I think btrfs is ready but just certain features aren't.

[neilt0]

Are there any issues in defragging a btrfs cache drive under unRAID? As described here: https://wiki.archlinux.org/index.php/Btrfs#Defragmentation

[NAS]

the general consensus is that XFS is more reliable than BTRFS. Certainly if you look on this forum with a relatively small number of users you see almost no XFS problem posts and almost every FS problem post is related to BTRFS in some way.

 

Anacdotal perhaps but if you follow any linux news channels you tend to see the same pattern emerging.

 

BTRFS is brilliant technology but for me it is no where near ready to "set and forget"

OpenSUSE is using btrfs now as there default filesystem. I think btrfs is ready but just certain features aren't.

 

Perhaps it is our implementation of docker or loopback that is the issue then because i see it report cryptic errors all the time. These are the same errors as we see on other user posts that typically result in having to redownload containers.

 

For instance I just checked and my few day old loopback now has 2 csum errors.

 

I am not convinced it is in the same league as RFS or XFS in terms or reliability yet.

 

https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F