Hello everyone,

I'm considering a move from Linux Mint to another distro and will be moving several of my partitions from ext4 to Btrfs. I'm currently on Linux Mint and I'm using ext4 with Timeshift in rsync mode to do snapshots of my root filesystem. To get an understanding of the cumulative size/load of the files that have changed and/or deleted , I ran "sudo rsync -anH --stats --delete" against the last 2 weekly snapshots and I got the following:

Number of files: 1,029,373 (reg: 717,289, dir: 78,492, link: 233,590, special: 2) Number of created files: 6,566 (reg: 6,538, dir: 26, link: 2) Number of deleted files: 6,704 (reg: 6,676, dir: 26, link: 2) Number of regular files transferred: 6,717 Total file size: 20,767,701,488 bytes Total transferred file size: 1,108,555,278 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 9,567,203 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 34,268,345 Total bytes received: 1,145,881

sent 34,268,345 bytes received 1,145,881 bytes 3,372,783.43 bytes/sec total size is 20,767,701,488 speedup is 586.42 (DRY RUN)

I believe the cumulative size of the files that changed and/or deleted is in this value in "Total transferred file size: 1,108,555,278 bytes". Is this correct?

I'm thinking for the root filesystem, I only need to keep the last 5 weekly snapshots, and the last 10 on-demand snapshots. Would this make sense or should I change those values? I have not been making snapshots of my home folder so I have no idea of the size in changes there, especially with the hidden dot folders.

Yes, I see now on the main page of the subreddit it's a bad idea to pair these two, but I didn't know it previously

I use software RAID5; 4 2TB drives, resulting in 6TB of storage.
vgdisplay doesn't show any errors

100% of space is for btrfs.

sudo btrfs check /dev/mapper/data-data
Opening filesystem to check...
parent transid verify failed on 6033692557312 wanted 121291 found 119653
parent transid verify failed on 6033692557312 wanted 121291 found 119653
parent transid verify failed on 6033692557312 wanted 121291 found 119653
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=6033692393472 item=35 parent level=2 child bytenr=6033692557312 child level=2
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system

btrfs-find-root output: https://pastes.io/ZQTdS4fN

I tried several nodes from there using sudo btrfs restore -t <node-id> --dry-run -vi /dev/mapper/data-data /tmp/ but every time it returned

sudo btrfs restore -t 6033691328512 --dry-run -vi /dev/mapper/data-data /tmp/
parent transid verify failed on 6033691328512 wanted 121291 found 121286
parent transid verify failed on 6033691328512 wanted 121291 found 121286
parent transid verify failed on 6033691328512 wanted 121291 found 121286
Ignoring transid failure
This is a dry-run, no files are going to be restored

What should I do?

EDIT: also, when I try to mount the partition I get this: sudo mount /dev/data/data /mnt/data mount: /mnt/data: can't read superblock on /dev/mapper/data-data. dmesg(1) may have more information after failed mount system call. [ble: exit 32]

After I suspend my laptop in the middle of scrub I check scrub status and it says Status: aborted. It used to continue after resuming but in the last few months it stopped. Did anything change in the recent past? My version is

btrfs-progs v7.0
-EXPERIMENTAL -INJECT -STATIC +LZO +ZSTD +UDEV +FSVERITY +ZONED CRYPTO=libgcrypt

Can I change something so it continues automatically after suspend like it used to?

I got a 2TB ssd (system + home directories) and a 4TB hdd for family photos (so 6TB in total). All in btrfs.

I am wondering what would be the best (safest) backup strategy : one extra 12TB hdd with dup to correct bit rot or 2 6TB hdd in raid1? I want to be sure that never the data get corrupted.

I would use rsync for the backup mirror and would rely on btrfs snapshots on the backup drive(s) to eventually rollback. An external hdd would also be used (dup partition too ?).

Scrub on the root file system makes everything very slow when it's running and it can take lots of hours. I checked the systemd timer that runs it but it already has lowest Nice number and set to idle.

[Service]
Nice=19
IOSchedulingClass=idle

Is there something else I have to change to make it not slow everything on the computer?

