Frederik Himpe posted on Wed, 12 Jun 2013 11:51:20 + as excerpted:
After this happened, I was unable to unlock my X session, and running
reboot in a console did not have any effect, so I had to do a hard
reset.
Not specific to this bug, but just a potentially helpful hint with such
Tomasz Chmielewski posted on Wed, 12 Jun 2013 20:53:03 +0900 as excerpted:
I've created two btrfs fileystems using these commands:
mkfs.btrfs -d raid1 -m raid1 -L btrfs1 /dev/sda5 /dev/sdb5
mkfs.btrfs -d raid1 -m raid1 -L btrfs2 /dev/sdc1 /dev/sdd1
So dual-device btrfs raid1 both
Before applying this patch, we search the csum item at first, and If the
new csums is adjoining to the existed csum item, we call btrfs_search_slot()
to grow this item. It is unnecessary because we can re-use the first search
result, if so, we can reduce the time of the csum insertion.
And
On Wed, Jun 12, 2013 at 05:51:20AM -0600, Frederik Himpe wrote:
I just encoutered this btrfs bug. When this happened, I was compiling
stuff in a qemu/kvm virtual machine running as guest on this host, so this
might be related. The guest hard disk image is a qcow2 file which has the
NO_COW
We unconditionally search for the EXTENT_ITEM_KEY for metadata during balance,
and then check the key that we found to see if it is actually a
METADATA_ITEM_KEY, but this doesn't work right because METADATA is a higher key
value, so if what we are looking for happens to be the first item in the
Thomas Koch:
On Monday, June 10, 2013 09:00:47 AM Josef Bacik wrote:
On Sat, Jun 08, 2013 at 01:14:35PM -0600, Thomas Koch wrote:
Hi,
I had a power loss on my btrfs file system during package installation
and now I found this:
code
% ls -l /var/lib/dpkg/tmp.ci
ls:
Hello,
I'd appreciate your recommendation on this:
I have three hdd with 3TB each. I intend to use them as raid5 eventually.
currently I use them like this:
# mount|grep sd
/dev/sda1 on /mnt/Datenplatte type ext4
/dev/sdb1 on /mnt/BTRFS/Video type btrfs
/dev/sdb1 on /mnt/BTRFS/rsnapshot type
On Thu, Jun 13, 2013 at 11:09:00PM +0200, Hendrik Friedel wrote:
Hello,
I'd appreciate your recommendation on this:
I have three hdd with 3TB each. I intend to use them as raid5 eventually.
currently I use them like this:
# mount|grep sd
/dev/sda1 on /mnt/Datenplatte type ext4
On Thu, Jun 13, 2013 at 3:21 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Jun 13, 2013 at 11:09:00PM +0200, Hendrik Friedel wrote:
Hello,
I'd appreciate your recommendation on this:
I have three hdd with 3TB each. I intend to use them as raid5 eventually.
currently I use them like this:
On Thu, Jun 13, 2013 at 01:45:29PM -0600, Thomas Koch wrote:
Thomas Koch:
On Monday, June 10, 2013 09:00:47 AM Josef Bacik wrote:
On Sat, Jun 08, 2013 at 01:14:35PM -0600, Thomas Koch wrote:
Hi,
I had a power loss on my btrfs file system during package installation
and now I
Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
This is an assortment of crash fixes:
Josef Bacik (3) commits (+9/-8):
Btrfs: don't delete fs_roots until after we cleanup the transaction (+1/-1)
Btrfs: init
Because they work with the same on-disk structures, and need
to perform many of the same tasks. So using the same code base
means bugs get fixed once, features get written once, there is
built-in consistency, more coverage, etc.
yes. Thanks Eric.
- Anand
--
To unsubscribe from this list:
As for skinny metadata, key.offset stores levels rather than extent length.
Signed-off-by: Liu Bo bo.li@oracle.com
---
btrfs-image.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index 739ae35..e5ff795 100644
--- a/btrfs-image.c
+++
13 matches
Mail list logo
