21:54, Chris Mason wrote:
> 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.
>
> Thanks Andi, I'
> 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 btr
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.
>>
>
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
---
fs/btrfs/snappy.c |4
1 files changed, 4 insertions(+
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))
# mount /mnt
# ulimit -n 102400
# cd /mnt
# sysbench --num-threads=1 --test
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.
>>
>
> 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 th
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
/mnt/bt
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 t
On 18/08/11 21:50, Chris Mason wrote:
Excerpts from Yalonda Gishtaka's message of 2011-08-17 21:09:37 -0400:
Chris Mason 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 that
can recov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I submitted some patches a few weeks ago to fix this so you specify
the device normally instead of looking up the internal devid and
passing it as an undocumented prefix to the size parameter. Hopefully
they can get merged sometime soon.
On 1/14/2012
On Tue, Jan 17, 2012 at 3:24 AM, Miao Xie 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))
> # mount /mnt
>
On Mon, Jan 16, 2012 at 6:10 PM, Mitch Harder
wrote:
> On Tue, Jan 3, 2012 at 11:35 AM, Mitch Harder
> wrote:
>> I've recently run into a kernel "NULL pointer dereference" while
>> scrubbing a partition that had picked up error.
>>
>
> I'm no longer getting the NULL pointer panic on this partitio
On Tue, Jan 17, 2012 at 10:31:00AM -0600, Mitch Harder wrote:
> On Tue, Jan 17, 2012 at 3:24 AM, Miao Xie 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 previously been receiving
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 messa
On 17.01.2012 17:41, Jan Schmidt wrote:
> However, I'm not sure whether it's worth investigating any further, as
> the bug seems to be readahead-related which is presumably being replaced
> soon.
Ah, and it's solved anyway, so scratch that :-)
-Jan
--
To unsubscribe from this list: send the line
On Tue, Jan 17, 2012 at 10:41 AM, Jan Schmidt 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 with a 3.2.1 kerne
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
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= /mnt/a btrfs
subvol=a,defaults,
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 -Wp,-MMD,./.btrfs_cm
On Tue, Jan 17, 2012 at 10:39 AM, Chris Mason 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 wrote:
>>
>> After applying this patch to the re-based integration branch, I was
>> able to clear an EFBIG error (that seemed to be rel
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
I
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 t
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 Mason oracle.com> writes:
> >>
> >>>
> >>>Aside from making sure the kernel code is stable, btrfsck is all I'm
27 matches
Mail list logo