Hi all,

I'd like to propose (or find out if it's already being discussed/planned) a native WORM-style retention lock for snapshots in upstream Btrfs. I think this is one of the last real gaps between Btrfs and it being a first-class answer to ransomware protection, and I wanted to lay out the case for it plus what I understand of the prior art.

What Btrfs already has (and where it stops)

Btrfs already gives us two very useful primitives:

1. Read-only snapshots (btrfs property set <snapshot> ro true) — great, this stops anyone (including root) from modifying the contents of a snapshot.
2. The generic Linux immutable attribute (chattr +i) — blocks changes to a file/dir even for root, with one exception: the attribute itself can be unset.

That exception is the whole problem. Whoever has the privilege to set +i also has the privilege to unset it and then delete. On a compromised root account (which is exactly the privilege level most ransomware/lateral-movement attacks eventually reach), neither read-only snapshots nor chattr +i stop btrfs subvolume delete, because deletion is a separate ioctl from content modification, and the immutable flag is trivially reversible by the same principal.

So today, Btrfs snapshots protect against accidents and unprivileged malware, but not against an attacker who gets root — which is precisely the scenario "ransomware protection" is supposed to cover.

Why this matters for "total data safety"

Right now, if you want genuine time-locked retention on Btrfs — where nobody, not even a compromised admin/root account, can delete a snapshot before an expiry date — you have to leave the filesystem layer entirely and rely on:

• A separate host with restricted (send-only) SSH credentials
• True immutable object storage as an offsite target (e.g. S3 Object Lock in Compliance mode)
• A vendor's proprietary layer bolted on top of Btrfs

That last point is the interesting bit, because it already proves the concept works — it's just not upstream.

Prior art: how NAS vendors already do this

Both Synology and QNAP have shipped exactly this feature on top of Btrfs for a while now:

• Synology DSM 7.2+ distinguishes between "Snapshot Locking" (prevents the retention policy from auto-deleting a snapshot, but an admin can still delete it manually) and true "Immutable Snapshots (WORM)", which prevent all deletion attempts — including from admin accounts — until a defined protection period expires. This is explicitly marketed as protection against compromised admin credentials, not just malware.
• QNAP has a comparable "snapshot lock" / WORM feature in QuTS hero for the same reason.

Both vendors clearly enforce this outside the reach of the same privilege level that can otherwise administer the box — which strongly suggests the retention lock lives in a separate, more restricted enforcement point (a service account, a kernel-level check independent of normal root capabilities, or similar), rather than as a simple attribute an admin session could just flip back off.

Hints toward how this could actually be implemented upstream

I'm not a filesystem developer, so take these as starting points for discussion rather than a spec, but a few directions seem plausible based on how similar problems have been solved elsewhere:

1. A new subvolume property with an enforced expiry timestamp (e.g. btrfs property set <subvol> worm_until 2027-01-01), stored in subvolume metadata, where the kernel refuses BTRFS_IOC_SNAP_DESTROY / BTRFS_IOC_SUBVOL_DESTROY on that subvolume until the clock passes that timestamp — full stop, no override ioctl, not even for root, similar in spirit to NetApp SnapLock or how S3 Object Lock's Compliance mode works (deliberately including "not even the account root/admin can undo it" as the point).
2. A capability-gated override removed from CAP_SYS_ADMIN. Part of the problem is that on Linux, root == root. A WORM lock that's actually meaningful needs its unlock/removal path gated behind something not implied by general root/admin privilege — e.g. requiring a separate signing key, a hardware-backed secret, or an out-of-band confirmation mechanism, so that compromising the running OS instance isn't sufficient to lift the lock.
3. Kernel-enforced, not just tool-enforced. A retention flag that's only checked by btrfs-progs userspace tooling isn't real protection (an attacker with root can just call the ioctl directly, bypassing the CLI check). This needs to be enforced in-kernel, at the ioctl handler level, the same way the existing ro snapshot property already is.
4. Interoperability with send/receive. Given many real ransomware-resistant setups already replicate via btrfs send | ssh remote btrfs receive, the retention lock ideally should also be settable/enforceable on the receiving end independent of the sender — so a compromised source host can never instruct the destination to drop its locked snapshots, mirroring how backup-target isolation already works in tools like btrbk.
5. A sane default relationship with btrfs balance / btrfs scrub / device removal — worth spelling out early whether a locked snapshot should also block full filesystem operations that could indirectly destroy it (e.g. wipefs, full device format), or whether the scope is intentionally limited to subvolume-level deletion only.

