I am new to snapraid and I have an issue that I have been unsuccessful googling (and searching this forum) for a solutions.
I have 3X 4TB drives. All are formatted to btrfs. I now understand this may introduce problems with parity but it seems like I have a snag in my config file. My snapraid.conf file is:
parity /mnt/diskp/snapraid.parity
content /var/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
# Excludes hidden files and directories (uncomment to enable).
#nohidden
exclude *.unrecoverable
exclude /tmp/
exclude /lost+found/
I have subvolumes set up on each disk. When I run syn I get:
oglark@sklad:~$ sudo snapraid sync
Self test...
Loading state from /var/snapraid.content...
Scanning disk d1...
WARNING! Ignoring mount point '/mnt/disk1/@archive-photos' because it appears to be in a different device
Scanning disk d2...
WARNING! Ignoring mount point '/mnt/disk2/@archive-video' because it appears to be in a different device
WARNING! Ignoring mount point '/mnt/disk2/@archive-music' because it appears to be in a different device
WARNING! Ignoring mount point '/mnt/disk2/@archive-ebooks' because it appears to be in a different device
Using 0 MiB of memory for the FileSystem.
Initializing...
Resizing...
Saving state to /var/snapraid.content...
Saving state to /mnt/disk1/snapraid.content...
Saving state to /mnt/disk2/snapraid.content...
Verifying /var/snapraid.content...
Verifying /mnt/disk1/snapraid.content...
Verifying /mnt/disk2/snapraid.content...
Syncing...
Nothing to do
I have not mounted the @archive -xxx subvolumes yet. Is there something obvious that I am doing wrong?
I appreciate any help anyone can give me.
Regards,
Karl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I figured out what as wrong. I thought that if the subvolume was unmounted it would be treated as a directory from the top level btrfs partition. According to the btrfs wiki it is actually similar to a POSIX namespace which apparently means that it is analgous to a separate partition. I modified my snapraid.conf file to:
parity /mnt/diskp/snapraid.parity
content /var/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
data d1 /mnt/disk1/@archive-photos
data d2 /mnt/disk2/@archive-music
data d3 /mnt/disk2/@archive-video
data d4 /mnt/disk2/@archive-ebooks
And now snapraid picks up the volumes correctly (although now it has problems with the UUID/inodes) and calculates parity. Again, sorry for my newby-ness, I am still getting my head around the concepts of btrfs.
Regards,
Karl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have run into the same problem, and I don't think Karl's solution is good because this will assume that d2,d3,d4 are separate disks. Now if /mnt/disk2 fails, snapraid will see it as 3 failed disks, and so it can't recover!
What is the correct way of resolving this?
EDIT:
After reading and thinking some more, I quite like the approach described here: https://sourceforge.net/p/snapraid/discussion/1677233/thread/034760e4/#c826, but that does not fully solve the problem.
I am just contemplating if I can augment this to save more than one snapshot using snapraid without duplicating data - maybe something using btrfs send...
Basically, what I would like is a way to tell snapraid to enter the mounted subvolumes, i.e. let it passed the error message:
WARNING! Ignoring mount point '/mnt/data/music' because it appears to be in a different device
Last edit: Siggiminator 2016-12-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SnapRAID doesn't support the Btrfs snapshots and I don't plan to add this kind of support. The problem is that SnapRAID won't be able do to the same deduplication that Btrfs is doing, resulting in a very big parity requirement.
Ciao,
Andrea
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I came across this thread as I love Snapraid but using it with BTRFS is impossible..and more and more NAS implementations are switching to btrfs as a default.
the problem is that Snapraid is ignoring any BTRFS Subvolumr even if there is no Snapshot created from it. I understand that Snapraid will not support snapshots but why can it not support Subvolumes? they could be treated like normal folders.
Last edit: Marc 2023-06-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I suppose it would make sense to support them now.
The underlying problem is that subvolumes are seen as different filesystems with independent inode spaces. This means that SnapRAID has to keep track of the subvolume ID along with the inode when searching for files by inodes.
I'll see what I can do in the next few weeks. But don't hold your breath :)
Ciao,
Andrea
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Andrea - It really would be great as otherwise many people who love Snapraid (like myself) have no choice but to drop it. After many Linux distros and Synology, also OMV is switching to BTRFS as a default filesystem and that categorically excludes us from using Snapraid. :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am new to snapraid and I have an issue that I have been unsuccessful googling (and searching this forum) for a solutions.
I have 3X 4TB drives. All are formatted to btrfs. I now understand this may introduce problems with parity but it seems like I have a snag in my config file. My snapraid.conf file is:
I have subvolumes set up on each disk. When I run syn I get:
I have not mounted the @archive -xxx subvolumes yet. Is there something obvious that I am doing wrong?
I appreciate any help anyone can give me.
Regards,
Karl
Hi,
Sorry, I figured out what as wrong. I thought that if the subvolume was unmounted it would be treated as a directory from the top level btrfs partition. According to the btrfs wiki it is actually similar to a POSIX namespace which apparently means that it is analgous to a separate partition. I modified my snapraid.conf file to:
And now snapraid picks up the volumes correctly (although now it has problems with the UUID/inodes) and calculates parity. Again, sorry for my newby-ness, I am still getting my head around the concepts of btrfs.
Regards,
Karl
Hi
I have run into the same problem, and I don't think Karl's solution is good because this will assume that d2,d3,d4 are separate disks. Now if /mnt/disk2 fails, snapraid will see it as 3 failed disks, and so it can't recover!
What is the correct way of resolving this?
EDIT:
After reading and thinking some more, I quite like the approach described here:
https://sourceforge.net/p/snapraid/discussion/1677233/thread/034760e4/#c826, but that does not fully solve the problem.
I am just contemplating if I can augment this to save more than one snapshot using snapraid without duplicating data - maybe something using btrfs send...
Basically, what I would like is a way to tell snapraid to enter the mounted subvolumes, i.e. let it passed the error message:
Last edit: Siggiminator 2016-12-28
Hi,
SnapRAID doesn't support the Btrfs snapshots and I don't plan to add this kind of support. The problem is that SnapRAID won't be able do to the same deduplication that Btrfs is doing, resulting in a very big parity requirement.
Ciao,
Andrea
I came across this thread as I love Snapraid but using it with BTRFS is impossible..and more and more NAS implementations are switching to btrfs as a default.
the problem is that Snapraid is ignoring any BTRFS Subvolumr even if there is no Snapshot created from it. I understand that Snapraid will not support snapshots but why can it not support Subvolumes? they could be treated like normal folders.
Last edit: Marc 2023-06-02
Hi Marc,
Yes, I suppose it would make sense to support them now.
The underlying problem is that subvolumes are seen as different filesystems with independent inode spaces. This means that SnapRAID has to keep track of the subvolume ID along with the inode when searching for files by inodes.
I'll see what I can do in the next few weeks. But don't hold your breath :)
Ciao,
Andrea
Thanks Andrea - It really would be great as otherwise many people who love Snapraid (like myself) have no choice but to drop it. After many Linux distros and Synology, also OMV is switching to BTRFS as a default filesystem and that categorically excludes us from using Snapraid. :(
Hello Andrea - is there an update on the BTRFS compitability ? Will there be support by Snapraid?