Btrfs Status?

[kiwimonk]

Any word on the status of Btrfs? I know synology now supports it on RC18015xs+, RS18016xs+, so it should be possibly to get working with XPEnology with a few tweaks I'm hoping!

[pigr8]

The executable is in /usr/syno/bin/scemd (my fault)

 

I added the support_dr_snap="yes" to the /etc.defaults/synoinfo.conf

I get the Data Protection Manager now. It is a GUI for managing iscsi LUN snapshots. That was not what I was looking for: a GUI for managing BTRFS snapshots.

 

the gui is the same for managing the snapshots.

 

i added the lines in synoinfo.conf but it keeps crashing when i try to create a new volume and disk group, how did you manage to create it?

[benji30]

I added the entries support_btrfs="yes" and support_dr_snap="yes" to both /etc/synoinfo.conf and /etc.defaults/synoinfo.conf (just to be sure)

I do not use disk groups.

 

I tried it on a real DS1813+ where I could create a btrfs volume on multiple disks and allocate shares on it. I can create and delete directories from filemanager From the cli I can take snapshots and delete them (not from the gui.)

 

On a virtualbox instance I created an ext4 volume (volume2). After that I used the cli to look up where volume2 was mounted. (in my case /dev/vg1001/lv) I removed volume2 and recreated it as a btrfs file system in storage manager. (Storage Manager completes with a message that volume2 is crashed.)

A manual mount "mount /dev/vg1001/lv /volume2" from the cli does the trick. (the manual mount has to be repeated after every reboot of the VB DSM instance)

 

The DS1813+ btrfs volume mounts automatically after a reboot of the system.

[davioxx]

anyone using this btrfs workaround as a stable filesystem? any issues appart from mount issues?

[optic]

thanks for the info on manual mounting, that is extremly interesting

 

benji30: any chance you could provide us with a few commandline examples to create the btrfs volume please? (thank you!!)

[benji30]

From a VirtualBox DSM system:

 

Storage Manager -> Create Volume

 

Choose all options you would like to use on the designated btrfs volume.

Create the volume with "Traditional volume format (ext4)

 

After the creation of the new volume, enter the CLI and type:

 

mount | grep volume

 

It will give you the devicenames of all volumes, including the freshly created one.

in my case:

 

/dev/vg1001/lv on /volume2 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl)

 