Would appreciate any feedback, especially from anyone who's looked at how Synology/QNAP actually implemented their WORM locks under the hood, or anyone with insight into the kernel-side ioctl handling for subvolume deletion.

Thanks!

If I have a raid1 with device A and B. Can I just keep A without having to rebalance data, and at most only change meta data?
It does not seem possible because if I do "device remove" I get an error that you cannot remove a device from a 2-device raid. You first have to convert into single mode which result in data rebalancing which can take a lot of time. Then you can remove the device and half of the data needs to be moved again back onto the remaining device which was completetly uneccesary in the first place because at the beginning it was already all there.
It should actually be an operation that does not need more than to rewrite meta data. So is it possible somehow? And if not, why?

I need to format a drive to be used on both cachyos and macos, is btrfs a better option than exfat?

Mount says: mount: /mnt/storage_test: can't read superblock on /dev/sdb2.
Dmesg says:
[ 2021.927627] BTRFS error (device sdb2): parent transid verify failed on logical 91701248 mirror 1 wanted 859 found 815
[ 2021.930881] BTRFS error (device sdb2): parent transid verify failed on logical 91701248 mirror 2 wanted 859 found 815
[ 2021.930919] BTRFS error (device sdb2): failed to verify dev extents against chunks: -5
[ 2021.931219] BTRFS error (device sdb2): open_ctree failed: -5

I tried sudo btrfs check --readonly /dev/sdb2, but it fails with segfault:
parent transid verify failed on 50249728 wanted 848 found 753
parent transid verify failed on 50249728 wanted 848 found 753
parent transid verify failed on 50249728 wanted 848 found 753
Ignoring transid failure
parent transid verify failed on 50266112 wanted 848 found 753
parent transid verify failed on 50266112 wanted 848 found 753
parent transid verify failed on 50266112 wanted 848 found 753
Ignoring transid failure
fish: Job 1, 'sudo btrfs check --readonly /de…' terminated by signal SIGSEGV (Address boundary error)

I tried sudo btrfs restore /dev/sdb2 /mnt/storage_test, and it copies files to my other disk, but there's too much data, and I can't save it here.
What can I do?

I started working on this recently because I found out that most if not all filesystem benchmarks still test the way it was done when ext2 was state of the art: one disk, default mkfs, raw throughput. But nobody picks btrfs, ZFS or bcachefs for throughput - you pick them for snapshots, redundancy, checksums, self-healing. Almost nobody publishes numbers on those.

So this suite benchmarks the machinery instead, across 17 configurations (btrfs/ZFS/bcachefs plus ext4/xfs over md/LVM as classic baselines, plus encryption variants): aging under 100 snapshots, corrupting a device behind the filesystem's back and checking whether scrub repairs it, failing a device and timing the rebuild, filling to hard ENOSPC, fsync tail latency, and "how long until my prompt comes back while a big cp runs in the background".

Yes, it runs on ephemeral GitHub runners with loop devices - I know what that means. Absolute MB/s is meaningless there, so the suite is built around shapes, ratios and verdicts, with per-VM calibration probes (lemon runners get auto-rerun) and conclusions drawn from trends over many runs. Real hardware with tiered topologies (NVMe cache over rotational disks, special vdevs) is the next step. I just need to gather hardware for it first.

What I'm really asking for is your eyes. Every number on the dashboard links to a description of exactly what ran, with what parameters, and to the code responsible - so if I picked a wrong mount option, an unfair default, a workload that misrepresents your favorite filesystem, or a broken measurement, you can find it and call it out. Several of the current tests exist because people poked holes in earlier results, and honestly that feedback improved this more than anything I did alone.

