It's because decompressing inline extents always fails. I've fixed it
and will send the patch out in a new mail thread.
Thanks for fixing.
But seems there's bug in lib snappy code, which makes the decompressed
data doesn't quite match the original data.
Simply copy a file to a btrfs
Andi Kleen wrote:
It's because decompressing inline extents always fails. I've fixed it
and will send the patch out in a new mail thread.
Thanks for fixing.
But seems there's bug in lib snappy code, which makes the decompressed
data doesn't quite match the original data.
Simply copy a
The first four bytes is the length of all data chunks, and the first
four bytes of each chunk is the length of compressed chunk data,
even when there's only one chunk, which is the case for inline
extents.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/snappy.c |4
1 files
On Thu, Jan 12, 2012 at 04:28:47PM -0800, Andi Kleen wrote:
Here's a slightly updated version of the BTRFS snappy interface.
snappy is a faster compression algorithm that provides similar
compression as LZO, but generally better performance.
Recently the LZ4 method showed up on the real-time
When we did sysbench test for inline files, enospc error happened easily though
there was lots of free disk space which could be allocated for new chunks.
Reproduce steps:
# mkfs.btrfs -b $((2 * 1024 * 1024 * 1024)) test partition
# mount test partition /mnt
# ulimit -n 102400
# cd /mnt
#
Andi Kleen wrote:
It's because decompressing inline extents always fails. I've fixed it
and will send the patch out in a new mail thread.
Thanks for fixing.
But seems there's bug in lib snappy code, which makes the decompressed
data doesn't quite match the original data.
Simply copy a
At first I saved emails and patched them in linux-btrfs git tree, and I
got weired result. Then I pulled the snappy branch directly, and now
nothing is wrong.. Sorry for the noise.
np. Thanks for testing.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this
I've kept hitting enospc warnings of global_rsv while running defragment on
files:
btrfs: block rsv returned -28
WARNING: at fs/btrfs/extent-tree.c:5984 btrfs_alloc_free_block+0x333/0x340
[btrfs]()
...
I used a fio jobs to create a file with lots of fragments:
$ filefrag /mnt/btrfs/foobar
If there is no free space, the free space allocator will try to get space from
the block group with the degenerated profile. For example, if there is no free
space in the RAID1 block groups, the allocator will try to allocate space from
the DUP block groups. And besides that, the space reservation
Since the data profile can be degenerated(RAID10 - RAID1 - DUP, RAID0 -
SINGLE), btrfs can utilize almost the whole disk space, we can simplify the
calculation of the available space in btrfs_statfs(). The new method just
ignore the disk space(one BTRFS_STRIPE_LEN at most) that can not be used to
On 18/08/11 21:50, Chris Mason wrote:
Excerpts from Yalonda Gishtaka's message of 2011-08-17 21:09:37 -0400:
Chris Masonchris.masonat oracle.com writes:
Aside from making sure the kernel code is stable, btrfsck is all I'm
working on right now. I do expect a release in the next two weeks
On Tue, Jan 17, 2012 at 3:24 AM, Miao Xie mi...@cn.fujitsu.com wrote:
When we did sysbench test for inline files, enospc error happened easily
though
there was lots of free disk space which could be allocated for new chunks.
Reproduce steps:
# mkfs.btrfs -b $((2 * 1024 * 1024 * 1024)) test
On Tue, Jan 17, 2012 at 10:31:00AM -0600, Mitch Harder wrote:
On Tue, Jan 17, 2012 at 3:24 AM, Miao Xie mi...@cn.fujitsu.com wrote:
After applying this patch to the re-based integration branch, I was
able to clear an EFBIG error (that seemed to be related to chunk
allocation) I had
On 17.01.2012 17:35, Mitch Harder wrote:
I've been able to clear this BUG_ON() after applying Miao Xie's
[PATCH] Btrfs: fix enospc error caused by wrong checks of the chunk
on top of the rebased integration branch with a 3.2.1 kernel.
Btrfsck still shows the same inode errors 400 message,
On Tue, Jan 17, 2012 at 10:41 AM, Jan Schmidt list.bt...@jan-o-sch.net wrote:
On 17.01.2012 17:35, Mitch Harder wrote:
I've been able to clear this BUG_ON() after applying Miao Xie's
[PATCH] Btrfs: fix enospc error caused by wrong checks of the chunk
on top of the rebased integration branch
On 17.01.2012 18:03, Mitch Harder wrote:
You're correct about my original problem being with scrub. I had lost
track of the multiple ways to make the partition BUG.
I've re-run scrub, and scrub now proceeds without error also, but it
still leaves the inode 400 error from btrfsck.
I am
Greeting all,
I have multiple subvolumes on the same filesystem that are mounted with
different options in fstab.
The problem is the mount options for subsequent subvolume mounts seem to be
ignored as reflected in /proc/mounts.
$ cat /etc/fstab | grep mnt
UUID=REMOVED /mnt/a btrfs
When compiling btrfs-progs (2011-12-01) from
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git on
3.2.1-030201-generic #201201121644 SMP Thu Jan 12 21:53:24 UTC 2012 i686 athlon
i386 GNU/Linux
I get the following warnings:
ls btrfs_cmds.c
btrfs_cmds.c
gcc
On Tue, Jan 17, 2012 at 10:39 AM, Chris Mason chris.ma...@oracle.com wrote:
On Tue, Jan 17, 2012 at 10:31:00AM -0600, Mitch Harder wrote:
On Tue, Jan 17, 2012 at 3:24 AM, Miao Xie mi...@cn.fujitsu.com wrote:
After applying this patch to the re-based integration branch, I was
able to clear an
Hi Linus,
This is pull request #2 of 2, and it's actually for a branch off Al's
tree.
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git btrfs
There's one minor conflict in the ioctl.c, which I've resolved here:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git viro
Hi Linus,
This is pull request #1 of 2, since I have a viro's VFS changes too.
This one is against 3.2. Against your current tree, there's a small
conflict in fs/btrfs/ioctl.c. My pull request with viro's changes has a
tree where I've resolved the conflict.
Please pull the for-linus branch of
These two didn't make my first pull request just because I wanted to get
something out the door. I'll definitely have them in the next pull.
-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Tue, Jan 17, 2012 at 03:07:16PM +, David Summers wrote:
On 18/08/11 21:50, Chris Mason wrote:
Excerpts from Yalonda Gishtaka's message of 2011-08-17 21:09:37 -0400:
Chris Masonchris.masonat oracle.com writes:
Aside from making sure the kernel code is stable, btrfsck is all I'm
23 matches
Mail list logo
