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
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 disk activity
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
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
stack...
...
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
nobody else has
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 dir
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, -1,
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
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 detailed
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 large
Excerpts from Mitch Harder's message of 2011-07-11 15:38:45 -0400:
2011/7/11 João Eduardo Luís jecl...@gmail.com:
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?
2011/5/10 David Sterba d...@jikos.cz
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:
2011/6/7 Josef Bacik jo...@redhat.com:
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
2011/7/12 Chris Mason chris.ma...@oracle.com:
Excerpts from Mitch Harder's message of 2011-07-11 15:38:45 -0400:
2011/7/11 João Eduardo Luís jecl...@gmail.com:
Hello.
Am I reading the code the wrong way, or is the 'last_index' variable in
'__btrfs_buffered_write()' (and previously used
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
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 rbtree
16 matches
Mail list logo