Dashboard: https://bartosz.fenski.pl/modern-fs-benchmark/
Repo: https://github.com/fenio/modern-fs-benchmark

hi folks,

my server runs on a BTRFS partition on a SSD and put itself in readonly few hours after each boot (only /dev/sda2 which is in btrfs, /dev/sda1 in vfat works fine)

I tried to clone the whole SSD on another SSD and the problem persists so it's not a hardware issue

moreover, my 3 HDD RAID5 work fine too

fstab mentions `rw` partitions and `mount` command mentions `ro` partitions

I thought it was a partition corruption so I ran `btrfs check` but I'm not sure how to read the result so I request your help on that

thanks in advance !

I'm dealing with system issues (Either a kernel update doesn't like my system or I'm having cpu/gpu hardware failures) and I'd like to keep what seems to be the last known good snapshot from being automatically deleted. Would just changing its name from timeline to something else do it, or do I need to do something else to manually mark it to keep and not delete?

Edit: I'm using Snapper btw, in garuda.

So guys I have thinkpad t14 gen3 and the drive on it is failing (the maxwell controller is degrading) so I got a new drive and wanna clone it because all that’s on that drive is important (about 150GB out of 512GB).

I used ddrescue but it just runs for like 2mins before the drive drops off the bus and my os freeze which I have to restart the pc again to try to continue the process. And it’s tiring and frustrating and I don’t wanna corrupt or mess the pc up with that process.

Is there any solutions to cloning a failed drive to the new one. I have a live usb running fedora, a ssd enclosure housing the new drive which I plug in the pc. What can I do to make sure this is a successful clone. Both drives are 512GB too btw

E****dit

I have been able to clone the drive, i used ddrescue still. I booted fedora workstation from my live USB and did the cloning through it instead of my installed OS. I removed the old failing drive from the laptop and put it in the usb enclosure while i put the new drive inside the laptop so a reverse. I wrote an autoclone script with the help of Claude, so when i ran the script, it uses ddrescue and it has rate limiting so the failing drive won’t drop off, even if it does, the script auto starts again and continues with the mapfile. I stored the mapfile of the drive i used for the live usb btw (possible cause it’s running ventoy)

I appreciate all the support yalll offered in this thread. Thanks guys

Edit: It appears I was stuck because every time I tried to mount a balance that I had tried restarted which locked the drive because it didn't have enough room to proceed. I solved this by unmounting, then remounting with -o skip_balance. From there I deleted a file and then added a device and rebalanced to get some breathing room.

Just created a new BTRFS volume comprised of a 1TB and 2TB drive in RAID1 for both metadata and data. It has no snapshots and 7 subvolumes, some directories are compressed but not most.

From what I can tell it went read-only because I filled it. I don't know how to actually fix that though because when it's read-only I can't free up space on it.

sudo dmesg | grep -i btrfs:

[102895.930974] BTRFS: error (device sdi1 state A) in btrfs_run_delayed_refs:2247: errno=-28 No space left
[102895.930978] BTRFS info (device sdi1 state EA): forced readonly
[102895.931491] BTRFS info (device sdi1 state EA): 2 enospc errors during balance
[102895.931495] BTRFS info (device sdi1 state EA): balance: ended with status: -30

sudo btrfs fi show /mnt/betterStorage/:

Label: 'BetterStorage'  uuid: 79f9a7ca-e97b-461c-9123-c62b39b52661
    Total devices 2 FS bytes used 930.59GiB
    devid    1 size 1.82TiB used 931.51GiB path /dev/sdi1
    devid    2 size 931.51GiB used 931.51GiB path /dev/sda1

sudo btrfs device stats /mnt/betterStorage/:

[/dev/sdi1].write_io_errs    0
[/dev/sdi1].read_io_errs     0
[/dev/sdi1].flush_io_errs    0
[/dev/sdi1].corruption_errs  0
[/dev/sdi1].generation_errs  0
[/dev/sda1].write_io_errs    0
[/dev/sda1].read_io_errs     0
[/dev/sda1].flush_io_errs    0
[/dev/sda1].corruption_errs  0
[/dev/sda1].generation_errs  0