make a note of the device name (your's could be different)

 

Now remove the newly created volume from the storage manager and recreate the volume with a btrfs filesystem. (It is important to keep all other settings in the creation process the same. You might end up with a different devicename and corrupt data on other volumes when mounting)

 

The creation process will end with a "Crashed" message.

 

In the CLI enter:

 

mount

 

in my case:

 

mount /dev/vg1001/lv /volume2

 

In the storage manager the crashed Volume will return to a "Normal" status and can be used now.

 

After every reboot the btrfs volume has to be manually mounted. (This is due to the workarounds in XPenology. On a DS1813+ it mounts automatically after creation and the volume survives reboots.)

 

The brtfs-volume can be managed from the cli (btrfs --help comes to the rescue)

I do not recommend tinkering with disks like adding or removing disks to/from the volume. It could confuse DSM, ending in system corruption

 

A share on the btrfs volume is a btrfs subvolume and can be managed from the CLI, including snapshotting.

[optic]

thanks alot benji30! thats a really helpful description.

 

i wonder if there is some kind of way around this or possible to automaticly boot it via script.

[pigr8]

i managed to get the same results but it's not fully working.. here is my recap:

 

1. first thing, upgrading 5.2-5592 to update3 brings some new stuff to btrfs.ko i think

 

 

2. volume creation works but mount is crashing at boot, manually mount makes volume online again.

 

 

3. shr expansion works adding a disk and btrfs filesystem grows so handlig here is ok

 

 

4. data protection is enabled while creating a new share in the volume (i suppose it's snapshot ability)

 

 

5. folder is visible as it should in file manager and #snapshot is here too

 

 

6. data protection manager handles the share snapshots and let you manually snap or schedule it

 

 

7. creating the first snapshot gives error to all users (even SYSTEM)

 

 

 

 

i wanted to try to make via ssh a manual snapshot and see if DPM handles it but i'm stuck with it :\

[benji30]

The snapshot and advanced data protection items don't show up in my DSM.

What are your modifications to /etc/synoinfo.conf and /etc.defaults/synoinfo.conf (or other settings files?)

 

I found I had forgotten to make the entries support_share_snapshot in the synoconfig files.

 

The snapshots fail because of apparmor. The dmesg entry:

 

type=1400 audit(1441125222.962:2): apparmor="DENIED" operation="mkdir" parent=15715 profile="/usr/syno/synoman/webman/index.cgi" name="/usr/syno/synoman/synohdpack/tmp/" pid=15749 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

 

What is the way to add a definition to apparmor?

Edited September 1, 2015 by Guest

[pigr8]

support_btrfs="yes"
support_dr_snap="yes"
support_share_snapshot="yes"
supportraidgroup="yes"

 

i added the first 3 and set "yes" to the last one that was "no"

[pigr8]

i think btrfs is fully included in 5.2 it only needs to be enabled by default and xpenology has to fix everything to use is properly

[benji30]

With the entries

 

support_btrfs="yes"

support_dr_snap="yes"

support_share_snapshot="yes"

 

in /etc/synoinfo.conf and /etc.default/synoinfo.conf the btrfs filesystem works and supports snapshotting on my ds1813+

 

I think with some further modifications in the XPenology workarounds it could be enabled there too!

[pigr8]

With the entries

 

support_btrfs="yes"

support_dr_snap="yes"

support_share_snapshot="yes"

 

in /etc/synoinfo.conf and /etc.default/synoinfo.conf the btrfs filesystem works and supports snapshotting on my ds1813+

 

I think with some further modifications in the XPenology workarounds it could be enabled there too!

 

excellent maybe next release of xpenology could bring us a fix

[rikadoo]

With the entries

 

support_btrfs="yes"

support_dr_snap="yes"

support_share_snapshot="yes"

 

in /etc/synoinfo.conf and /etc.default/synoinfo.conf the btrfs filesystem works and supports snapshotting on my ds1813+

 

I think with some further modifications in the XPenology workarounds it could be enabled there too!

 

excellent maybe next release of xpenology could bring us a fix

With the entries

 

support_btrfs="yes"

support_dr_snap="yes"

support_share_snapshot="yes"

 

in /etc/synoinfo.conf and /etc.default/synoinfo.conf the btrfs filesystem works and supports snapshotting on my ds1813+

 

I think with some further modifications in the XPenology workarounds it could be enabled there too!

 

The best is probably a XPenoboot boot based on the new Synology product RS18016xs+ We will see i hope the developers of xpenoboot will make btrfs workable for use at xpenology NAS systems.

[pigr8]

i don't think the problem needs another rebase of xpenology, the genuine ds3615xs is probably working fine with btrfs like benji30's ds1813+ out of the box with some modification at the *.conf and i think with the next big update Synology will bring btrfs to all latest gen NAS.

[davioxx]

looking forward for official Xpenology BTRFS support, it is a really nice filesystem I've seen an implementation in rockstor.com and it is starting to shape up, with the advanced applications and usability of DSM and that excellent filesystem we would have a very resilient NAS.

[fakeman]

I have a spare machine with 2 x 4TB disks, just tried with 5592 Update 4 (direct update from UI, it works!)

It has a /dev/md2 device (mirror), same as previous posts, the volume crashed immediately, mounting it to /volume1/ by command and then it works.

I've chosen "enable enhanced data integrity" in options but no idea how it can enhance data integrity.

 

And I tried to transfer about 10GB files from my PC using FTP, everything looks good, we just need a way to figure out how to automount it during reboot.

[wenlez]

The snapshot and advanced data protection items don't show up in my DSM.

What are your modifications to /etc/synoinfo.conf and /etc.defaults/synoinfo.conf (or other settings files?)

 

I found I had forgotten to make the entries support_share_snapshot in the synoconfig files.

 

The snapshots fail because of apparmor. The dmesg entry:

 

type=1400 audit(1441125222.962:2): apparmor="DENIED" operation="mkdir" parent=15715 profile="/usr/syno/synoman/webman/index.cgi" name="/usr/syno/synoman/synohdpack/tmp/" pid=15749 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

 

What is the way to add a definition to apparmor?

 

 

I have the same logs too. THis gets written to the kern.log every minute. any one know how to disable this? I am running xepnology 5.2 5592 Update4, under virtualbox.

[optic]

this (btrfs) is basicly the one thing that would make xpenology perfect at this stage

has there been any comments anywhere else anyone knows of about the current state of btrfs?

[davioxx]

DSM 6.0 will bring BTRFS to more devices and apparently the version on which xpenology is based on is included, we will need more information for official release.

 

also does anyone knows what happened to xpenology.nl?

[grogi]

this (btrfs) is basicly the one thing that would make xpenology perfect at this stage

has there been any comments anywhere else anyone knows of about the current state of btrfs?

 

Most users when talking about BTRFS they usually care about following things: data integrity protection (bit rod protection), snapshots and integrated volume management.

 

The volume in DSM is built on top of disk group, which takes care of redundancy. That nullifies the BTRFS-integrated volume management and ability to add/remove devices from the volume. DSM comes with SHR, which provides some of those features too - but not as flexible as BTRFS.

 

A slightly different way of defining volumes would need to be introduced to leverage BTRFS here. Additional options for RAID level when would work great: one would create a BTRFS diskgroup and volumes inside it - implemented as BTRFS subvolumes. Creating a BTRFS volume on top of RAID diskgroup does not bring many features, except for immediate snapshots. This has however one disadvantage - one cannot create effective LUNs on top of such BTRFS diskgroup...

 

So, currently BTRFS sees only one block device. Now, if one wants to guarantee the integrity, a RAID1 profile for both data and metadata would have to be used in BTRFS, reducing the usable capacity by 50% - all on top of already redundant raid. Unfortunately BTRFS does know nothing about the underlying hardware, so it cannot utilize it more efficiently.

 

Snapshots are still there, regardless of the underlying layer.

 

So, it seems the support for BTRFS in 5.2 does not make much sense at the moment. I trust that DSM 6.0 will come with much more comprehensive support, with post 3.19 kernel as well.

[blindpoison]

Thank you so much for your advice!

 

I successfully set a btrfs volume following your guide.

 

However, the volume does not accept uploaded files via windows network (SMB)

with the message that there is not enough space(actually I dont know the exact message because

I use korean language).

 

This problem does not appear when I create a volume as ext4!

 

Do you have any suggestion for this?

Thank you in advance.

[Fridel]

Hello,

 

I also create a working Xpenology DSM 6 with actual Pat File on an normal Intel machine.

 

Same procedure - after reboot - the volume crashed and I fix this with the task manager, running a task as root with "mount /dev/mapper-vg1 /volume1" and the crashed volume will become GOOD.

 

But all the "Shared Folders" are not present - via SSH I can see all the "subvolumes" and all the files in it.

 

At the moment, when I reboot the machine, I create the shared folders (same name and para) via the WEB ui again and all my files become present.

 

Is is possible to mount also the subvolumes as "Shared Folders" with a mount or btrfs command?

[JoeOIVOV]

 

Is is possible to mount also the subvolumes as "Shared Folders" with a mount or btrfs command?

 

 

 

Have you figured this out yet? This is exactly the point I'm at as well. I need a command that will create the missing shares at reboot to create a seamless experience with DSM 6 on baremetal.