Qiang Zhu wrote:
> hi
>
> In the end part of “set_extent_bit”，I found when err occurs ，there is no
> operate to free "prealloc" which have been allocated in
> "alloc_extent_state_atomic"
> this may lead a menory leak when "set_state_bits" failed.
No, it won't. 'prealloc' has been inserted into
The variable 'last_index' is calculated in the __btrfs_buffered_write
function and passed as a parameter to the prepare_pages function,
but is not used anywhere in the prepare_pages function.
Remove instances of 'last_index' in these functions.
Signed-off-by: Mitch Harder
---
fs/btrfs/file.c |
2011/7/12 Chris Mason :
> Excerpts from Mitch Harder's message of 2011-07-11 15:38:45 -0400:
>> 2011/7/11 João Eduardo Luís :
>> > Hello.
>> >
>> > Am I reading the code the wrong way, or is the 'last_index' variable in
>> > '__btrfs_buffered_write()' (and previously used in
>> > 'btrfs_file_aio_
On 07/12/2011 11:20 AM, Christian Brunner wrote:
> 2011/6/7 Josef Bacik :
>> On 06/06/2011 09:39 PM, Miao Xie wrote:
>>> On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
I got a lot of these when running stress.sh on my test box
This is because use_block_rsv() is havi
2011/6/7 Josef Bacik :
> On 06/06/2011 09:39 PM, Miao Xie wrote:
>> On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
>>> I got a lot of these when running stress.sh on my test box
>>>
>>>
>>>
>>> This is because use_block_rsv() is having to do a
>>> reserve_metadata_bytes(), which shouldn't h
2011/5/10 David Sterba
>
> Hi,
>
> I've hit this lockdep warning, 2.6.39rc6. Single btrfs partition, 30GB,
> filled with 2GB, "compress-force=lzo", warning trigered after normal copy+du.
> Happened only once.
>
> [Might be a false positive.]
Hi,
I have a similar error with 3.0-rc6.
OS: Fedora 1
Excerpts from Mitch Harder's message of 2011-07-11 15:38:45 -0400:
> 2011/7/11 João Eduardo Luís :
> > Hello.
> >
> > Am I reading the code the wrong way, or is the 'last_index' variable in
> > '__btrfs_buffered_write()' (and previously used in
> > 'btrfs_file_aio_write()') irrelevant?
> >
> > It
2011-07-11 10:01:21 +0100, Stephane Chazelas:
[...]
> Same without dmcrypt. So to sum up, BUG() reached in btrfs-fixup
> thread when doing an
>
> - rsync (though I also got (back when on ubuntu and 2.6.38) at
> least one occurrence using bsdtar | bsdtar)
> - of a large amount of data (with a la
On Tuesday 12 of July 2011 00:22:01 Hugo Mills wrote:
> On Mon, Jul 11, 2011 at 09:11:24PM +0200, Jan Schmidt wrote:
> > On 07/11/2011 08:38 PM, Goffredo Baroncelli wrote:
[snip]
> > > A script extracts from the comment in the source both:
> > > - the text for the man page
> > > - the text for the
On Tue, Jul 12, 2011 at 12:40:06PM +0200, Hubert Kario wrote:
> On Monday 11 of July 2011 17:13:13 Jan Schmidt wrote:
> > Hi Hubert,
> >
> > I have to admit I did not recognize this patch but now Hugo is forcing
> > me to use the "detailed help messages" and I've got an improvement to
> > suggest:
On Monday 11 of July 2011 17:13:13 Jan Schmidt wrote:
> Hi Hubert,
>
> I have to admit I did not recognize this patch but now Hugo is forcing
> me to use the "detailed help messages" and I've got an improvement to
> suggest:
>
> On 23.01.2011 13:42, Hubert Kario wrote:
[snip]
> > { do_defrag,
On Tue, Jul 12, 2011 at 02:47:41AM +0200, krz...@gmail.com wrote:
> dd if=/dev/null of=img5 bs=1 seek=2G
> dd if=/dev/null of=img6 bs=1 seek=2G
> mkfs.btrfs -d raid1 -m raid1 img5 img6
> losetup /dev/loop4 img5
> losetup /dev/loop5 img6
> btrfs device scan
> mount -t btrfs /dev/loop4 dir
> umount
On Tue, Jul 12, 2011 at 10:49:59AM +0200, Jan Schmidt wrote:
> On 11.07.2011 22:57, Hugo Mills wrote:
> > On Mon, Jul 11, 2011 at 04:29:24PM +0200, Jan Schmidt wrote:
> >> On 10.07.2011 20:23, Hugo Mills wrote:
> >>>Yes, this is over three months after the initial posting, but since
> >>> nobod
On 11.07.2011 22:57, Hugo Mills wrote:
> On Mon, Jul 11, 2011 at 04:29:24PM +0200, Jan Schmidt wrote:
>> On 10.07.2011 20:23, Hugo Mills wrote:
>>>Yes, this is over three months after the initial posting, but since
>>> nobody else has looked at it yet, and the patch is in my integration
>>> sta
On 11.07.2011 22:45, Hugo Mills wrote:
>OK, here's the remainder of my comments for this file. Not much for
> this bit -- just one comment about locking, a reminder, and an
> observation.
Again, I ripped out the bits I simply corrected. My comments below.
> [...]
>
>> +static int scrub_write_
>>> I've been monitoring the lists for a while now but didn't see this
>>> problem mentioned in particular: I've got a fairly standard desktop
>>> system at home, 700gb WD drive, nothing special, with 2 btrfs
>>> filesystems and some snapshots. The system runs for days, and I've
>>> noticed unusual
Jan Stilow, Tue, 12 Jul 2011 09:18:06 +0200:
> On 07/11/2011 02:18 AM, Kok, Auke-jan H wrote:
>> I've been monitoring the lists for a while now but didn't see this
>> problem mentioned in particular: I've got a fairly standard desktop
>> system at home, 700gb WD drive, nothing special, with 2 btrf
On 07/11/2011 02:18 AM, Kok, Auke-jan H wrote:
> I've been monitoring the lists for a while now but didn't see this
> problem mentioned in particular: I've got a fairly standard desktop
> system at home, 700gb WD drive, nothing special, with 2 btrfs
> filesystems and some snapshots. The system runs
18 matches
Mail list logo