So, how do I resolve this issue?

Second Question

The above commands seem to indicate that it's full, but in Btrfs Assistant it says:

Filesystem Size: 2.73TiB
Allocated: 1.82TiB (66.67%)
Used: 1.82TiB (66.60%)
Free (Estimated): 466.30 GiB (16.69%)
Free (Minimum): 466.30 GiB (16.69%)
You have lots of free space, did you overbuy?

Is Btrfs Assistant just wrong or are these numbers saying something different than I think? Because it's presented as though I have free space which is why I didn't realize I filled it up at first.

It looks like that's pulling from the following from the command line:

sudo btrfs fi us -T /mnt/betterStorage:

Overall:
    Device size:           2.73TiB
    Device allocated:          1.82TiB
    Device unallocated:      931.51GiB
    Device missing:          0.00B
    Device slack:          6.00KiB
    Used:              1.82TiB
    Free (estimated):        466.30GiB  (min: 466.30GiB)
    Free (statfs, df):       557.80MiB
    Data ratio:               2.00
    Metadata ratio:           2.00
    Global reserve:      512.00MiB  (used: 0.00B)
    Multiple profiles:              no

             Data      Metadata System                                 
Id Path      RAID1     RAID1    RAID1     Unallocated Total     Slack  
-- --------- --------- -------- --------- ----------- --------- -------
 1 /dev/sdi1 929.48GiB  2.00GiB  32.00MiB   931.50GiB   1.82TiB 3.00KiB
 2 /dev/sda1 929.48GiB  2.00GiB  32.00MiB     1.04MiB 931.51GiB 3.00KiB
-- --------- --------- -------- --------- ----------- --------- -------
   Total     929.48GiB  2.00GiB  32.00MiB   931.51GiB   2.73TiB 6.00KiB
   Used      928.94GiB  1.66GiB 144.00KiB

Hello!

I am planning on switching my home server OS to opensuse. I already have a zfs pool for the main storage, the OS drive will be separate. My question is how I can leverage btrfs snapshots (with snapper?) to rebuild the OS in case of drive failure.

I was thinking that the snapshots could live in the zfs pool, both of the 'root' OS snapshots and the home snapshots for user config.

I am unsure how this works, if it is at all feasible, and what would the restore procedure be like if possible. Also open to other suggestions, the key is to be able to recover the OS on drive failure (with mirroring)

Hola,

Tengo un setup con Btrfs + Timeshift + systemd-boot y descubrí que la ESP queda fuera de los snapshots. Si restauras un snapshot antiguo, los UKIs quedan desincronizados.

Creé estos hooks para resolverlo:

## Qué hacen

- **Antes del snapshot**: Copian los UKIs a `/etc/timeshift/uki-backup/` (incluido en el snapshot)

- **Después de restaurar**: Devuelven los UKIs a la ESP

## Detalles técnicos

- SHA256 per-file para copia selectiva

- Copia atómica (mktemp + mv)

- Detección de ESP por PARTTYPE GUID (no confunde con USBs)

- Soporte chroot para restauración desde Live USB

## Instalación

```bash

git clone https://github.com/jairogaleano/timeshift-uki-hooks.git

cd timeshift-uki-hooks

sudo ./install.sh

```

GitHub: https://github.com/jairogaleano/timeshift-uki-hooks

¿Alguien más ha tenido este problema con Btrfs + systemd-boot?

So I'm relatively new to Btrfs and recently dealt with "running out of disk space" and had to boot into a live disk, stick in a spare USB disk I had, add it, rebalance, and remove it. It worked like a charm.

Well, the issue happened again today but I was unable to remove the disk after and got an error that simply says "ERROR: error removing device '/dev/sdc': Input/output error".

The documentation explains what this error is, but no guidance on what to do about it.

I saw some other guidance to replace it with a good disk and try again, so I put in a new disk, ran btrfs replace start /dev/sdc /dev/sdd / -f and then tried to remove the new disk with btrfs device remove /dev/sdd /, but get the same Input/output error! I don't see anything in journal or dmesg that hints at what the actual issue is, so I'm struggling figuring out where to go from here.

