btrfs on bcache

[d***@arcor.de]

Concerning http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018, does this "bug" still exists?

Kernel 3.14
B: 2x HDD 1 TB
C: 1x SSD 256 GB

# make-bcache -B /dev/sda /dev/sdb -C /dev/sdc --cache_replacement_policy=lru
# mkfs.btrfs -d raid1 -m raid1 -L "BTRFS_RAID" /dev/bcache0 /dev/bcache1

I still have no "incomplete page write" messages in "dmesg | grep btrfs" and the checksums of some manually reviewed files are okay.

Who has more experiences about this?

Thanks,

- dp

[Larkin Lowrey]

I've been running two backup servers, with 25T and 20T of data, using
btrfs on bcache (writeback) for about 7 months. I periodically run btrfs
scrubs and backup verifies (SHA1 hashes) and have never had a corruption
issue.

My use of btrfs is simple, though, with no subvolumes and no btrfs level
raid. My bcache backing devices are LVM volumes that span multiple md
raid6 arrays. So, either the bug has been fixed or my configuration is
not susceptible.

I'm running kernel 3.15.5-200.fc20.x86_64.

--Larkin

Post by d***@arcor.de
Concerning http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018, does this "bug" still exists?
Kernel 3.14
B: 2x HDD 1 TB
C: 1x SSD 256 GB
# make-bcache -B /dev/sda /dev/sdb -C /dev/sdc --cache_replacement_policy=lru
# mkfs.btrfs -d raid1 -m raid1 -L "BTRFS_RAID" /dev/bcache0 /dev/bcache1
I still have no "incomplete page write" messages in "dmesg | grep btrfs" and the checksums of some manually reviewed files are okay.
Who has more experiences about this?
Thanks,
- dp
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Fábio Pfeifer]

After completely loosing my filesystem twice because of this bug, I gav=
e
up using btrfs on top of bcache (also writeback). In my case, I used to
have some subvolumes and some snapshot of these subvolumes, but not man=
y
of them. The btrfs mantra "backup, bakcup and backup" saved me.

Best regards,

=46=C3=A1bio Pfeifer

Post by Larkin Lowrey
I've been running two backup servers, with 25T and 20T of data, using
btrfs on bcache (writeback) for about 7 months. I periodically run bt=

rfs

Post by Larkin Lowrey
scrubs and backup verifies (SHA1 hashes) and have never had a corrupt=

ion

Post by Larkin Lowrey
issue.
My use of btrfs is simple, though, with no subvolumes and no btrfs le=

vel

Post by Larkin Lowrey
raid. My bcache backing devices are LVM volumes that span multiple md
raid6 arrays. So, either the bug has been fixed or my configuration i=

s

Post by Larkin Lowrey
not susceptible.
I'm running kernel 3.15.5-200.fc20.x86_64.
--Larkin

Concerning http://thread.gmane.org/gmane.comp.file-systems.btrfs/310=

18, does this "bug" still exists?

Post by Larkin Lowrey

Kernel 3.14
B: 2x HDD 1 TB
C: 1x SSD 256 GB
# make-bcache -B /dev/sda /dev/sdb -C /dev/sdc --cache_replacement_p=

olicy=3Dlru

Post by Larkin Lowrey

# mkfs.btrfs -d raid1 -m raid1 -L "BTRFS_RAID" /dev/bcache0 /dev/bca=

che1

Post by Larkin Lowrey

I still have no "incomplete page write" messages in "dmesg | grep bt=

rfs" and the checksums of some manually reviewed files are okay.

Post by Larkin Lowrey

Who has more experiences about this?
Thanks,
- dp
--
To unsubscribe from this list: send the line "unsubscribe linux-bcac=

he" in

Post by Larkin Lowrey

More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-bcach=

e" in

Post by Larkin Lowrey
More majordomo info at http://vger.kernel.org/majordomo-info.html