btrfs adventure

This forum is dedicated to advanced help and support :

Ask here your questions about advanced usage of Mageia. For example you may post here all your questions about network and automated installs, complex server configurations, kernel tuning, creating your own Mageia mirrors, and all tasks likely to be touchy even for skilled users.

btrfs adventure

Postby rolf » Jun 28th, '20, 18:39

Howdy. I've never used this filesystem and my first foray is not going smoothly. After days of manipulation with probably corner-case, off-label, non-sanctioned methods, this is more of a story and solutions or insights would be welcome but not expected.

Over the last 5 or 6 years, I've acquired several old, therefore cheap(er), DLINK 2-disk NAS and flashed them with Alt-F firmware, which is reported as offering increased functionality. I've never used any other NAS/firmware but my usage has been well-served by it.

The latest box is a DNS-327L and my adventure started with installing two 8TB ST8000DM004-2CX188 in Raid 1:
20200628_074637.png
20200628_074637.png (87.14 KiB) Viewed 110 times


The intent is to use this device for my various personal files backup and btrfs caught my attention. My current backup is on a 3.7TB drive in a USB/eSATA enclosure. If I run my backup script on my main desktop PC over the LAN to the DNS-327L, progress is slow, understandably, but also gets interrupted by an rsync error or errors periodically and has to be restarted.

I thought to connect the 4TB drive to the USB connector on the 327L but the stumbling block with that idea is that the partition is formatted reiserfs, which is not digested by Alt-F.

My next trick was to build fstransform to convert the partition to the compatible ext4 filesystem without data loss but, when I executed the command, I discovered an overlooked fatal limitation:

REISERFS file systems using format "3.5" (the default) and equal or larger than 2TB cannot be converted due to their maximum file size = 2TB - 4k: fstransform needs to create a sparse file as large as the device itself.

REISERFS file systems using format "3.6" are immune to this problem.


My next trick was to run `btrfs convert' from btrfs-progs-5.6-1.mga7, got an error that reiserfs was not supported, tried building from source, got the same error, and found the [default] configure option for source filesystems did not include reiserfs. After re-configuring with reiserfs indicated and making, the `convert' command completed on the target partition. That process was performed via ssh to another MGA7 machine on the LAN with the bare HDD connected over an eSATAp connection. However, while the filesystem is recognized as btrfs in, for example, gnome-disks, it won't mount and that machine won't boot with the disk connected. I can boot then connect the drive and it is recognized for what it is but still won't mount.

Code: Select all
Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD4000F9YZ-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 70351DDC-EC05-BD44-9127-C957CEBF8528

Device     Start        End    Sectors  Size Type
/dev/sdd1   2048 7814037134 7814035087  3.7T Linux filesystem
[root@z170i rolf]# mount /dev/sdd1 /mnt/disk
mount: /mnt/disk: wrong fs type, bad option, bad superblock on /dev/sdd1, missing codepage or helper program, or other error.
[root@z170i rolf]#


Running a grep for BTRFS on `dmesg' or `journalctl' showed problems with chunks and extents, sizes outside physical boundaries, to the best of my recollection.
There are a number of btrfs filesystem maintenance/repair commands and I cautiously worked through them, clearing the errors reported in the logs except when I try to mount. This one, iianm, got the kernel to be happy about the partition (except when mounting):

Code: Select all
btrfs rescue chunk-recover -v /dev/sdc1


About 8.5 hours later:

Code: Select all
...
Unrecoverable Chunks:

Total Chunks:           10787
  Recoverable:          10787
  Unrecoverable:        0

Orphan Block Groups:

Orphan Device Extents:

Check chunks successfully with no orphans
Chunk tree recovered successfully
[root@z170i rolf]# mount /dev/sdc1 /mnt/disk
mount: /mnt/disk: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.
[root@z170i rolf]# mount -t btrfs /dev/sdc1 /mnt/disk
mount: /mnt/disk: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.
[root@z170i rolf]#reboot


won't boot; unplug esatap 4TB drive
reboot and replug:

Code: Select all
# journalctl -f
...
Jun 27 15:53:45 z170i kernel: ata2: COMRESET failed (errno=-16)
Jun 27 15:53:49 z170i kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jun 27 15:53:49 z170i kernel: ata2.00: ATA-8: WDC WD4000F9YZ-09N20L1, 01.01A02, max UDMA/133
Jun 27 15:53:49 z170i kernel: ata2.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 32), AA
Jun 27 15:53:49 z170i kernel: ata2.00: configured for UDMA/133
Jun 27 15:53:49 z170i kernel: scsi 1:0:0:0: Direct-Access     ATA      WDC WD4000F9YZ-0 1A02 PQ: 0 ANSI: 5
Jun 27 15:53:49 z170i kernel: sd 1:0:0:0: [sdd] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
Jun 27 15:53:49 z170i kernel: sd 1:0:0:0: [sdd] 4096-byte physical blocks
Jun 27 15:53:49 z170i kernel: sd 1:0:0:0: [sdd] Write Protect is off
Jun 27 15:53:49 z170i kernel: sd 1:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Jun 27 15:53:49 z170i kernel: sd 1:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 27 15:53:49 z170i kernel:  sdd: sdd1
Jun 27 15:53:49 z170i kernel: sd 1:0:0:0: [sdd] Attached SCSI disk
Jun 27 15:53:50 z170i kernel: BTRFS: device label backup devid 1 transid 1035511 /dev/sdd1 scanned by systemd-udevd (18729)
Jun 27 15:53:58 z170i mandi[2753]: skipping known address: ...

