Access to openSUSE BTRFS partitions

[JanJans640]

Hi everyone, Maybe someone can help me. I have the following situation. Dual boot with windows 11 and openSUSE Tumbleweed. After installing WinBTRFS I can see the /home folder in WinBTRFS, but this folder is empty. When I look for hidden files, I can see some of the files. All other folder are not there. I'm not use how SUSE is setting op the disk, but I think they are using "subpartitions"or so. Is there someone who can help me to make these files show up in win11 with WinBTRFS?

Thanks

[JanJans640]

<I'm not how SUSE is setting op the diskpartitions, but I think they are using "subvolumes"or so. Is there someone who can help me to make these files show up in win11 with WinBTRFS?

[maharmstone]

I don't know how SuSE have everything set up, but it might be that they're bind-mounting subvolumes into /home and changing the default subvolume. Is there a hidden directory \$Root that your subvolumes are hiding in?

[micahwelf]

Please forgive my likely ignorance. I've been following this project with high hopes of seeing BTRFS become a high quality filesystem that works on multiple operating systems. I'm on Arch Linux and unfortunately must use exFAT for most of my inter-OS needs (I use macOS, Linux, and more rarely MS Win**). I love Windows 7, but I've seen Microsoft resume their con-artist-out-of-a-dark-alley level of customer consideration a couple years after releasing Windows 10 and want no part of it.

Oh, Anyway, the reason I was replying on this thread is to mention that, at least on Linux, subvolumes show as directories if the file system is mounted to a parent subvolume, so you should be able to find all of the file system structure by mounting the subvolume ID 5 or subvolume path "/" (don't know if you need to enter "\" from the winBTRFS setup). As long as you hit the root of the file system, everything should show.

I have my suspicion that something went wrong based on your description, though. I haven't used SUSE Linux for years, but last I knew they didn't do anything quite so strange as bind-mount anything inside the /home path. I recommend you not store anything too important on that file system while it is behaving oddly. I've crashed BTRFS a few times in the last decade. The recovery tool was great, but required an enormous amount of spare storage space that most people don't have handy. Good luck!

Micah Waddoups @.***

On Sat, May 4, 2024 at 11:55 AM Mark Harmstone @.***> wrote:

I don't know how SuSE have everything set up, but it might be that they're bind-mounting subvolumes into /home and changing the default subvolume. Is there a hidden directory \$Root that your subvolumes are hiding in?

— Reply to this email directly, view it on GitHub https://github.com/maharmstone/btrfs/issues/657#issuecomment-2094326705, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGJF6KHLF56SXTU7LCSICDZAUOHPAVCNFSM6AAAAABHGWE5QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUGMZDMNZQGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[patrolez]

This is the output of command "mount" in openSUSE Tumbleweed:

/dev/nvme0n1p1  on  /                       type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=266,subvol=/@/.snapshots/1/snapshot)
/dev/nvme0n1p1  on  /.snapshots             type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=265,subvol=/@/.snapshots)
/dev/nvme0n1p1  on  /boot/grub2/i386-pc     type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=264,subvol=/@/boot/grub2/i386-pc)
/dev/nvme0n1p1  on  /home                   type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=262,subvol=/@/home)
/dev/nvme0n1p1  on  /boot/grub2/x86_64-efi  type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=263,subvol=/@/boot/grub2/x86_64-efi)
/dev/nvme0n1p1  on  /opt                    type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=261,subvol=/@/opt)
/dev/nvme0n1p1  on  /root                   type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=260,subvol=/@/root)
/dev/nvme0n1p1  on  /srv                    type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=259,subvol=/@/srv)
/dev/nvme0n1p1  on  /usr/local              type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@/usr/local)
/dev/nvme0n1p1  on  /var                    type  btrfs  (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@/var)
/dev/nvme0n1p2  on  /run/media/pat/Data     type  btrfs  (rw,nosuid,nodev,relatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/)

So as we can see the eventual root is being made from multiple subvolumes composition: 1) /@/.snapshots/1/snapshot … 2) /@/home …

Which composition is being determined via /etc/fstab mechanism, so I guess it is not being covered within the WinBTRFS driver.