Hello list!
What is the status of btrfs' self-healing capabilities?
On my backup btrfs device I am currently facing back-reference errors that
neither btrfs can deal with online, nor btrfsck is able to repair it (it
bails out with an assertion). I'm going to post this as a separate post.
So
Hello list!
By backup btrfs device fails to delete snapshots with the following
backtrace:
[87332.200212] WARNING: CPU: 0 PID: 5406 at fs/btrfs/extent-tree.c:5723
__btrfs_free_extent+0x692/0xb20()
[87332.200213] Modules linked in: rfcomm af_packet bnep vmnet(O) vmblock(O)
vsock vmmon(O)
Hello,
I'm using BTRFS over LVM and after some time of usage (days or hours),
it just remounts itself, and I don't see the reason why, while it is
said to be fault-tolerant.
It is possible that I have bad sectors on the disk, though I don't
find it likely. Even then, I don't think bad sectors
On Sat, Jan 11, 2014 at 03:32:26PM +0100, MegaBrutal wrote:
Hello,
I'm using BTRFS over LVM and after some time of usage (days or hours),
it just remounts itself, and I don't see the reason why, while it is
said to be fault-tolerant.
It is possible that I have bad sectors on the disk,
2014/1/11 Hugo Mills h...@carfax.org.uk:
[60631.481913] attempt to access beyond end of device
[60631.481935] dm-1: rw=1073, want=42917896, limit=42917888
[60631.481941] btrfs_dev_stat_print_on_error: 34 callbacks suppressed
[60631.481949] btrfs: bdev /dev/mapper/vmhost--vg-vmhost--rootfs
On Sat, Jan 11, 2014 at 06:10:35PM +0100, MegaBrutal wrote:
2014/1/11 Hugo Mills h...@carfax.org.uk:
[60631.481913] attempt to access beyond end of device
[60631.481935] dm-1: rw=1073, want=42917896, limit=42917888
[60631.481941] btrfs_dev_stat_print_on_error: 34 callbacks suppressed
On Jan 11, 2014, at 10:10 AM, MegaBrutal megabru...@gmail.com wrote:
2014/1/11 Hugo Mills h...@carfax.org.uk:
It looks like you've shrunk the LV without first shrinking the
filesystem. Depending on how much you shrunk it by, the odds are
fairly good that significant chunks of the FS are
2014-01-11 18:10 keltezéssel, MegaBrutal írta:
How can I shrink the FS to the correct size right now, ensuring that I
really shrink it to the exact LV size?
btrfs fi re 10G /dev/mapper/vg-lv
lvresize -L 10G vg/lv
Grub can boot a root on lv (with appropriate initrd), but the grub
itself has
On Sat, 11 Jan 2014 19:48:55 +0100
Szalma László dbl...@dblaci.hu wrote:
2014-01-11 18:10 keltezéssel, MegaBrutal írta:
How can I shrink the FS to the correct size right now, ensuring that I
really shrink it to the exact LV size?
btrfs fi re 10G /dev/mapper/vg-lv
lvresize -L 10G vg/lv
Yeah, I used to do the way you wrote before, but in fact, G means
gigabyte (1024^3), and works the same with both tools. On smaller units
You have to watch for the rounding to extent size (4M by default).
Moreover, some could use:
btrfs fi re -2G /mount (well, I just noticed, I
After the change titled Btrfs: add support for inode properties, if
btrfs was built-in the kernel (i.e. not as a module), it would cause a
kernel panic, as reported recently by Fengguang:
[2.024722] BUG: unable to handle kernel NULL pointer dereference at
(null)
[2.027814] IP:
If the current path's leaf slot is 0, we do search for the previous
leaf (via btrfs_prev_leaf) and set the new path's leaf slot to a
value corresponding to the number of items - 1 of the former leaf.
Fix this by using the slot set by btrfs_prev_leaf, decrementing it
by 1 if it's equal to the
It is possible for the send feature to send clone operations that
request a cloning range (offset + length) that is not aligned with
the block size. This makes the btrfs receive command send issue a
clone ioctl call that will fail, as the ioctl will return an -EINVAL
error because of the unaligned
When we are looking for file extent items that intersect the cloning
range, for each one that falls completely outside the range, don't
release the path and do another full tree search - just move on
to the next slot and copy the file extent item into our buffer only
if the item intersects the
Test for an issue in btrfs send where it sent clone operations to user
space with a range (offset + length) that was not aligned with the block
size. This caused the btrfs receive command to send such clone operations
to the ioctl clone API, which would return -EINVAL errors to btrfs receive,
Hi Miguel,
On Sat, Nov 30, 2013 at 1:43 PM, Miguel Negrão
miguel.negrao-li...@friendlyvirus.org wrote:
Em 29-11-2013 16:37, Wang Shilong escreveu:
From: Wang Shilong wangsl.f...@cn.fujitsu.com
Steps to reproduce:
# mkfs.btrfs -f /dev/sda
# mount /dev/sda /mnt
# btrfs
On Jan 11, 2014, at 11:48 AM, Szalma László dbl...@dblaci.hu wrote:
but the grub itself has to be on a standard bios bootable partition (as far
as I know)
Negative. GRUB2 has support for pretty much everything out there: ZFS, Btrfs,
LVM, LUKS, md raid 0, 1, 10, 5, 6. It will boot Btrfs
On Jan 11, 2014, at 12:16 PM, Roman Mamedov r...@romanrm.net wrote:
On Sat, 11 Jan 2014 19:48:55 +0100
Szalma László dbl...@dblaci.hu wrote:
2014-01-11 18:10 keltezéssel, MegaBrutal írta:
How can I shrink the FS to the correct size right now, ensuring that I
really shrink it to the exact
After the change titled Btrfs: add support for inode properties, if
btrfs was built-in the kernel (i.e. not as a module), it would cause a
kernel panic, as reported recently by Fengguang:
[2.024722] BUG: unable to handle kernel NULL pointer dereference at
(null)
[2.027814] IP:
It is possible for the send feature to send clone operations that
request a cloning range (offset + length) that is not aligned with
the block size. This makes the btrfs receive command send issue a
clone ioctl call that will fail, as the ioctl will return an -EINVAL
error because of the unaligned
Chris Murphy posted on Sat, 11 Jan 2014 16:03:20 -0700 as excerpted:
On Jan 11, 2014, at 11:48 AM, Szalma László dbl...@dblaci.hu wrote:
but the grub itself has to be on a standard bios bootable partition (as
far as I know)
Negative. GRUB2 has support for pretty much everything out there:
21 matches
Mail list logo
