Re: Spurious mount point

Chris Murphy: > I wasn't aware that SUSE was now using the @ location for > snapshots, or that it was using Btrfs for /home. For a > while it's been XFS with a Btrfs sysroot. Ours does use btrfs for `/' and xfs for `/home' *except* `/home/hana', which is strange and wonderful, because the

Re: Spurious mount point

Chris Murphy to Anton Shepelev: > > How can I track down the origin of this mount point: > > > > /dev/sda2 on /home/hana type btrfs > > (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana) > > > > if it is not present in /etc/fstab

Interpreting `btrfs filesystem show'

Hello, all While trying to resolve free space problems, and found that I cannot interpret the output of: > btrfs filesystem show Label: none uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8 Total devices 1 FS bytes used 34.06GiB devid1 size 40.00GiB used 37.82GiB path /dev/sda2

Re: Interpreting `btrfs filesystem show'

Hugo Mills to Anton Shepelev: >>While trying to resolve free space problems, and found >>that I cannot interpret the output of: >> >>> btrfs filesystem show >> >>Label: none uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8 >>Total devices 1 FS

Spurious mount point

Hello, all How can I track down the origin of this mount point: /dev/sda2 on /home/hana type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana) if it is not present in /etc/fstab? I shouldn't like to find/grep thoughout the whole filesystem. -- () ascii

Re: CRC mismatch

[I accdientally replied to Chris instead of the mailing list] Chris Murphy: >Is there still that O_DIRECT related "bug" (or more of a >limitation) if the guest is using cache=none on the block >device? I know nothing about it. >Anton what virtual machine tech are you using? qemu/kvm >managed

Re: CRC mismatch

I wrote: >What may be the reason of a CRC mismatch on a BTRFS file in >a virutal machine: > >csum failed ino 175524 off 1876295680 csum 451760558 >expected csum 1446289185 > >Shall I seek the culprit in the host machine on in the >guest one? Supposing the host machine healty, what >operations on

Re: btrfs check: Superblock bytenr is larger than device size

Qu Wenruo to Anton Shepelev: >>On all our servers with BTRFS, which are otherwise working >>normally, `btrfs check /' complains that >> >>Superblock bytenr is larger than device size >>Couldn't open file system >> >Please try latest btrfs-progs an

CRC mismatch

Hello, all What may be the reason of a CRC mismatch on a BTRFS file in a virutal machine: csum failed ino 175524 off 1876295680 csum 451760558 expected csum 1446289185 Shall I seek the culprit in the host machine on in the guest one? Supposing the host machine healty, what operations on

btrfs check: Superblock bytenr is larger than device size

Hello, all On all our servers with BTRFS, which are otherwise working normally, `btrfs check /' complains that Superblock bytenr is larger than device size Couldn't open file system Since am not using any "dangerous" options and want merely to analyse the system for errors without any