* processes stuck in llseek
@ 2011-08-16 3:59 Dan Merillat
2011-08-16 12:36 ` David Sterba
2011-08-16 12:51 ` Chris Mason
0 siblings, 2 replies; 14+ messages in thread
From: Dan Merillat @ 2011-08-16 3:59 UTC (permalink / raw)
To: Linux Kernel Mailing List, BTRFS Mailing list
I noticed a series of hung_task notifications in dmesg, so I went
poking at it. Process is 'dropbox', and it's stuck trying to llseek
it's library.zip file.
strace of dropbox:
...
stat("/home/x/.dropbox-dist/library.zip", {st_mode=S_IFREG|0755,
st_size=11575179, ...}) = 0
open("/home/x/.dropbox-dist/library.zip", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fa766ea8000
fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
lseek(3, 11571200, SEEK_SET
SEEK_SET is less than st_size
strace of dd if=library.zip of=/dev/null bs=1 seek=11571200:
open("library.zip", O_RDONLY) = 3
dup2(3, 0) = 0
close(3) = 0
lseek(0, 0, SEEK_CUR
[72960.716080] INFO: task dropbox:1348 blocked for more than 120 seconds.
[72960.716084] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[72960.716087] dropbox D ffff8800762d8a78 0 1348 1 0x00000004
[72960.716092] ffff880069cede18 0000000000000086 0000000000096000
0000000000000000
[72960.716097] ffff880069cec000 00000000000119c0 ffff8800762d8700
00000000000119c0
[72960.716101] ffff880069cedfd8 0000000000004000 ffff880069cedfd8
00000000000119c0
[72960.716106] Call Trace:
[72960.716113] [<ffffffff81331f9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[72960.716119] [<ffffffff8155710a>] ? retint_restore_args+0xe/0xe
[72960.716124] [<ffffffff810e8ef1>] ? noop_llseek+0xa/0xa
[72960.716129] [<ffffffff810340ff>] ? mutex_spin_on_owner+0x1c/0x45
[72960.716133] [<ffffffff81555be0>] __mutex_lock_slowpath+0xd2/0x116
[72960.716137] [<ffffffff81559edd>] ? do_page_fault+0x374/0x3e6
[72960.716140] [<ffffffff81555a87>] mutex_lock+0x16/0x27
[72960.716146] [<ffffffff812c8ad7>] btrfs_file_llseek+0x38/0x297
[72960.716150] [<ffffffff81331fda>] ? trace_hardirqs_off_thunk+0x3a/0x6c
[72960.716153] [<ffffffff810e8f2c>] vfs_llseek+0x2e/0x30
[72960.716155] [<ffffffff810e9311>] sys_lseek+0x3e/0x5d
[72960.716159] [<ffffffff8155d4fb>] system_call_fastpath+0x16/0x1b
Oddly enough, it's just llseek. I can copy/read the file sequentially
just fine, but llseek fails on a copy as well. Once I get physically
to the system I'll recompile to an unmodified kernel and try again.
Other files of the same approximate age llseek correctly.
Kernel is 3.1-rc1 with the fglrx module from AMD and the following
patch: (I was playing with cross-subvolume reflinking, but not on
this file)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 7cf0133..a13b5e2 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2182,7 +2182,7 @@ static noinline long btrfs_ioctl_clone(struct
file *file, unsigned long srcfd,
goto out_fput;
ret = -EXDEV;
- if (src->i_sb != inode->i_sb || BTRFS_I(src)->root != root)
+ if (src->i_sb != inode->i_sb)
goto out_fput;
ret = -ENOMEM;
@@ -2246,13 +2246,13 @@ static noinline long btrfs_ioctl_clone(struct
file *file, unsigned long srcfd,
* note the key will change type as we walk through the
* tree.
*/
- ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
+ ret = btrfs_search_slot(NULL, BTRFS_I(src)->root, &key, path, 0, 0);
if (ret < 0)
goto out;
nritems = btrfs_header_nritems(path->nodes[0]);
if (path->slots[0] >= nritems) {
- ret = btrfs_next_leaf(root, path);
+ ret = btrfs_next_leaf(BTRFS_I(src)->root, path);
if (ret < 0)
goto out;
if (ret > 0)
@@ -2313,7 +2313,7 @@ static noinline long btrfs_ioctl_clone(struct
file *file, unsigned long srcfd,
else
new_key.offset = destoff;
- trans = btrfs_start_transaction(root, 1);
+ trans = btrfs_start_transaction(root, 3);
if (IS_ERR(trans)) {
ret = PTR_ERR(trans);
goto out;
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-16 3:59 processes stuck in llseek Dan Merillat
@ 2011-08-16 12:36 ` David Sterba
2011-08-16 12:51 ` Chris Mason
1 sibling, 0 replies; 14+ messages in thread
From: David Sterba @ 2011-08-16 12:36 UTC (permalink / raw)
To: Dan Merillat; +Cc: Linux Kernel Mailing List, BTRFS Mailing list
On Mon, Aug 15, 2011 at 11:59:50PM -0400, Dan Merillat wrote:
> I noticed a series of hung_task notifications in dmesg, so I went
> poking at it. Process is 'dropbox', and it's stuck trying to llseek
> it's library.zip file.
looks like mutex lock is waiting, in btrfs_file_llseek. somebody else is
holding it for that file. it could be a forgotten unlock (of
inode->i_mutex) on some error path, but this does not look very
promising to me, or the process holding the lock still exists and will
be visible in process listings. locdep would tell more exactly.
>
> strace of dropbox:
> ...
> stat("/home/x/.dropbox-dist/library.zip", {st_mode=S_IFREG|0755,
> st_size=11575179, ...}) = 0
> open("/home/x/.dropbox-dist/library.zip", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7fa766ea8000
> fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
> lseek(3, 11571200, SEEK_SET
>
> SEEK_SET is less than st_size
>
> strace of dd if=library.zip of=/dev/null bs=1 seek=11571200:
>
> open("library.zip", O_RDONLY) = 3
> dup2(3, 0) = 0
> close(3) = 0
> lseek(0, 0, SEEK_CUR
>
> [72960.716080] INFO: task dropbox:1348 blocked for more than 120 seconds.
> [72960.716084] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [72960.716087] dropbox D ffff8800762d8a78 0 1348 1 0x00000004
> [72960.716092] ffff880069cede18 0000000000000086 0000000000096000
> 0000000000000000
> [72960.716097] ffff880069cec000 00000000000119c0 ffff8800762d8700
> 00000000000119c0
> [72960.716101] ffff880069cedfd8 0000000000004000 ffff880069cedfd8
> 00000000000119c0
> [72960.716106] Call Trace:
> [72960.716113] [<ffffffff81331f9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
> [72960.716119] [<ffffffff8155710a>] ? retint_restore_args+0xe/0xe
> [72960.716124] [<ffffffff810e8ef1>] ? noop_llseek+0xa/0xa
> [72960.716129] [<ffffffff810340ff>] ? mutex_spin_on_owner+0x1c/0x45
> [72960.716133] [<ffffffff81555be0>] __mutex_lock_slowpath+0xd2/0x116
> [72960.716137] [<ffffffff81559edd>] ? do_page_fault+0x374/0x3e6
> [72960.716140] [<ffffffff81555a87>] mutex_lock+0x16/0x27
> [72960.716146] [<ffffffff812c8ad7>] btrfs_file_llseek+0x38/0x297
> [72960.716150] [<ffffffff81331fda>] ? trace_hardirqs_off_thunk+0x3a/0x6c
> [72960.716153] [<ffffffff810e8f2c>] vfs_llseek+0x2e/0x30
> [72960.716155] [<ffffffff810e9311>] sys_lseek+0x3e/0x5d
> [72960.716159] [<ffffffff8155d4fb>] system_call_fastpath+0x16/0x1b
just a guess, as it touches file pages, can you try Sage's fix
"truncate pages from clone ioctl target range"
https://patchwork.kernel.org/patch/1054552/
under assumption that the file on which seek is run has been reflinked
or at least written to during the running transaction (ie no sync in
between).
> Oddly enough, it's just llseek. I can copy/read the file sequentially
> just fine, but llseek fails on a copy as well.
incorrect or unexpected contents of the same-aged files would point to
the missing truncate.
david
> Once I get physically
> to the system I'll recompile to an unmodified kernel and try again.
> Other files of the same approximate age llseek correctly.
>
> Kernel is 3.1-rc1 with the fglrx module from AMD and the following
> patch: (I was playing with cross-subvolume reflinking, but not on
> this file)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 7cf0133..a13b5e2 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2182,7 +2182,7 @@ static noinline long btrfs_ioctl_clone(struct
> file *file, unsigned long srcfd,
> goto out_fput;
>
> ret = -EXDEV;
> - if (src->i_sb != inode->i_sb || BTRFS_I(src)->root != root)
> + if (src->i_sb != inode->i_sb)
> goto out_fput;
>
> ret = -ENOMEM;
> @@ -2246,13 +2246,13 @@ static noinline long btrfs_ioctl_clone(struct
> file *file, unsigned long srcfd,
> * note the key will change type as we walk through the
> * tree.
> */
> - ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
> + ret = btrfs_search_slot(NULL, BTRFS_I(src)->root, &key, path, 0, 0);
> if (ret < 0)
> goto out;
>
> nritems = btrfs_header_nritems(path->nodes[0]);
> if (path->slots[0] >= nritems) {
> - ret = btrfs_next_leaf(root, path);
> + ret = btrfs_next_leaf(BTRFS_I(src)->root, path);
> if (ret < 0)
> goto out;
> if (ret > 0)
> @@ -2313,7 +2313,7 @@ static noinline long btrfs_ioctl_clone(struct
> file *file, unsigned long srcfd,
> else
> new_key.offset = destoff;
>
> - trans = btrfs_start_transaction(root, 1);
> + trans = btrfs_start_transaction(root, 3);
> if (IS_ERR(trans)) {
> ret = PTR_ERR(trans);
> goto out;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-16 3:59 processes stuck in llseek Dan Merillat
2011-08-16 12:36 ` David Sterba
@ 2011-08-16 12:51 ` Chris Mason
2011-08-16 19:22 ` Dan Merillat
1 sibling, 1 reply; 14+ messages in thread
From: Chris Mason @ 2011-08-16 12:51 UTC (permalink / raw)
To: Dan Merillat; +Cc: Linux Kernel Mailing List, BTRFS Mailing list
Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
> I noticed a series of hung_task notifications in dmesg, so I went
> poking at it. Process is 'dropbox', and it's stuck trying to llseek
> it's library.zip file.
>
> strace of dropbox:
> ...
> stat("/home/x/.dropbox-dist/library.zip", {st_mode=S_IFREG|0755,
> st_size=11575179, ...}) = 0
> open("/home/x/.dropbox-dist/library.zip", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7fa766ea8000
> fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
> lseek(3, 11571200, SEEK_SET
>
> SEEK_SET is less than st_size
>
> strace of dd if=library.zip of=/dev/null bs=1 seek=11571200:
>
> open("library.zip", O_RDONLY) = 3
> dup2(3, 0) = 0
> close(3) = 0
> lseek(0, 0, SEEK_CUR
>
> [72960.716080] INFO: task dropbox:1348 blocked for more than 120 seconds.
> [72960.716084] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [72960.716087] dropbox D ffff8800762d8a78 0 1348 1 0x00000004
> [72960.716092] ffff880069cede18 0000000000000086 0000000000096000
> 0000000000000000
> [72960.716097] ffff880069cec000 00000000000119c0 ffff8800762d8700
> 00000000000119c0
> [72960.716101] ffff880069cedfd8 0000000000004000 ffff880069cedfd8
> 00000000000119c0
> [72960.716106] Call Trace:
> [72960.716113] [<ffffffff81331f9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
> [72960.716119] [<ffffffff8155710a>] ? retint_restore_args+0xe/0xe
> [72960.716124] [<ffffffff810e8ef1>] ? noop_llseek+0xa/0xa
> [72960.716129] [<ffffffff810340ff>] ? mutex_spin_on_owner+0x1c/0x45
> [72960.716133] [<ffffffff81555be0>] __mutex_lock_slowpath+0xd2/0x116
> [72960.716137] [<ffffffff81559edd>] ? do_page_fault+0x374/0x3e6
> [72960.716140] [<ffffffff81555a87>] mutex_lock+0x16/0x27
> [72960.716146] [<ffffffff812c8ad7>] btrfs_file_llseek+0x38/0x297
> [72960.716150] [<ffffffff81331fda>] ? trace_hardirqs_off_thunk+0x3a/0x6c
> [72960.716153] [<ffffffff810e8f2c>] vfs_llseek+0x2e/0x30
> [72960.716155] [<ffffffff810e9311>] sys_lseek+0x3e/0x5d
> [72960.716159] [<ffffffff8155d4fb>] system_call_fastpath+0x16/0x1b
>
> Oddly enough, it's just llseek. I can copy/read the file sequentially
> just fine, but llseek fails on a copy as well. Once I get physically
> to the system I'll recompile to an unmodified kernel and try again.
> Other files of the same approximate age llseek correctly.
>
> Kernel is 3.1-rc1 with the fglrx module from AMD and the following
> patch: (I was playing with cross-subvolume reflinking, but not on
> this file)
Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
-chris
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-16 12:51 ` Chris Mason
@ 2011-08-16 19:22 ` Dan Merillat
2011-08-17 1:23 ` Li Zefan
0 siblings, 1 reply; 14+ messages in thread
From: Dan Merillat @ 2011-08-16 19:22 UTC (permalink / raw)
To: Chris Mason; +Cc: Linux Kernel Mailing List, BTRFS Mailing list
On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.com> wrote:
> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
> Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
Can you send it? I'd like to test it to see if it fixes my system.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-16 19:22 ` Dan Merillat
@ 2011-08-17 1:23 ` Li Zefan
2011-08-18 15:40 ` Mitch Harder
2011-08-19 16:20 ` Dan Merillat
0 siblings, 2 replies; 14+ messages in thread
From: Li Zefan @ 2011-08-17 1:23 UTC (permalink / raw)
To: Dan Merillat; +Cc: Chris Mason, Linux Kernel Mailing List, BTRFS Mailing list
Dan Merillat wrote:
> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.com> wrote:
>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
>
>> Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
>
> Can you send it? I'd like to test it to see if it fixes my system.
Here it is.
http://marc.info/?l=linux-btrfs&m=131176036219732&w=2
--
Li Zefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-17 1:23 ` Li Zefan
@ 2011-08-18 15:40 ` Mitch Harder
2011-08-19 16:20 ` Dan Merillat
1 sibling, 0 replies; 14+ messages in thread
From: Mitch Harder @ 2011-08-18 15:40 UTC (permalink / raw)
To: Li Zefan
Cc: Dan Merillat, Chris Mason, Linux Kernel Mailing List, BTRFS Mailing list
On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> Dan Merillat wrote:
>> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.com=
> wrote:
>>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
>>
>>> Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
>>
>> Can you send it? =A0I'd like to test it to see if it fixes my system=
=2E
>
> Here it is.
>
> http://marc.info/?l=3Dlinux-btrfs&m=3D131176036219732&w=3D2
>
Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set which
isn't in the kernel yet?
http://marc.info/?l=3Dlinux-btrfs&m=3D130927580606177&w=3D2
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
@ 2011-08-18 15:40 ` Mitch Harder
0 siblings, 0 replies; 14+ messages in thread
From: Mitch Harder @ 2011-08-18 15:40 UTC (permalink / raw)
To: Li Zefan
Cc: Dan Merillat, Chris Mason, Linux Kernel Mailing List, BTRFS Mailing list
On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> Dan Merillat wrote:
>> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.com> wrote:
>>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
>>
>>> Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
>>
>> Can you send it? I'd like to test it to see if it fixes my system.
>
> Here it is.
>
> http://marc.info/?l=linux-btrfs&m=131176036219732&w=2
>
Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set which
isn't in the kernel yet?
http://marc.info/?l=linux-btrfs&m=130927580606177&w=2
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-18 15:40 ` Mitch Harder
@ 2011-08-18 16:00 ` Chris Mason
-1 siblings, 0 replies; 14+ messages in thread
From: Chris Mason @ 2011-08-18 16:00 UTC (permalink / raw)
To: Mitch Harder
Cc: Li Zefan, Dan Merillat, Linux Kernel Mailing List, BTRFS Mailing list
Excerpts from Mitch Harder's message of 2011-08-18 11:40:17 -0400:
> On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrote=
:
> > Dan Merillat wrote:
> >> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.c=
om> wrote:
> >>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400=
:
> >>
> >>> Dan Carpenter sent a patch for this, I'll get it queued up for rc=
3.
> >>
> >> Can you send it? =C2=A0I'd like to test it to see if it fixes my s=
ystem.
> >
> > Here it is.
> >
> > http://marc.info/?l=3Dlinux-btrfs&m=3D131176036219732&w=3D2
> >
>=20
> Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set whic=
h
> isn't in the kernel yet?
>=20
> http://marc.info/?l=3Dlinux-btrfs&m=3D130927580606177&w=3D2
It does, but the hang was reported on 3.1-rc1, which does have Josef's
code.
-chris
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
@ 2011-08-18 16:00 ` Chris Mason
0 siblings, 0 replies; 14+ messages in thread
From: Chris Mason @ 2011-08-18 16:00 UTC (permalink / raw)
To: Mitch Harder
Cc: Li Zefan, Dan Merillat, Linux Kernel Mailing List, BTRFS Mailing list
Excerpts from Mitch Harder's message of 2011-08-18 11:40:17 -0400:
> On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> > Dan Merillat wrote:
> >> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.com> wrote:
> >>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
> >>
> >>> Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
> >>
> >> Can you send it? I'd like to test it to see if it fixes my system.
> >
> > Here it is.
> >
> > http://marc.info/?l=linux-btrfs&m=131176036219732&w=2
> >
>
> Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set which
> isn't in the kernel yet?
>
> http://marc.info/?l=linux-btrfs&m=130927580606177&w=2
It does, but the hang was reported on 3.1-rc1, which does have Josef's
code.
-chris
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-18 16:00 ` Chris Mason
@ 2011-08-18 16:53 ` Mitch Harder
-1 siblings, 0 replies; 14+ messages in thread
From: Mitch Harder @ 2011-08-18 16:53 UTC (permalink / raw)
To: Chris Mason
Cc: Li Zefan, Dan Merillat, Linux Kernel Mailing List, BTRFS Mailing list
On Thu, Aug 18, 2011 at 11:00 AM, Chris Mason <chris.mason@oracle.com> =
wrote:
> Excerpts from Mitch Harder's message of 2011-08-18 11:40:17 -0400:
>> On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrot=
e:
>> > Dan Merillat wrote:
>> >> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.=
com> wrote:
>> >>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -040=
0:
>> >>
>> >>> Dan Carpenter sent a patch for this, I'll get it queued up for r=
c3.
>> >>
>> >> Can you send it? =A0I'd like to test it to see if it fixes my sys=
tem.
>> >
>> > Here it is.
>> >
>> > http://marc.info/?l=3Dlinux-btrfs&m=3D131176036219732&w=3D2
>> >
>>
>> Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set whi=
ch
>> isn't in the kernel yet?
>>
>> http://marc.info/?l=3Dlinux-btrfs&m=3D130927580606177&w=3D2
>
> It does, but the hang was reported on 3.1-rc1, which does have Josef'=
s
> code.
>
Thanks.
That gives me some insights regarding the differences between the
'for-linus' and the 'for-linus-merged' branches.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
@ 2011-08-18 16:53 ` Mitch Harder
0 siblings, 0 replies; 14+ messages in thread
From: Mitch Harder @ 2011-08-18 16:53 UTC (permalink / raw)
To: Chris Mason
Cc: Li Zefan, Dan Merillat, Linux Kernel Mailing List, BTRFS Mailing list
On Thu, Aug 18, 2011 at 11:00 AM, Chris Mason <chris.mason@oracle.com> wrote:
> Excerpts from Mitch Harder's message of 2011-08-18 11:40:17 -0400:
>> On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> > Dan Merillat wrote:
>> >> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.com> wrote:
>> >>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
>> >>
>> >>> Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
>> >>
>> >> Can you send it? I'd like to test it to see if it fixes my system.
>> >
>> > Here it is.
>> >
>> > http://marc.info/?l=linux-btrfs&m=131176036219732&w=2
>> >
>>
>> Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set which
>> isn't in the kernel yet?
>>
>> http://marc.info/?l=linux-btrfs&m=130927580606177&w=2
>
> It does, but the hang was reported on 3.1-rc1, which does have Josef's
> code.
>
Thanks.
That gives me some insights regarding the differences between the
'for-linus' and the 'for-linus-merged' branches.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-18 16:53 ` Mitch Harder
@ 2011-08-18 17:52 ` Chris Mason
-1 siblings, 0 replies; 14+ messages in thread
From: Chris Mason @ 2011-08-18 17:52 UTC (permalink / raw)
To: Mitch Harder
Cc: Li Zefan, Dan Merillat, Linux Kernel Mailing List, BTRFS Mailing list
Excerpts from Mitch Harder's message of 2011-08-18 12:53:33 -0400:
> On Thu, Aug 18, 2011 at 11:00 AM, Chris Mason <chris.mason@oracle.com=
> wrote:
> > Excerpts from Mitch Harder's message of 2011-08-18 11:40:17 -0400:
> >> On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wr=
ote:
> >> > Dan Merillat wrote:
> >> >> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracl=
e.com> wrote:
> >> >>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0=
400:
> >> >>
> >> >>> Dan Carpenter sent a patch for this, I'll get it queued up for=
rc3.
> >> >>
> >> >> Can you send it? =C2=A0I'd like to test it to see if it fixes m=
y system.
> >> >
> >> > Here it is.
> >> >
> >> > http://marc.info/?l=3Dlinux-btrfs&m=3D131176036219732&w=3D2
> >> >
> >>
> >> Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set w=
hich
> >> isn't in the kernel yet?
> >>
> >> http://marc.info/?l=3Dlinux-btrfs&m=3D130927580606177&w=3D2
> >
> > It does, but the hang was reported on 3.1-rc1, which does have Jose=
f's
> > code.
> >
>=20
> Thanks.
>=20
> That gives me some insights regarding the differences between the
> 'for-linus' and the 'for-linus-merged' branches.
for-linus is usually what I send him to pull, and master is usually the
stable things against the last release (3.0 as of today).
for-linus-merged is used when there is a conflict between his current
tree and my for-linus branch. Linus almost never uses this directly,
since he really likes to resolve conflicts himself. This is mostly
because he wants to see what the conflicts are and make sure the
integration is done correctly.
But I still provide a for-linus-merged just so we can double check=20
the results of the conflict resolution.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
@ 2011-08-18 17:52 ` Chris Mason
0 siblings, 0 replies; 14+ messages in thread
From: Chris Mason @ 2011-08-18 17:52 UTC (permalink / raw)
To: Mitch Harder
Cc: Li Zefan, Dan Merillat, Linux Kernel Mailing List, BTRFS Mailing list
Excerpts from Mitch Harder's message of 2011-08-18 12:53:33 -0400:
> On Thu, Aug 18, 2011 at 11:00 AM, Chris Mason <chris.mason@oracle.com> wrote:
> > Excerpts from Mitch Harder's message of 2011-08-18 11:40:17 -0400:
> >> On Tue, Aug 16, 2011 at 8:23 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> >> > Dan Merillat wrote:
> >> >> On Tue, Aug 16, 2011 at 8:51 AM, Chris Mason <chris.mason@oracle.com> wrote:
> >> >>> Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
> >> >>
> >> >>> Dan Carpenter sent a patch for this, I'll get it queued up for rc3.
> >> >>
> >> >> Can you send it? I'd like to test it to see if it fixes my system.
> >> >
> >> > Here it is.
> >> >
> >> > http://marc.info/?l=linux-btrfs&m=131176036219732&w=2
> >> >
> >>
> >> Doesn't this patch rely on Josef's SEEK_HOLE/SEEK_DATA patch set which
> >> isn't in the kernel yet?
> >>
> >> http://marc.info/?l=linux-btrfs&m=130927580606177&w=2
> >
> > It does, but the hang was reported on 3.1-rc1, which does have Josef's
> > code.
> >
>
> Thanks.
>
> That gives me some insights regarding the differences between the
> 'for-linus' and the 'for-linus-merged' branches.
for-linus is usually what I send him to pull, and master is usually the
stable things against the last release (3.0 as of today).
for-linus-merged is used when there is a conflict between his current
tree and my for-linus branch. Linus almost never uses this directly,
since he really likes to resolve conflicts himself. This is mostly
because he wants to see what the conflicts are and make sure the
integration is done correctly.
But I still provide a for-linus-merged just so we can double check
the results of the conflict resolution.
-chris
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: processes stuck in llseek
2011-08-17 1:23 ` Li Zefan
2011-08-18 15:40 ` Mitch Harder
@ 2011-08-19 16:20 ` Dan Merillat
1 sibling, 0 replies; 14+ messages in thread
From: Dan Merillat @ 2011-08-19 16:20 UTC (permalink / raw)
To: Li Zefan; +Cc: Chris Mason, Linux Kernel Mailing List, BTRFS Mailing list
> Here it is.
>
> http://marc.info/?l=linux-btrfs&m=131176036219732&w=2
That was it, thanks. Confirmed fixed.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-08-19 16:20 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-16 3:59 processes stuck in llseek Dan Merillat
2011-08-16 12:36 ` David Sterba
2011-08-16 12:51 ` Chris Mason
2011-08-16 19:22 ` Dan Merillat
2011-08-17 1:23 ` Li Zefan
2011-08-18 15:40 ` Mitch Harder
2011-08-18 15:40 ` Mitch Harder
2011-08-18 16:00 ` Chris Mason
2011-08-18 16:00 ` Chris Mason
2011-08-18 16:53 ` Mitch Harder
2011-08-18 16:53 ` Mitch Harder
2011-08-18 17:52 ` Chris Mason
2011-08-18 17:52 ` Chris Mason
2011-08-19 16:20 ` Dan Merillat
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.