On Fri, Sep 20, 2013 at 09:53:02AM -0700, Greg KH wrote:
On Fri, Sep 20, 2013 at 06:34:39PM +0200, David Sterba wrote:
Hi stable team,
please add the following commits to 3.11 tree, they fix user visible
problems,
were tested and are now present in 3.12-rc1.
Another user has just reported this in irc on 3.11.2
kernel BUG at fs/btrfs/relocation.c:1055!
invalid opcode: [#1] SMP
Modules linked in: ebtable_nat nf_conntrack_netbios_ns
nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv6
ip6table_mangle ip6t_REJECT nf_conntrack_ipv6
Anatol Pomozov posted on Sat, 05 Oct 2013 22:14:25 -0700 as excerpted:
Actually I remembered that I set chattr +C on /var/log/journal
recursively (even for non-empty files) about a week ago, it might be
related to the crash. When I mount -orw and try to remove
/var/log/journal system hangs in
Hi,
I'm getting an error when trying to delete a device from a raid1 (data
and metadata mirrored).
btrfs filesystem show
failed to read /dev/sr0
Label: none uuid: 78b5162b-489e-4de1-a989-a47b91adef50
Total devices 2 FS bytes used 107.64GB
devid2 size 149.05GB used 109.01GB path
On Oct 6, 2013, at 5:10 AM, Alfredo Esteban aedelato...@gmail.com wrote:
btrfs device delete /dev/sdh1 /mnt/raid-data/
ERROR: error removing the device '/dev/sdh1' - Inappropriate ioctl for device
It's sortof a generic error, I think it's fixed since I haven't seen this
recently with newer
Currently the hash value used for adding an inode to the VFS's inode
hash table consists of the plain inode number, which is a 64 bits
integer. This results in hash table buckets (hlist_head lists) with
too many elements for at least 2 important scenarios:
1) When we have many subvolumes. Each
If we want to speed up this progress, i think we can split it into two parts:
1. First to search inline extent_data
2. Secondly search in extent tree to calculate (extent refs=1)
This will avoid n*n rather than n+n which is better…
(sorry for delay in reply, I was on vacation).
On 10/07/2013 11:01 AM, Wang Shilong wrote:
On 10/07/2013 10:47 AM, Anand Jain wrote:
If we want to speed up this progress, i think we can split it into two
parts:
1. First to search inline extent_data
2. Secondly search in extent tree to calculate (extent refs=1)
This will avoid n*n
This patch suppresses the following compilation warnings (mostly unused
variables):
fs/btrfs/backref.c: In function 'iterate_inode_extrefs':
fs/btrfs/backref.c:1652:6: warning: variable 'slot' set but not used
[-Wunused-but-set-variable]
int slot;
^
fs/btrfs/ctree.c: In function