Could I try your hack, pretty please? If there's any chance it could either
resolve this problem
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg10683.html ,
or at least restore the data from the filesystem, then I'd like to give it a
go. Waiting for the new btrfsck is currentl
It was pointed out by 'make versioncheck' that some includes of
linux/version.h were not needed in fs/ (fs/btrfs/ctree.h and
fs/omfs/file.c).
This patch removes them.
Signed-off-by: Jesper Juhl
---
fs/btrfs/ctree.h |1 -
fs/omfs/file.c |1 -
2 files changed, 0 insertions(+), 2 deletion
On 06/23/2011 05:11 PM, Daniel Witzel wrote:
Well still no cigar, didnt even change the error output. Thank you though for
at least trying to help. here goes the error info with your patch applied to
/fs/btrfs/disk-io.c:
mount -o ro /dev/sdf1 (same for c1,d1,etc) /btrfs (dmesg output)
[ 1647.330
Well still no cigar, didnt even change the error output. Thank you though for
at least trying to help. here goes the error info with your patch applied to
/fs/btrfs/disk-io.c:
mount -o ro /dev/sdf1 (same for c1,d1,etc) /btrfs (dmesg output)
[ 1647.330104] btrfs: open_ctree failed
[ 1683.328038] d
The recently posted EVM/IMA-appraisal patches added a new hook
evm_inode_post_init_security() to calculate the security.evm extended
attribute(xattr) and an additional call to set_xattr().
security_inode_init_security(&lsm_xattr)
set_xattr(&lsm_xattr)
evm_inode_post_init_s
Martin Steigerwald lichtvoll.de> writes:
>
> Hi!
>
> Short summary: I suspect that rsync´ing files to a newly created BTRFS
> partition with a subvolume *and* enabled space_cache triggers the error
> mentioned in the subject line of this mail. I reported this also as:
>
> Bug 38112 - btrfs:
A user reported this bug again where we have more bitmaps than we are supposed
to. This is because we failed to load the free space cache, but don't update
the ctl->total_bitmaps counter when we remove entries from the tree. This patch
fixes this problem and we should be good to go again. Thanks
On Thu, Jun 23, 2011 at 03:51:37PM -0400, Josef Bacik wrote:
> A user reported this bug again where we have more bitmaps than we are supposed
> to. This is because we failed to load the free space cache, but don't update
> the ctl->total_bitmaps counter when we remove entries from the tree. This
A user reported this bug again where we have more bitmaps than we are supposed
to. This is because we failed to load the free space cache, but don't update
the ctl->total_bitmaps counter when we remove entries from the tree. This patch
fixes this problem and we should be good to go again. Thanks
On Thu, Jun 23, 2011 at 07:37:12PM +0200, Martin Steigerwald wrote:
> Hi!
>
> Short summary: I suspect that rsync´ing files to a newly created BTRFS
> partition with a subvolume *and* enabled space_cache triggers the error
> mentioned in the subject line of this mail. I reported this also as:
>
On Wed, Jun 22, 2011 at 09:45:20PM -0400, Chris Mason wrote:
> Excerpts from Andrej Podzimek's message of 2011-06-22 18:42:28 -0400:
> >
> > Could I try your hack, pretty please? If there's any chance it could either
> > resolve this problem
> >
> > http://www.mail-archive.com/linux-btrfs@vg
Apologies if this has been asked already...
I am testing btrfs across multiple devices to see if removing them is
working smoothly yet(smallish loopback devices, a few 2GB and one 5GB)
and I always seem to hit a point where I can no longer remove a device.
I've created the filesystem as RAID
I'm game for trying it, been waiting a good bit to recover, and i have spare
drives to save the data to. Just post the git link for it if it's different then
Chris Masons git tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vge
Hi!
Short summary: I suspect that rsync´ing files to a newly created BTRFS
partition with a subvolume *and* enabled space_cache triggers the error
mentioned in the subject line of this mail. I reported this also as:
Bug 38112 - btrfs: failed to load free space cache for block group on
rsync´i
On Thu, Jun 23, 2011 at 11:01:01PM +0800, Daniel J Blueman wrote:
> On 23 June 2011 18:31, David Sterba wrote:
> (how does one follow up an email in git send-email with the message id?)
git-send-email --in-reply-to=
(if it does not ask for it) and paste identifier from mail header
In-Reply-To:
On 23 June 2011 18:31, David Sterba wrote:
> Hi,
>
> On Sun, Jun 19, 2011 at 06:53:28PM +0800, Daniel J Blueman wrote:
>> I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
>>
>> If lookup_extent_backref fails, path->nodes[0] reasonably could be
>> null, so look before lea
One of the casts in ioctl.c loses the __user annotation; cast so it is
correctly maintained.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index a3c4751..79c32d8 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2708,7 +2708,7 @@ long btrfs_ioctl_space_i
On Wed, Jun 22, 2011 at 08:13:42PM +0200, Jan Kara wrote:
> No problem. Just we have to somehow coordinate with Christoph... Either
> he can avoid touching ext4 and merge his patch set after you merge my patch
> or he can take my patch instead of his ext4 change. Since my patch touches
> only ext
Hi,
On Sun, Jun 19, 2011 at 06:53:28PM +0800, Daniel J Blueman wrote:
> I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
>
> If lookup_extent_backref fails, path->nodes[0] reasonably could be
> null, so look before leaping [2].
I think the check should be placed into b
On Tue, 21 Jun 2011 10:15:30 +0900, Tsutomu Itoh wrote:
[SNIP]
> Bad news.
>
> I changed my test environment to 'btrfs-unstable + for-linus', I encountered
> following panic without inode_cache. (in about 4 hours after test begins)
>
> btrfs: relocating block group 49161437184 flags 9
> btrfs: fo
Hi!
I scanned for relevant topics in the last two years but except for putting
a swap file on compress=lzo this march I didn´t found anything.
Does compression make sense on SSD? Or more specifically:
1) In what chunk sizes does BTRFS compress? How much data is affected when
a byte is changed
On 21.06.2011 17:12, Jan Schmidt wrote:
> On 21.06.2011 16:37, David Sterba wrote:
>> [...]
> Something is going wrong here:
>
>> Example:
>> ipath buffer and scratch are 32K, each, ie. the overly sized
>> ref_name_len will fit there:
>>
>> [ 8766.928232] btrfs: ino2name: 266 p1/
>> [ 8767.440964
When iputting the inode, We may leave the delayed nodes if they have some
delayed items that have not been dealt with. So when the inode is read again,
we must look up the relative delayed node, and use the information in it to
initialize the inode. Or we will get inconsonant inode information, it
23 matches
Mail list logo