[rolf@z170i ~]$ dmesg | grep BTRFS
[  180.321856] BTRFS: device label backup devid 1 transid 1035511 /dev/sdd1 scanned by systemd-udevd (18729)
[rolf@z170i ~]$

Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD4000F9YZ-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 70351DDC-EC05-BD44-9127-C957CEBF8528

Device     Start        End    Sectors  Size Type
/dev/sdd1   2048 7814037134 7814035087  3.7T Linux filesystem
[root@z170i rolf]# mount /dev/sdd1 /mnt/disk
mount: /mnt/disk: wrong fs type, bad option, bad superblock on /dev/sdd1, missing codepage or helper program, or other error.
[root@z170i rolf]# mount -t btrfs /dev/sdd1 /mnt/disk
mount: /mnt/disk: wrong fs type, bad option, bad superblock on /dev/sdd1, missing codepage or helper program, or other error.
[root@z170i rolf]# lsmod | grep btrfs
[root@z170i rolf]# modprobe btrfs
[root@z170i rolf]# lsmod | grep btrfs
[root@z170i rolf]#


Although, from `man btrfs-check':
Code: Select all
 Warning
           Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only
           after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other
           software or hardware bugs can fatally damage a volume.

I had spent enough time avoiding this in my free time over this past week, and I was ready to jump:
Code: Select all
[root@sysresccd /tmp]# ps -p 1015 -o args
COMMAND
btrfs check --repair -p /dev/sda1

BTW, this is being run over ssh on the secondary machine booted to systemrescuecd, which boots with the drive connected. It's been running for about 16 hours, seemingly looking at and correcting every inode. From quite a little while ago:
Code: Select all
[root@sysresccd /tmp]# ps -p 1015 -o etime
    ELAPSED
   14:49:00

btrfs-screenie1.png
btrfs-screenie1.png (170.24 KiB) Viewed 110 times

This is also the first time I've paid any attention to "inodes". Searching google for how many inodes are in a 3.7TB partition, not that I'm thinking they can be counted that way for this purpose, I'm still afraid this "repair" might not end in my lifetime. :P

Before too long, I'll stop the --repair and try another experiment. According to `man btrfs-convert':
Code: Select all
-r|--rollback
           rollback to the original ext2/3/4 filesystem if possible

That doesn't mention reiserfs and there might need to be an image created, so long shot. I need to get my backup online and might just format ext4 and run the script on the enclosure connected to my PC, as the next steps.

Thanks for reading!
rolf
 
Posts: 119
Joined: Mar 25th, '11, 02:58

Re: btrfs adventure

Postby doktor5000 » Jun 28th, '20, 23:25

Not sure if I missed an important part, but is there actually some question here, or is this more intended as a sort-of read-along ?

Apart from that, may I point out that I don't understand and you don't mention why you want to use BTRFS in the first place, or why you took this adventure.
If the NAS appliance only supports e.g. ReiserFS and maybe ext4, I'd go with one of those that are natively supported.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 15830
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: btrfs adventure

Postby rolf » Jun 28th, '20, 23:33

I thought the first sentence explained my intent. Starting with a clean slate of new NAS + disks, except for an existing backup 3.7TB partition on reiserfs, which is *not* supported on the NAS, I thought to try something different in btrfs, which has a lot of glowing reviews, potentially moving on from my favorite of 20 years, reiserfs. Also, I've also shied away from any sort of RAID and, in pursuit of a more reliable backup, added that novelty to the experiment.
rolf
 
Posts: 119
Joined: Mar 25th, '11, 02:58

Re: btrfs adventure

Postby doktor5000 » Jun 29th, '20, 17:14

Ahh OK, got the whole picture now.

For a suggestion, I'd probably connect one of the 8TB disks to the box that has the 3.7TB disk with your current backup, then copy everything locally to the 8TB disk, then afterwards put the 8TB disk into the NAS and start building the RAID.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 15830
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: btrfs adventure

Postby rolf » Jul 5th, '20, 02:05

Thanks for the suggestion. That original 3.7TB reiserfs /backup partition has already suffered the failed application of a btrfs-convert binary I had to compile for reiserfs support. The filesystem was created but could not be mounted. Then, I tried various new-to-me btrfs maintenance operations over several days that finished up with a last-ditch `btrfs repair' that ran for 2-1/2 days without completing. This much was in my first post. The referenced "rollback" to reiserfs, not surprisingly, also failed. I have since formatted that disk in ext4 and re-populated it with my rsync backup script, so I have that, at least.

WRT the btrfs raid 1 on the NAS, running my script on that resulted in slow, halting transfers and rsync errors that caused the script to abort. After some time of re-starting the script, I decided to re-make the raid 1 in ext4. Running the script does not stop but is still very slow to transfer. I calculated an average over the past 32 hours of about 3.26 MB/sec. (See Alt-F discussion linked below). My suspicions, now, pertain to reports of slow throughput from many users attributed to the Shingled Magnetic Recording technology used on such large disks that would seem suitable for NAS to most consumers.

There is a discussion of this issue at the google group for the Alt-F firmware I use on these DNS NAS and I have written more there: https://groups.google.com/forum/#!msg/a ... O_ahqfCQAJ

It's too much to repeat here. If there might be some interest to continue, perhaps some of the info could be imported to this thread or another, if appropriate. Otherwise, I've restored my original backup capacity and will tinker with this new adventure as somewhat limited time allows, without urgency.

Thanks for your help.
rolf
 
Posts: 119
Joined: Mar 25th, '11, 02:58


Return to Advanced support

Who is online

Users browsing this forum: No registered users and 1 guest

cron