On 08/15/13 01:16, Zach Brown wrote:
qgroup.c:82:23: warning: memcpy with byte count of 0
qgroup.c:83:23: warning: memcpy with byte count of 0
The inheritance wasn't copying qgroups[] because a confused sizeof()
gave 0 byte memcpy()s. It's been like this for the year since it was
merged,
hi all
I moved my btrfs filesystems around using btrfs replace and now I have errors
(lots of errors)
[63724.419779] BTRFS info (device dm-12): csum failed ino 9340 off 8192 csum
717036259 private 94677163
: root; time btrfs scrub start -Bd /disks/backups
scrub device /dev/dm-11 (id 1)
On Aug 18, 2013, at 1:12 PM, Stuart Pook slp644...@pook.it wrote:
6 btrfs filesystem resize 580g .
You first shrank a 2TB btrfs file system on dmcrypt device to 590GB. But then
you didn't resize the dm device or the partition?
9 time btrfs balance start -musage=1 -dusage=1 . time
hi Chris
thanks for your reply. I was unable to save the filesystem. Even after deleting
all but 4Gb I still had too many errors so I just reformated the device. I'm
glad that it was my backups and not my data.
On 18/08/13 23:43, Chris Murphy wrote:
On Aug 18, 2013, at 1:12 PM, Stuart Pook
On Aug 18, 2013, at 4:35 PM, Stuart Pook slp644...@pook.it wrote:
You first shrank a 2TB btrfs file system on dmcrypt device to 590GB.
But then you didn't resize the dm device or the partition?
no, I had no need to resize the dm device or partition.
OK well it's unusual to resize a file
This is just a comment from someone following all of this from the
sidelines.
And that is that I see so much going on here with this procedure that is
scares me. Once a single operation reaches a certain degree of
complexity I get really scared because all it takes is a single misstep
and
Hi,
On thu, 15 Aug 2013 20:42:42 -0400, Jeff Mahoney wrote:
Commit 615f2867 (Btrfs-progs: cleanup similar code in open_ctree_*
and close_ctree) introduced a regression in btrfs-convert.
Wang has fixed this problem.
[PATCH] Btrfs-progs: fix wrong arg sb_bytenr for btrfs_scan_fs_devices()
On wed, 14 Aug 2013 11:41:00 -0400, Josef Bacik wrote:
I added a patch where we started taking the ordered operations mutex when we
waited on ordered extents. We need this because we splice the list and
process
it, so if a flusher came in during this scenario it would think the list was