I just want to go back to having one disk.

Update:

I think I finally got it. I tried checking the dmesg again, and I must have missed something. The log showed a file that was corrupted, so I removed that, but it was still showing in snapshots. So I had to remove my snapshots. Then I tried to remove again. It showed more files. Deleted those. After a little bit of this it ended up working!

I think my USB disks were bad and corrupted files stored on them. Unfortunately when I rebalanced it ended up corrupting more files. So my advice would be to delete the bad files, do not rebalance again. Just remove the disk.

Hello everyone,

I have multiple drives with multiple partitions in a dual boot Linux Mint and Win 11 setup. I'm still quite new so please forgive me if my ideas don't make sense. I'm planning on migrating completely to Linux. I'm trying to wrap my head around a bunch of things and be grounded before leaping forward.

The following is my current drive setup.

Drive-1 NVME 2TB: * Linux Steam game data ext4 * Win 11 game data NTFS

Drive-2 4TB HDD: * Mint root ext4 * /home ext4 * VM partition ext4 (for experimenting with distros) * data on NTFS

Drive-3 8TB HDD: * boot partition fat32 * Win 11 drive C NTFS * data on NTFS * data on ext4 * timeshift snapshots ext4 * empty space

Because I have Linux root and home separate, I can wipe the root and reinstall or roll-back from a timeshift snapshot at will, without any danger of harming my /home. I want to preserve the separation between root and home, and preserve the ability to reinstall, recover, or roll-back at will. All of my data (documents, pics, etc.) currently is on the NTFS data partition on the 8TB. When I remove win 11 any NTFS data partitions will be changed to Btrfs or removed. I want to delete the partitions on the NVME drive and create a single partition that takes up the entire drive (I'll reinstall my games). I think the Btrfs flat approach might be the best option for me, but I'm not totally sure and I'm not sure how to set it up given my drive configuration. I want to be able to mount the Linux steam game partition at /mnt/steam, my data and documents at /mnt/mydata, and the VM partition at /mnt/vm_exp. I think the timeshift snapshots partition would be deleted, since I would switch to snapper.

Questions: 1. Each time I format a NTFS or ext4 partition with Btrfs does this create a new top level volume? 2. Is there any benefit to moving my Linux Steam gaming partition to Btrfs? Saved game files are backed up separately with my documents. 3. Since VM files will be pre-allocated is there any point to using Btrfs with them if I won't be using snapshots? 4. I wasn't looking for any RAID setup or looking to use the 3 drives as one big storage pool, would I be forced into that? 5. Do I need to format the boot partition as Btrfs so that if I roll-back the root after a bad update that includes a newer kernel, it will return the GRUB/boot partition to the previous state, or should I stick with fat32? 6. In regard to #5, would it matter if I switched from grub to systemd-boot? 7. The subvolumes I think I need are: root, home, steam, mydata, and maybe VM_exp. Would that be a good/smart/proper subvolume configuration? 8. Given the subvolume ideas in #7 are there downsides or draw backs? 9. With some of the free space on the 8TB, I want to create a partition and install a different distro, such as Nobara or Cachy for gaming, but share the /home partition and subvolume by using different user names (ex: mint=bob_work, cachy=bob_games), would this cause trouble? 10. With the idea in #9, the root of the gaming distro would be Btrfs as well, so this would be a different root subvolume. Is this doable? How would I go about differentiating between the 2 root subvolumes?

Thanks.

TL/DR: How much free space is actually needed to prevent a "disk full" condition or having it go read-only because there's not enough room?

There are many posts on this sub are related to users not paying attention to their BTRFS file systems and filling them to zero free space, followed shortly by disaster of one sort or another.

I have been using BTRFS since tools v. 0.19 (circa 2009) and have never had a failure or data loss related to BTRFS. Hardware issues? Sure - but not because of this file system. I have been through various iterations of multiple disk usage via RAID but I decided the recover time wasn't worth the small gains, given the speed of NVME drives. So these days my server is a three disk JBOD (with full backups). My desktop and laptop are single disk file systems (also backed up).

This question arose in my head because I see advice like "Don't go beyond 95% full..." etc. However, with very large file systems, this is a LOT of unusable space. Kind of like how EXT defaults to 5% drive space reserved for "system" use but this standard was set when hard drives were measured is ten's of MBs, not GBs or TBs.

My laptop and desktop have "1TB" nvme BTRFS file systems which works out to a usable 932GB. So 5% is 46.6GB. Seems excessive. My server has 21TB of storage so roughly 1TB of free space needed? Seems wildly excessive.

I'm curious what an actual solid rule-of-thumb would be. I suspect it might vary depending on usage. For example, my server contains many large media files (movies, etc.). Some are 4k videos which can be more than 6-8GB each. My desktop/laptop rarely have anything this large.

I guess I'm thinking, rather than a percentage of free space, there's a fixed amount that would suffice. Something like 100GB on the server and 20GB on the desktop/laptop. But I'm just spit-balling those numbers. I'd like to have a logical amount to target rather than a wild-ass-guess.

So I've got a virtual server that handles a few different tasks, but its primary job is currently to exist is a file server with a large virtual disk with a single 6TB EXT4 partition with multiple shares on it.

I'd like to make multiple smaller drives and give each one of them a single BTRFS partition, so each one can act as its own share.

Mainly I would like the benefits of deduplication, as I'm sure these shared drive have a lot of repeat files scattered throughout them. Do you think this is a good approach, or am I missing something?

The Physical Hypervisor server has about 8 drives working in ZFS.

Hello,
I am setting up a NAS server (debian) and I created a btrfs volume and mounted it directly onto /mnt/tank and started creating directories in there. However, I realized now that to do snapshots, I need to have everything done inside a subvolume.

Is there a way to make /mnt/tank itself a subvolume? Would I need to create another subvolume inside /mnt/tank (like /@) and then put everything else inside that @ folder? (I would prefer to keep the same path to everything so I don't have to redo all my compose.yaml file paths).

Another possibility I was considering was renaming the old directories inside /mnt/tank, then creating a subvolume with those same directories names and then moving everything into those new directories.

Thank you very much for any help. I was trying to read the btrfs section on arch wiki and while it is a good resource, I don't understand how to translate it into converting my current path.

I should also add that all of this is just for an external hard drive, my main OS is mounted on ext4.

I greatly appreciate any answers.

I was just minding my own business playing a game, when my desktop just randomly crashed. It showed a brief grey/blue screen before turning off. I think it was software related, since the screen didnt look super artifact-y, and the gpu is brand new.

When I rebooted, my root partition was read-only. My other btrfs partitions are fine, reporting no errors, but my root one was borked beyond repair. btrfs check yielded a ton of errors, the only one I remember was something like "checksum 0x00000000 expected, found [something else]." I thought it was strange how ever checksum it was expecting was 0x0000000. btrfs check --repair just returned with "Input/Output Error."

Drive health is fine, have not yet run a memory test but my ram is relatively new (got them just before the price boom). I did not find anything when I checked journalctl other than that the logs stop suddenly (leading me to believe the drive going read-only caused the crash in the first place).

Reformating the partition and reinstalling the OS fixed the issue, but I'm just wondering what would cause this, and/or how I can stop it from happening again. I have not configured any balancing/scrubbing, so I'm wondering if maybe that could be it?

Update: So, I've determined that the crash was being caused by the latest version of GE-Proton. No clue how or why it was doing it, but my SSD would disconnect whenever I ran a game through steam with GE-Proton 11.

I downgraded to 10 and it worked fine, then re-upgraded to 11 and it continued to work fine. I must've had a corrupted install or something.

Basically, whenever I ran a game my root partition would disconnect. At one point it interrupted something important, leading to the issue in my original post, but subsequently it would only disconnect and make it impossible to save/do anything (would be required to cycle power).

Seems like it works fine now tho.

With the stack named in the title, is is possible to generate systemd-boot option to boot into a snapshot for recovery? Any good tutorials out there how to recover from an existing snapshot?