* 2.6.38: Quota over NFS4 @ 2011-03-17 13:32 Adam Lackorzynski 2011-03-17 17:38 ` J. Bruce Fields 2011-03-20 19:49 ` Maciej Rutecki 0 siblings, 2 replies; 20+ messages in thread From: Adam Lackorzynski @ 2011-03-17 13:32 UTC (permalink / raw) To: Trond Myklebust, linux-kernel, linux-nfs Hello, I'm seeing a problem with quotas in a system where the server running 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel version does not seem to play a role, checked with 2.6.38, 2.6.37 and 2.6.36. The following script and output show the problem: #! /bin/sh quota | grep home du cp /bin/ls x1 du cat x1 > /dev/null rm x1 du quota | grep home Output: homes:/home/ 8194720 9072000 9174400 403670 500000 550000 0 . 96 . 0 . homes:/home/ 8194816 9072000 9174400 403671 500000 550000 As can be seen the 96 kb are still accounted on the quota of the user. Removing the 'cat' command from the script makes the quota be ok again (original value). Also mounting via nfs3 does not exhibit it, same for running the script on the nfs-server directly. Client mount options are: homes:/home/ /home nfs4 rw,nosuid,nodev,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.3,minorversion=0,local_lock=none,addr=1.2.3.4 0 0 Server mount options are: /dev/mapper/vg-homefs /home xfs rw,nosuid,nodev,relatime,attr2,usrquota 0 0 Thanks, Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-17 13:32 2.6.38: Quota over NFS4 Adam Lackorzynski @ 2011-03-17 17:38 ` J. Bruce Fields 2011-03-17 21:33 ` Adam Lackorzynski 2011-03-20 19:49 ` Maciej Rutecki 1 sibling, 1 reply; 20+ messages in thread From: J. Bruce Fields @ 2011-03-17 17:38 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Trond Myklebust, linux-kernel, linux-nfs On Thu, Mar 17, 2011 at 02:32:47PM +0100, Adam Lackorzynski wrote: > Hello, > > I'm seeing a problem with quotas in a system where the server running > 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel > version does not seem to play a role, checked with 2.6.38, 2.6.37 and > 2.6.36. The following script and output show the problem: > > #! /bin/sh > > quota | grep home > du > cp /bin/ls x1 > du > cat x1 > /dev/null > rm x1 > du > quota | grep home > > Output: > > homes:/home/ 8194720 9072000 9174400 403670 500000 550000 > 0 . > 96 . > 0 . > homes:/home/ 8194816 9072000 9174400 403671 500000 550000 > > > As can be seen the 96 kb are still accounted on the quota of the user. > Removing the 'cat' command from the script makes the quota be ok again > (original value). Also mounting via nfs3 does not exhibit it, same for running > the script on the nfs-server directly. Does "df" show the same problem? And does unmounting/remounting on the client clear the problem? (Or that, in combination with stopping the server, unmounting the xfs export, remounting it, and restarting?) Was there an earlier server version that didn't exhibit this problem? --b. > > Client mount options are: > homes:/home/ /home nfs4 rw,nosuid,nodev,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.3,minorversion=0,local_lock=none,addr=1.2.3.4 0 0 > > Server mount options are: > /dev/mapper/vg-homefs /home xfs rw,nosuid,nodev,relatime,attr2,usrquota 0 0 > > > > > Thanks, > Adam > -- > Adam adam@os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-17 17:38 ` J. Bruce Fields @ 2011-03-17 21:33 ` Adam Lackorzynski 2011-03-17 22:27 ` J. Bruce Fields 0 siblings, 1 reply; 20+ messages in thread From: Adam Lackorzynski @ 2011-03-17 21:33 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Trond Myklebust, linux-kernel, linux-nfs On Thu Mar 17, 2011 at 13:38:05 -0400, J. Bruce Fields wrote: > On Thu, Mar 17, 2011 at 02:32:47PM +0100, Adam Lackorzynski wrote: > > Hello, > > > > I'm seeing a problem with quotas in a system where the server running > > 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel > > version does not seem to play a role, checked with 2.6.38, 2.6.37 and > > 2.6.36. The following script and output show the problem: > > > > #! /bin/sh > > > > quota | grep home > > du > > cp /bin/ls x1 > > du > > cat x1 > /dev/null > > rm x1 > > du > > quota | grep home > > > > Output: > > > > homes:/home/ 8194720 9072000 9174400 403670 500000 550000 > > 0 . > > 96 . > > 0 . > > homes:/home/ 8194816 9072000 9174400 403671 500000 550000 > > > > > > As can be seen the 96 kb are still accounted on the quota of the user. > > Removing the 'cat' command from the script makes the quota be ok again > > (original value). Also mounting via nfs3 does not exhibit it, same for running > > the script on the nfs-server directly. > > Does "df" show the same problem? With '/bin/ls' it does not change at all, so I took a bigger binary which yields to: homes:/home/ 8203780 9072000 9174400 403688 500000 550000 0 . Filesystem 1K-blocks Used Available Use% Mounted on homes:/home 513671168 335251456 178419712 66% /tmp/xx 4592 . Filesystem 1K-blocks Used Available Use% Mounted on homes:/home 513671168 335256576 178414592 66% /tmp/xx 0 . Filesystem 1K-blocks Used Available Use% Mounted on homes:/home 513671168 335256576 178414592 66% /tmp/xx homes:/home/ 8208372 9072000 9174400 403689 500000 550000 So yes, it seems to be there as well. > And does unmounting/remounting on the > client clear the problem? No. > (Or that, in combination with stopping the > server, unmounting the xfs export, remounting it, and restarting?) I rebooted once, got a recovery and then the quotas were ok again (and supposedly the used blocks as well). I assume a unmount/mount would show the same behaviour but requires a bit of preparation to try out. > Was there an earlier server version that didn't exhibit this problem? Had 2.6.37 on the server before and that was fine regarding this. > > Client mount options are: > > homes:/home/ /home nfs4 rw,nosuid,nodev,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.3,minorversion=0,local_lock=none,addr=1.2.3.4 0 0 > > > > Server mount options are: > > /dev/mapper/vg-homefs /home xfs rw,nosuid,nodev,relatime,attr2,usrquota 0 0 Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-17 21:33 ` Adam Lackorzynski @ 2011-03-17 22:27 ` J. Bruce Fields 2011-03-17 22:59 ` Adam Lackorzynski 0 siblings, 1 reply; 20+ messages in thread From: J. Bruce Fields @ 2011-03-17 22:27 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Trond Myklebust, linux-kernel, linux-nfs On Thu, Mar 17, 2011 at 10:33:03PM +0100, Adam Lackorzynski wrote: > > On Thu Mar 17, 2011 at 13:38:05 -0400, J. Bruce Fields wrote: > > On Thu, Mar 17, 2011 at 02:32:47PM +0100, Adam Lackorzynski wrote: > > > Hello, > > > > > > I'm seeing a problem with quotas in a system where the server running > > > 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel > > > version does not seem to play a role, checked with 2.6.38, 2.6.37 and > > > 2.6.36. The following script and output show the problem: > > > > > > #! /bin/sh > > > > > > quota | grep home > > > du > > > cp /bin/ls x1 > > > du > > > cat x1 > /dev/null > > > rm x1 > > > du > > > quota | grep home > > > > > > Output: > > > > > > homes:/home/ 8194720 9072000 9174400 403670 500000 550000 > > > 0 . > > > 96 . > > > 0 . > > > homes:/home/ 8194816 9072000 9174400 403671 500000 550000 > > > > > > > > > As can be seen the 96 kb are still accounted on the quota of the user. > > > Removing the 'cat' command from the script makes the quota be ok again > > > (original value). Also mounting via nfs3 does not exhibit it, same for running > > > the script on the nfs-server directly. > > > > Does "df" show the same problem? > > With '/bin/ls' it does not change at all, so I took a bigger binary > which yields to: > > homes:/home/ 8203780 9072000 9174400 403688 500000 550000 > 0 . > Filesystem 1K-blocks Used Available Use% Mounted on > homes:/home 513671168 335251456 178419712 66% /tmp/xx > 4592 . > Filesystem 1K-blocks Used Available Use% Mounted on > homes:/home 513671168 335256576 178414592 66% /tmp/xx > 0 . > Filesystem 1K-blocks Used Available Use% Mounted on > homes:/home 513671168 335256576 178414592 66% /tmp/xx > homes:/home/ 8208372 9072000 9174400 403689 500000 550000 > > So yes, it seems to be there as well. It might be easier to see with "df -i" (assuming we're leaking an inode). > > And does unmounting/remounting on the > > client clear the problem? > > No. > > > (Or that, in combination with stopping the > > server, unmounting the xfs export, remounting it, and restarting?) > > I rebooted once, got a recovery and then the quotas were ok again (and > supposedly the used blocks as well). I assume a unmount/mount would show > the same behaviour but requires a bit of preparation to try out. > > > Was there an earlier server version that didn't exhibit this problem? > > Had 2.6.37 on the server before and that was fine regarding this. OK, thanks. Sounds like a server bug, but I'm not managing to reproduce it here yet.... --b. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-17 22:27 ` J. Bruce Fields @ 2011-03-17 22:59 ` Adam Lackorzynski 2011-03-17 23:03 ` J. Bruce Fields 0 siblings, 1 reply; 20+ messages in thread From: Adam Lackorzynski @ 2011-03-17 22:59 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Trond Myklebust, linux-kernel, linux-nfs On Thu Mar 17, 2011 at 18:27:32 -0400, J. Bruce Fields wrote: > On Thu, Mar 17, 2011 at 10:33:03PM +0100, Adam Lackorzynski wrote: > > > > On Thu Mar 17, 2011 at 13:38:05 -0400, J. Bruce Fields wrote: > > > On Thu, Mar 17, 2011 at 02:32:47PM +0100, Adam Lackorzynski wrote: > > > > Hello, > > > > > > > > I'm seeing a problem with quotas in a system where the server running > > > > 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel > > > > version does not seem to play a role, checked with 2.6.38, 2.6.37 and > > > > 2.6.36. The following script and output show the problem: > > > > > > > > #! /bin/sh > > > > > > > > quota | grep home > > > > du > > > > cp /bin/ls x1 > > > > du > > > > cat x1 > /dev/null > > > > rm x1 > > > > du > > > > quota | grep home > > > > > > > > Output: > > > > > > > > homes:/home/ 8194720 9072000 9174400 403670 500000 550000 > > > > 0 . > > > > 96 . > > > > 0 . > > > > homes:/home/ 8194816 9072000 9174400 403671 500000 550000 > > > > > > > > > > > > As can be seen the 96 kb are still accounted on the quota of the user. > > > > Removing the 'cat' command from the script makes the quota be ok again > > > > (original value). Also mounting via nfs3 does not exhibit it, same for running > > > > the script on the nfs-server directly. > > > > > > Does "df" show the same problem? > > > > With '/bin/ls' it does not change at all, so I took a bigger binary > > which yields to: > > > > homes:/home/ 8203780 9072000 9174400 403688 500000 550000 > > 0 . > > Filesystem 1K-blocks Used Available Use% Mounted on > > homes:/home 513671168 335251456 178419712 66% /tmp/xx > > 4592 . > > Filesystem 1K-blocks Used Available Use% Mounted on > > homes:/home 513671168 335256576 178414592 66% /tmp/xx > > 0 . > > Filesystem 1K-blocks Used Available Use% Mounted on > > homes:/home 513671168 335256576 178414592 66% /tmp/xx > > homes:/home/ 8208372 9072000 9174400 403689 500000 550000 > > > > So yes, it seems to be there as well. > > It might be easier to see with "df -i" (assuming we're leaking an > inode). Result is as expected, inode goes one up and not down again. > > > And does unmounting/remounting on the > > > client clear the problem? > > > > No. > > > > > (Or that, in combination with stopping the > > > server, unmounting the xfs export, remounting it, and restarting?) > > > > I rebooted once, got a recovery and then the quotas were ok again (and > > supposedly the used blocks as well). I assume a unmount/mount would show > > the same behaviour but requires a bit of preparation to try out. > > > > > Was there an earlier server version that didn't exhibit this problem? > > > > Had 2.6.37 on the server before and that was fine regarding this. > > OK, thanks. Sounds like a server bug, but I'm not managing to reproduce > it here yet.... Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-17 22:59 ` Adam Lackorzynski @ 2011-03-17 23:03 ` J. Bruce Fields 2011-03-17 23:16 ` Adam Lackorzynski [not found] ` <20110320172758.GK11929@os.inf.tu-dresden.de> 0 siblings, 2 replies; 20+ messages in thread From: J. Bruce Fields @ 2011-03-17 23:03 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Trond Myklebust, linux-kernel, linux-nfs On Thu, Mar 17, 2011 at 11:59:08PM +0100, Adam Lackorzynski wrote: > > On Thu Mar 17, 2011 at 18:27:32 -0400, J. Bruce Fields wrote: > > On Thu, Mar 17, 2011 at 10:33:03PM +0100, Adam Lackorzynski wrote: > > > > > > On Thu Mar 17, 2011 at 13:38:05 -0400, J. Bruce Fields wrote: > > > > On Thu, Mar 17, 2011 at 02:32:47PM +0100, Adam Lackorzynski wrote: > > > > > Hello, > > > > > > > > > > I'm seeing a problem with quotas in a system where the server running > > > > > 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel > > > > > version does not seem to play a role, checked with 2.6.38, 2.6.37 and > > > > > 2.6.36. The following script and output show the problem: > > > > > > > > > > #! /bin/sh > > > > > > > > > > quota | grep home > > > > > du > > > > > cp /bin/ls x1 > > > > > du > > > > > cat x1 > /dev/null > > > > > rm x1 > > > > > du > > > > > quota | grep home > > > > > > > > > > Output: > > > > > > > > > > homes:/home/ 8194720 9072000 9174400 403670 500000 550000 > > > > > 0 . > > > > > 96 . > > > > > 0 . > > > > > homes:/home/ 8194816 9072000 9174400 403671 500000 550000 > > > > > > > > > > > > > > > As can be seen the 96 kb are still accounted on the quota of the user. > > > > > Removing the 'cat' command from the script makes the quota be ok again > > > > > (original value). Also mounting via nfs3 does not exhibit it, same for running > > > > > the script on the nfs-server directly. > > > > > > > > Does "df" show the same problem? > > > > > > With '/bin/ls' it does not change at all, so I took a bigger binary > > > which yields to: > > > > > > homes:/home/ 8203780 9072000 9174400 403688 500000 550000 > > > 0 . > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > homes:/home 513671168 335251456 178419712 66% /tmp/xx > > > 4592 . > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > homes:/home 513671168 335256576 178414592 66% /tmp/xx > > > 0 . > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > homes:/home 513671168 335256576 178414592 66% /tmp/xx > > > homes:/home/ 8208372 9072000 9174400 403689 500000 550000 > > > > > > So yes, it seems to be there as well. > > > > It might be easier to see with "df -i" (assuming we're leaking an > > inode). > > Result is as expected, inode goes one up and not down again. Is this something special about binaries? If you copy something other than a binary, do you not see the bug? --b. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-17 23:03 ` J. Bruce Fields @ 2011-03-17 23:16 ` Adam Lackorzynski [not found] ` <20110320172758.GK11929@os.inf.tu-dresden.de> 1 sibling, 0 replies; 20+ messages in thread From: Adam Lackorzynski @ 2011-03-17 23:16 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Trond Myklebust, linux-kernel, linux-nfs On Thu Mar 17, 2011 at 19:03:15 -0400, J. Bruce Fields wrote: > On Thu, Mar 17, 2011 at 11:59:08PM +0100, Adam Lackorzynski wrote: > > > > On Thu Mar 17, 2011 at 18:27:32 -0400, J. Bruce Fields wrote: > > > On Thu, Mar 17, 2011 at 10:33:03PM +0100, Adam Lackorzynski wrote: > > > > > > > > On Thu Mar 17, 2011 at 13:38:05 -0400, J. Bruce Fields wrote: > > > > > On Thu, Mar 17, 2011 at 02:32:47PM +0100, Adam Lackorzynski wrote: > > > > > > Hello, > > > > > > > > > > > > I'm seeing a problem with quotas in a system where the server running > > > > > > 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel > > > > > > version does not seem to play a role, checked with 2.6.38, 2.6.37 and > > > > > > 2.6.36. The following script and output show the problem: > > > > > > > > > > > > #! /bin/sh > > > > > > > > > > > > quota | grep home > > > > > > du > > > > > > cp /bin/ls x1 > > > > > > du > > > > > > cat x1 > /dev/null > > > > > > rm x1 > > > > > > du > > > > > > quota | grep home > > > > > > > > > > > > Output: > > > > > > > > > > > > homes:/home/ 8194720 9072000 9174400 403670 500000 550000 > > > > > > 0 . > > > > > > 96 . > > > > > > 0 . > > > > > > homes:/home/ 8194816 9072000 9174400 403671 500000 550000 > > > > > > > > > > > > > > > > > > As can be seen the 96 kb are still accounted on the quota of the user. > > > > > > Removing the 'cat' command from the script makes the quota be ok again > > > > > > (original value). Also mounting via nfs3 does not exhibit it, same for running > > > > > > the script on the nfs-server directly. > > > > > > > > > > Does "df" show the same problem? > > > > > > > > With '/bin/ls' it does not change at all, so I took a bigger binary > > > > which yields to: > > > > > > > > homes:/home/ 8203780 9072000 9174400 403688 500000 550000 > > > > 0 . > > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > > homes:/home 513671168 335251456 178419712 66% /tmp/xx > > > > 4592 . > > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > > homes:/home 513671168 335256576 178414592 66% /tmp/xx > > > > 0 . > > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > > homes:/home 513671168 335256576 178414592 66% /tmp/xx > > > > homes:/home/ 8208372 9072000 9174400 403689 500000 550000 > > > > > > > > So yes, it seems to be there as well. > > > > > > It might be easier to see with "df -i" (assuming we're leaking an > > > inode). > > > > Result is as expected, inode goes one up and not down again. > > Is this something special about binaries? If you copy something other > than a binary, do you not see the bug? No change when using a plain text file instead of a binary. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <20110320172758.GK11929@os.inf.tu-dresden.de>]
[parent not found: <20110320212633.GA26036@fieldses.org>]
[parent not found: <20110320213111.GO11929@os.inf.tu-dresden.de>]
[parent not found: <20110320214316.GB26036@fieldses.org>]
[parent not found: <20110321184043.GC4992@os.inf.tu-dresden.de>]
[parent not found: <20110321222301.GB472@fieldses.org>]
[parent not found: <20110322221305.GA5857@os.inf.tu-dresden.de>]
[parent not found: <20110323150328.GD23418@fieldses.org>]
[parent not found: <20110323174052.GE5005@os.inf.tu-dresden.de>]
* Re: 2.6.38: Quota over NFS4 [not found] ` <20110323174052.GE5005@os.inf.tu-dresden.de> @ 2011-03-23 19:06 ` J. Bruce Fields 2011-03-23 22:30 ` Adam Lackorzynski 0 siblings, 1 reply; 20+ messages in thread From: J. Bruce Fields @ 2011-03-23 19:06 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: linux-nfs On Wed, Mar 23, 2011 at 06:40:52PM +0100, Adam Lackorzynski wrote: > Hi, > > On Wed Mar 23, 2011 at 11:03:28 -0400, J. Bruce Fields wrote: > > (How'd linux-nfs get dropped off the cc:?) > > I must have accidently done single reply only, sorry. OK, assuming you won't mind my re-adding it. > > > On Tue, Mar 22, 2011 at 11:13:06PM +0100, Adam Lackorzynski wrote: > > > > > > On Mon Mar 21, 2011 at 18:23:01 -0400, J. Bruce Fields wrote: > > > > > > > > Oh, right, you'd want to unmount on the sender before copying. > > > > > > > > You *may* still get some kind of usable result if you fsck the fs you > > > > get on the receiver, but who knows. > > > > > > Ok, good news. After some fight I got it mounted in the VM. Reproducible > > > with the original 2.6.38 kernel (as released) and also reproducible with > > > latest git as of today. What now? > > > > OK, so now you can reproduce the problem on one xfs filesystem, but not > > the other. > > > > Can we find any differences between the two filesystems? Was one > > created with different features, for example? > > > > Might also be worth asking xfs developers for ideas. > > Bisecting shows this commit: That's an odd place for it to end up. You're positive the problem is reliably reproduceable after this commit and not in the commit immediately previous? --b. > 5d926e8c2f46dc09f4ddde86644a5f1d0726a470 is the first bad commit > commit 5d926e8c2f46dc09f4ddde86644a5f1d0726a470 > Author: J. Bruce Fields <bfields@redhat.com> > Date: Mon Feb 7 16:53:46 2011 -0500 > > nfsd4: modify fi_delegations under recall_lock > > Modify fi_delegations only under the recall_lock, allowing us to use > that list on lease breaks. > > Also some trivial cleanup to simplify later changes. > > Signed-off-by: J. Bruce Fields <bfields@redhat.com> > > :040000 040000 fa71771d862119d1918c40a0ea25815f2f8b16bf 5bf94b91c7c696586f0aaf8b5df1cd9c4aa70ac0 M fs > > > Adam > -- > Adam adam@os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-23 19:06 ` J. Bruce Fields @ 2011-03-23 22:30 ` Adam Lackorzynski 2011-03-24 17:17 ` Christoph Hellwig 0 siblings, 1 reply; 20+ messages in thread From: Adam Lackorzynski @ 2011-03-23 22:30 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-nfs On Wed Mar 23, 2011 at 15:06:32 -0400, J. Bruce Fields wrote: > On Wed, Mar 23, 2011 at 06:40:52PM +0100, Adam Lackorzynski wrote: > > > On Tue, Mar 22, 2011 at 11:13:06PM +0100, Adam Lackorzynski wrote: > > > > > > > > On Mon Mar 21, 2011 at 18:23:01 -0400, J. Bruce Fields wrote: > > > > > > > > > > Oh, right, you'd want to unmount on the sender before copying. > > > > > > > > > > You *may* still get some kind of usable result if you fsck the fs you > > > > > get on the receiver, but who knows. > > > > > > > > Ok, good news. After some fight I got it mounted in the VM. Reproducible > > > > with the original 2.6.38 kernel (as released) and also reproducible with > > > > latest git as of today. What now? > > > > > > OK, so now you can reproduce the problem on one xfs filesystem, but not > > > the other. > > > > > > Can we find any differences between the two filesystems? Was one > > > created with different features, for example? > > > > > > Might also be worth asking xfs developers for ideas. > > > > Bisecting shows this commit: > > That's an odd place for it to end up. You're positive the problem is > reliably reproduceable after this commit and not in the commit > immediately previous? I probably mistyped something and thus bisected again: acfdf5c383b38f7f4dddae41b97c97f1ae058f49 is the first bad commit commit acfdf5c383b38f7f4dddae41b97c97f1ae058f49 Author: J. Bruce Fields <bfields@redhat.com> Date: Mon Jan 31 19:20:39 2011 -0500 nfsd4: acquire only one lease per file Instead of acquiring one lease each time another client opens a file, nfsd can acquire just one lease to represent all of them, and reference count it to determine when to release it. This fixes a regression introduced by c45821d263a8a5109d69a9e8942b8d65bcd5f31a "locks: eliminate fl_mylease callback": after that patch, only the struct file * is used to determine who owns a given lease. But since we recently converted the server to share a single struct file per open, if we acquire multiple leases on the same file from nfsd, it then becomes impossible on unlocking a lease to determine which of those leases (all of whom share the same struct file *) we meant to remove. Thanks to Takashi Iwai <tiwai@suse.de> for catching a bug in a previous version of this patch. Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> :040000 040000 5bf94b91c7c696586f0aaf8b5df1cd9c4aa70ac0 4ee1f39f455ee7f648fccedc1ddba4da6a94cec7 M fs Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-23 22:30 ` Adam Lackorzynski @ 2011-03-24 17:17 ` Christoph Hellwig 0 siblings, 0 replies; 20+ messages in thread From: Christoph Hellwig @ 2011-03-24 17:17 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: J. Bruce Fields, linux-nfs, xfs On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > I probably mistyped something and thus bisected again: maybe this is just a symptom. When was the nfs4 code converted to just use a single open struct file, and what are the lifetime rules for it? It would easily be that a long alive file might make XFS keep persistent preallocations longer or similar issues. Adam, can you create a loop filesystem with ext3 or something else on it and see if the problem is XFS-specific? _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 @ 2011-03-24 17:17 ` Christoph Hellwig 0 siblings, 0 replies; 20+ messages in thread From: Christoph Hellwig @ 2011-03-24 17:17 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: J. Bruce Fields, linux-nfs, xfs On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > I probably mistyped something and thus bisected again: maybe this is just a symptom. When was the nfs4 code converted to just use a single open struct file, and what are the lifetime rules for it? It would easily be that a long alive file might make XFS keep persistent preallocations longer or similar issues. Adam, can you create a loop filesystem with ext3 or something else on it and see if the problem is XFS-specific? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-24 17:17 ` Christoph Hellwig @ 2011-03-24 17:51 ` J. Bruce Fields -1 siblings, 0 replies; 20+ messages in thread From: J. Bruce Fields @ 2011-03-24 17:51 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-nfs, Adam Lackorzynski, xfs On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > I probably mistyped something and thus bisected again: > > maybe this is just a symptom. When was the nfs4 code converted > to just use a single open struct file, and what are the lifetime > rules for it? It would easily be that a long alive file might > make XFS keep persistent preallocations longer or similar issues. Definitely, the commit he's bisect to there seems much more likely to be a culprit. I'll take a closer look.... > Adam, can you create a loop filesystem with ext3 or something else > on it and see if the problem is XFS-specific? Originally it sounded like he was able to reproduce this only on one specific filesystem so I wondered whether there was something particular to that filesystem. --b. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 @ 2011-03-24 17:51 ` J. Bruce Fields 0 siblings, 0 replies; 20+ messages in thread From: J. Bruce Fields @ 2011-03-24 17:51 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Adam Lackorzynski, linux-nfs, xfs On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > I probably mistyped something and thus bisected again: > > maybe this is just a symptom. When was the nfs4 code converted > to just use a single open struct file, and what are the lifetime > rules for it? It would easily be that a long alive file might > make XFS keep persistent preallocations longer or similar issues. Definitely, the commit he's bisect to there seems much more likely to be a culprit. I'll take a closer look.... > Adam, can you create a loop filesystem with ext3 or something else > on it and see if the problem is XFS-specific? Originally it sounded like he was able to reproduce this only on one specific filesystem so I wondered whether there was something particular to that filesystem. --b. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-24 17:51 ` J. Bruce Fields @ 2011-03-24 22:28 ` Adam Lackorzynski -1 siblings, 0 replies; 20+ messages in thread From: Adam Lackorzynski @ 2011-03-24 22:28 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Christoph Hellwig, linux-nfs, xfs On Thu Mar 24, 2011 at 13:51:06 -0400, J. Bruce Fields wrote: > On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > > I probably mistyped something and thus bisected again: > > > > maybe this is just a symptom. When was the nfs4 code converted > > to just use a single open struct file, and what are the lifetime > > rules for it? It would easily be that a long alive file might > > make XFS keep persistent preallocations longer or similar issues. > > Definitely, the commit he's bisect to there seems much more likely to be > a culprit. I'll take a closer look.... > > > Adam, can you create a loop filesystem with ext3 or something else > > on it and see if the problem is XFS-specific? > > Originally it sounded like he was able to reproduce this only on one > specific filesystem so I wondered whether there was something particular > to that filesystem. I just found out it happens also with a newly created xfs and also with ext3 and ext4. The reason that I did not see that initially is that the script I'm using needs to be on the same fs which wasn't the case when I initially tried it with a new fs. The sequence I'm using is: # mount x.x.x:/home /tmp/st # su - foo $ cd /tmp/st/foo/x $ ../test-script foo@host:/tmp/st/foo/x$ ../test-script Filesystem Inodes IUsed IFree IUse% Mounted on x.x.x:/home 39321600 15 39321585 1% /tmp/st Filesystem Inodes IUsed IFree IUse% Mounted on x.x.x:/home 39321600 16 39321584 1% /tmp/st Filesystem Inodes IUsed IFree IUse% Mounted on x.x.x:/home 39321600 16 39321584 1% /tmp/st test-script: #! /bin/sh df -i . cp /bin/ls x1 df -i . cat x1 > /dev/null rm x1 df -i . Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 @ 2011-03-24 22:28 ` Adam Lackorzynski 0 siblings, 0 replies; 20+ messages in thread From: Adam Lackorzynski @ 2011-03-24 22:28 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Christoph Hellwig, linux-nfs, xfs On Thu Mar 24, 2011 at 13:51:06 -0400, J. Bruce Fields wrote: > On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > > I probably mistyped something and thus bisected again: > > > > maybe this is just a symptom. When was the nfs4 code converted > > to just use a single open struct file, and what are the lifetime > > rules for it? It would easily be that a long alive file might > > make XFS keep persistent preallocations longer or similar issues. > > Definitely, the commit he's bisect to there seems much more likely to be > a culprit. I'll take a closer look.... > > > Adam, can you create a loop filesystem with ext3 or something else > > on it and see if the problem is XFS-specific? > > Originally it sounded like he was able to reproduce this only on one > specific filesystem so I wondered whether there was something particular > to that filesystem. I just found out it happens also with a newly created xfs and also with ext3 and ext4. The reason that I did not see that initially is that the script I'm using needs to be on the same fs which wasn't the case when I initially tried it with a new fs. The sequence I'm using is: # mount x.x.x:/home /tmp/st # su - foo $ cd /tmp/st/foo/x $ ../test-script foo@host:/tmp/st/foo/x$ ../test-script Filesystem Inodes IUsed IFree IUse% Mounted on x.x.x:/home 39321600 15 39321585 1% /tmp/st Filesystem Inodes IUsed IFree IUse% Mounted on x.x.x:/home 39321600 16 39321584 1% /tmp/st Filesystem Inodes IUsed IFree IUse% Mounted on x.x.x:/home 39321600 16 39321584 1% /tmp/st test-script: #! /bin/sh df -i . cp /bin/ls x1 df -i . cat x1 > /dev/null rm x1 df -i . Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-24 22:28 ` Adam Lackorzynski @ 2011-03-25 0:03 ` J. Bruce Fields -1 siblings, 0 replies; 20+ messages in thread From: J. Bruce Fields @ 2011-03-25 0:03 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Christoph Hellwig, linux-nfs, xfs On Thu, Mar 24, 2011 at 11:28:07PM +0100, Adam Lackorzynski wrote: > > On Thu Mar 24, 2011 at 13:51:06 -0400, J. Bruce Fields wrote: > > On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > > > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > > > I probably mistyped something and thus bisected again: > > > > > > maybe this is just a symptom. When was the nfs4 code converted > > > to just use a single open struct file, and what are the lifetime > > > rules for it? It would easily be that a long alive file might > > > make XFS keep persistent preallocations longer or similar issues. > > > > Definitely, the commit he's bisect to there seems much more likely to be > > a culprit. I'll take a closer look.... > > > > > Adam, can you create a loop filesystem with ext3 or something else > > > on it and see if the problem is XFS-specific? > > > > Originally it sounded like he was able to reproduce this only on one > > specific filesystem so I wondered whether there was something particular > > to that filesystem. > > I just found out it happens also with a newly created xfs and also with > ext3 and ext4. The reason that I did not see that initially is that the > script I'm using needs to be on the same fs which wasn't the case when I > initially tried it with a new fs. The sequence I'm using is: Ah-hah, got it. So the leak's probably of a delegation on the file containing the script itself. OK, I should be able to fix that, thanks! --b. > > # mount x.x.x:/home /tmp/st > # su - foo > $ cd /tmp/st/foo/x > $ ../test-script > foo@host:/tmp/st/foo/x$ ../test-script > Filesystem Inodes IUsed IFree IUse% Mounted on > x.x.x:/home 39321600 15 39321585 1% /tmp/st > Filesystem Inodes IUsed IFree IUse% Mounted on > x.x.x:/home 39321600 16 39321584 1% /tmp/st > Filesystem Inodes IUsed IFree IUse% Mounted on > x.x.x:/home 39321600 16 39321584 1% /tmp/st > > > > test-script: > #! /bin/sh > > df -i . > cp /bin/ls x1 > df -i . > cat x1 > /dev/null > rm x1 > df -i . > > > > > > > Adam > -- > Adam adam@os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 @ 2011-03-25 0:03 ` J. Bruce Fields 0 siblings, 0 replies; 20+ messages in thread From: J. Bruce Fields @ 2011-03-25 0:03 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Christoph Hellwig, linux-nfs, xfs On Thu, Mar 24, 2011 at 11:28:07PM +0100, Adam Lackorzynski wrote: > > On Thu Mar 24, 2011 at 13:51:06 -0400, J. Bruce Fields wrote: > > On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > > > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > > > I probably mistyped something and thus bisected again: > > > > > > maybe this is just a symptom. When was the nfs4 code converted > > > to just use a single open struct file, and what are the lifetime > > > rules for it? It would easily be that a long alive file might > > > make XFS keep persistent preallocations longer or similar issues. > > > > Definitely, the commit he's bisect to there seems much more likely to be > > a culprit. I'll take a closer look.... > > > > > Adam, can you create a loop filesystem with ext3 or something else > > > on it and see if the problem is XFS-specific? > > > > Originally it sounded like he was able to reproduce this only on one > > specific filesystem so I wondered whether there was something particular > > to that filesystem. > > I just found out it happens also with a newly created xfs and also with > ext3 and ext4. The reason that I did not see that initially is that the > script I'm using needs to be on the same fs which wasn't the case when I > initially tried it with a new fs. The sequence I'm using is: Ah-hah, got it. So the leak's probably of a delegation on the file containing the script itself. OK, I should be able to fix that, thanks! --b. > > # mount x.x.x:/home /tmp/st > # su - foo > $ cd /tmp/st/foo/x > $ ../test-script > foo@host:/tmp/st/foo/x$ ../test-script > Filesystem Inodes IUsed IFree IUse% Mounted on > x.x.x:/home 39321600 15 39321585 1% /tmp/st > Filesystem Inodes IUsed IFree IUse% Mounted on > x.x.x:/home 39321600 16 39321584 1% /tmp/st > Filesystem Inodes IUsed IFree IUse% Mounted on > x.x.x:/home 39321600 16 39321584 1% /tmp/st > > > > test-script: > #! /bin/sh > > df -i . > cp /bin/ls x1 > df -i . > cat x1 > /dev/null > rm x1 > df -i . > > > > > > > Adam > -- > Adam adam@os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-25 0:03 ` J. Bruce Fields @ 2011-04-22 19:31 ` J. Bruce Fields -1 siblings, 0 replies; 20+ messages in thread From: J. Bruce Fields @ 2011-04-22 19:31 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Christoph Hellwig, linux-nfs, xfs On Thu, Mar 24, 2011 at 08:03:10PM -0400, J. Bruce Fields wrote: > On Thu, Mar 24, 2011 at 11:28:07PM +0100, Adam Lackorzynski wrote: > > > > On Thu Mar 24, 2011 at 13:51:06 -0400, J. Bruce Fields wrote: > > > On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > > > > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > > > > I probably mistyped something and thus bisected again: > > > > > > > > maybe this is just a symptom. When was the nfs4 code converted > > > > to just use a single open struct file, and what are the lifetime > > > > rules for it? It would easily be that a long alive file might > > > > make XFS keep persistent preallocations longer or similar issues. > > > > > > Definitely, the commit he's bisect to there seems much more likely to be > > > a culprit. I'll take a closer look.... > > > > > > > Adam, can you create a loop filesystem with ext3 or something else > > > > on it and see if the problem is XFS-specific? > > > > > > Originally it sounded like he was able to reproduce this only on one > > > specific filesystem so I wondered whether there was something particular > > > to that filesystem. > > > > I just found out it happens also with a newly created xfs and also with > > ext3 and ext4. The reason that I did not see that initially is that the > > script I'm using needs to be on the same fs which wasn't the case when I > > initially tried it with a new fs. The sequence I'm using is: > > Ah-hah, got it. So the leak's probably of a delegation on the file > containing the script itself. OK, I should be able to fix that, thanks! This should be fixed in the latest upstream (so, in 39-rc5, when that comes out) and soon in stable. Let me know if not. --b. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 @ 2011-04-22 19:31 ` J. Bruce Fields 0 siblings, 0 replies; 20+ messages in thread From: J. Bruce Fields @ 2011-04-22 19:31 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Christoph Hellwig, linux-nfs, xfs On Thu, Mar 24, 2011 at 08:03:10PM -0400, J. Bruce Fields wrote: > On Thu, Mar 24, 2011 at 11:28:07PM +0100, Adam Lackorzynski wrote: > > > > On Thu Mar 24, 2011 at 13:51:06 -0400, J. Bruce Fields wrote: > > > On Thu, Mar 24, 2011 at 01:17:05PM -0400, Christoph Hellwig wrote: > > > > On Wed, Mar 23, 2011 at 11:30:17PM +0100, Adam Lackorzynski wrote: > > > > > I probably mistyped something and thus bisected again: > > > > > > > > maybe this is just a symptom. When was the nfs4 code converted > > > > to just use a single open struct file, and what are the lifetime > > > > rules for it? It would easily be that a long alive file might > > > > make XFS keep persistent preallocations longer or similar issues. > > > > > > Definitely, the commit he's bisect to there seems much more likely to be > > > a culprit. I'll take a closer look.... > > > > > > > Adam, can you create a loop filesystem with ext3 or something else > > > > on it and see if the problem is XFS-specific? > > > > > > Originally it sounded like he was able to reproduce this only on one > > > specific filesystem so I wondered whether there was something particular > > > to that filesystem. > > > > I just found out it happens also with a newly created xfs and also with > > ext3 and ext4. The reason that I did not see that initially is that the > > script I'm using needs to be on the same fs which wasn't the case when I > > initially tried it with a new fs. The sequence I'm using is: > > Ah-hah, got it. So the leak's probably of a delegation on the file > containing the script itself. OK, I should be able to fix that, thanks! This should be fixed in the latest upstream (so, in 39-rc5, when that comes out) and soon in stable. Let me know if not. --b. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.38: Quota over NFS4 2011-03-17 13:32 2.6.38: Quota over NFS4 Adam Lackorzynski 2011-03-17 17:38 ` J. Bruce Fields @ 2011-03-20 19:49 ` Maciej Rutecki 1 sibling, 0 replies; 20+ messages in thread From: Maciej Rutecki @ 2011-03-20 19:49 UTC (permalink / raw) To: Adam Lackorzynski; +Cc: Trond Myklebust, linux-kernel, linux-nfs On czwartek, 17 marca 2011 o 14:32:47 Adam Lackorzynski wrote: > Hello, > > I'm seeing a problem with quotas in a system where the server running > 2.6.38 exports an XFS filesystem via NFS4 to a client. The client kernel > version does not seem to play a role, checked with 2.6.38, 2.6.37 and > 2.6.36. The following script and output show the problem: > > #! /bin/sh > > quota | grep home > du > cp /bin/ls x1 > du > cat x1 > /dev/null > rm x1 > du > quota | grep home > > Output: > > homes:/home/ 8194720 9072000 9174400 403670 500000 550000 > 0 . > 96 . > 0 . > homes:/home/ 8194816 9072000 9174400 403671 500000 550000 > > > As can be seen the 96 kb are still accounted on the quota of the user. > Removing the 'cat' command from the script makes the quota be ok again > (original value). Also mounting via nfs3 does not exhibit it, same for > running the script on the nfs-server directly. > > Client mount options are: > homes:/home/ /home nfs4 > rw,nosuid,nodev,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,har > d,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.3,minorvers > ion=0,local_lock=none,addr=1.2.3.4 0 0 > > Server mount options are: > /dev/mapper/vg-homefs /home xfs rw,nosuid,nodev,relatime,attr2,usrquota 0 0 > > I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=31532 for your bug report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.maciek.unixy.pl ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-04-22 19:31 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-17 13:32 2.6.38: Quota over NFS4 Adam Lackorzynski
2011-03-17 17:38 ` J. Bruce Fields
2011-03-17 21:33 ` Adam Lackorzynski
2011-03-17 22:27 ` J. Bruce Fields
2011-03-17 22:59 ` Adam Lackorzynski
2011-03-17 23:03 ` J. Bruce Fields
2011-03-17 23:16 ` Adam Lackorzynski
[not found] ` <20110320172758.GK11929@os.inf.tu-dresden.de>
[not found] ` <20110320212633.GA26036@fieldses.org>
[not found] ` <20110320213111.GO11929@os.inf.tu-dresden.de>
[not found] ` <20110320214316.GB26036@fieldses.org>
[not found] ` <20110321184043.GC4992@os.inf.tu-dresden.de>
[not found] ` <20110321222301.GB472@fieldses.org>
[not found] ` <20110322221305.GA5857@os.inf.tu-dresden.de>
[not found] ` <20110323150328.GD23418@fieldses.org>
[not found] ` <20110323174052.GE5005@os.inf.tu-dresden.de>
2011-03-23 19:06 ` J. Bruce Fields
2011-03-23 22:30 ` Adam Lackorzynski
2011-03-24 17:17 ` Christoph Hellwig
2011-03-24 17:17 ` Christoph Hellwig
2011-03-24 17:51 ` J. Bruce Fields
2011-03-24 17:51 ` J. Bruce Fields
2011-03-24 22:28 ` Adam Lackorzynski
2011-03-24 22:28 ` Adam Lackorzynski
2011-03-25 0:03 ` J. Bruce Fields
2011-03-25 0:03 ` J. Bruce Fields
2011-04-22 19:31 ` J. Bruce Fields
2011-04-22 19:31 ` J. Bruce Fields
2011-03-20 19:49 ` Maciej Rutecki
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.