When we defrag a file, whose size can be fit into an inline extent,
with compression enabled, the compress type is set to be
fs_info->compress_type, which is 0 if the btrfs filesystem is mounted
without compress option. This leads to oops.
Reported-by: Daniel Blueman
Signed-off-by: Li Zefan
---
On Monday, March 28, 2011 09:39:26 AM Chris Mason wrote:
> Excerpts from Chris Mason's message of 2011-03-27 21:30:20 -0400:
> > Excerpts from Chris Mason's message of 2011-03-27 14:10:46 -0400:
> > > Excerpts from Li Dongyang's message of 2011-03-24 06:24:24 -0400:
> > > > Dear list,
> > > > This
Hi everyone,
The kernel.org mirror is making me pay for a mistake in my push last
night. I'm still waiting for it to update the mirrors with the correct
commits, so I've got the proper sha down below.
Linus, I've pushed out two branches for you, for-linus and
for-linus-unmerged
git://git.kernel
2011-03-22 18:06:29 -0600, cwillu:
> > I can mount it back, but not if I reload the btrfs module, in which case I
> > get:
> >
> > [ 1961.328280] Btrfs loaded
> > [ 1961.328695] device fsid df4e5454eb7b1c23-7a68fc421060b18b devid 1
> > transid 118 /dev/loop0
> > [ 1961.329007] btrfs: failed to re
2011-03-23 12:13:45 +0700, Fajar A. Nugraha:
> On Mon, Mar 21, 2011 at 11:24 PM, Stephane Chazelas
> wrote:
> > AFAICT, compression is enabled at mount time and would
> > only apply to newly created files. Is there a way to compress
> > files already in a btrfs filesystem?
>
> You need to select
Hi,
Chris, you did not add my sign-of on the unaligned fix I've posted, nor
the tested-by or reported-by. Looking again into the mail, it seems like
some automated-misprocessing picked the first part of the mail altough
there was properly formated patch after '--' marker (and I've verified
this is
When I moved the orphan adding to btrfs_truncate I missed the fact that during
orphan cleanup we just add the orphan items to the orphan list without going
through btrfs_orphan_add, which results in lots of warnings on mount if you have
any orphan items that need to be truncated. Just remove this
On Mon, Mar 28, 2011 at 5:08 AM, Chris Mason wrote:
>
> Linus, I've pushed out two branches for you, for-linus and
> for-linus-unmerged
Thanks. I took the unmerged one, because I do like to see what's going
on. But I did end up verifying the end result against your merge, and
it ended up identica
David Sterba wrote:
> Hi,
>
> Chris, you did not add my sign-of on the unaligned fix I've posted, nor
> the tested-by or reported-by. Looking again into the mail, it seems like
> some automated-misprocessing picked the first part of the mail altough
> there was properly formated patch after '--' m
On 03/28/2011 08:59 AM, Chris Mason wrote:
> Excerpts from Chris Mason's message of 2011-03-26 08:12:04 -0400:
>> Excerpts from liubo's message of 2011-03-24 07:18:59 -0400:
>>> Tracepoints can provide insight into why btrfs hits bugs and be greatly
>>> helpful for debugging, e.g
>> This is really
On Mon, Feb 14, 2011 at 10:22 AM, Chris Mason wrote:
> Excerpts from Andrew Lutomirski's message of 2011-02-11 19:35:02 -0500:
>> On Fri, Feb 11, 2011 at 10:44 AM, Chris Mason wrote:
>> >
>> > We can tell more if you post the full traces from latencytop. I have a
>> > patch here for latencytop
Hi Miao,
On Sun, 27 Mar 2011 20:27:30 +0800
Miao Xie wrote:
> Changelog V1 -> V2:
> - modify the explanation of the deadlock.
> - clear __GFP_FS flag in the free space's page cache.
I think this is also needed on top of your V5 patch to avoid a recursion. Could
you
review it and give your Sign
On tue, 29 Mar 2011 14:48:05 +0900, Itaru Kitayama wrote:
> Hi Miao,
>
> On Sun, 27 Mar 2011 20:27:30 +0800
> Miao Xie wrote:
>
>> Changelog V1 -> V2:
>> - modify the explanation of the deadlock.
>> - clear __GFP_FS flag in the free space's page cache.
>
> I think this is also needed on top of
13 matches
Mail list logo
