headers
Benny Halevy | 2 Oct 2011 09:15

Re: Block layout status

On 2011-09-29 19:52, Jim Rees wrote:
> Since the call doesn't seem to be happening, here's my status.
> 
> On 16 Sep I sent these bug fixes to Trond for 3.1:
> 
> Jim Rees (2):
>   pnfsblock: fix size of upcall message     
>   pnfsblock: fix return code confusion          
> Peng Tao (3):
>   pnfsblock: fix NULL pointer dereference                
>   pnfsblock: fix writeback deadlock   
>   pnfsblock: add missing rpc_put_mount and path_put
> 
> These are the ones I think are important enough, and low enough risk to
> anyone else, that they should be considered for 3.1 even though it's late in
> the release cycle.  They have not shown up upstream.  Trond?
> 
> On 22 Sep I sent these to Trond for 3.2.  I believe these are all in Benny's
> tree now (sorry about that, Benny):
> 
> Jim Rees (2):
>   pnfsblock: fix return code confusion
>   pnfsblock: fix size of upcall message
> Peng Tao (8):
>   SUNRPC/NFS: make rpc pipe upcall generic
>   pnfsblock: add missing rpc_put_mount and path_put
>   pnfs: make _set_lo_fail generic
> - pnfsblock: init pg_bsize properly
>   pnfs: recoalesce when ld write pagelist fails
>   pnfs: recoalesce when ld read pagelist fails
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luk Claes | 2 Oct 2011 19:27
Picon
Favicon

[PATCH] blkmapd: Use getconf(_SC_PAGE_SIZE)

PAGE_SIZE is not exported by all architectures as it is not fixed: it can depend on the model of the machine.
So it's better to query the system configuration for the actual page size on the machine.

Signed-off-by: Luk Claes <luk@...>
---
 utils/blkmapd/device-process.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/utils/blkmapd/device-process.c b/utils/blkmapd/device-process.c
index 27ff374..652a7a8 100644
--- a/utils/blkmapd/device-process.c
+++ b/utils/blkmapd/device-process.c
 <at>  <at>  -296,7 +296,7  <at>  <at>  decode_blk_volume(uint32_t **pp, uint32_t *end, struct bl_volume *vols, int voln
 		off_t stripe_unit = vol->param.bv_stripe_unit;
 		/* Check limitations imposed by device-mapper */
 		if ((stripe_unit & (stripe_unit - 1)) != 0
-		    || stripe_unit < (off_t) (PAGE_SIZE >> 9))
+		    || stripe_unit < (off_t) (sysconf(_SC_PAGE_SIZE) >> 9))
 			return -EIO;
 		BLK_READBUF(p, end, 4);
 		READ32(vol->bv_vol_n);
--

-- 
1.7.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luk Claes | 2 Oct 2011 19:40
Picon
Favicon

[PATCH] nfs.man: Fix macro use

The groff macros for filling (word-wrapping) and tabulation control are
lower-case, but are written in upper-case here and so have been ignored.

Change the .NF and .FI lines to lower-case.

Change the .TA lines to lower-case and fix the tab stops to work both
on a terminal and in Postscript output.

Signed-off-by: Luk Claes <luk@...>
---
 utils/mount/nfs.man |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index ce40933..2ad92d1 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
 <at>  <at>  -1561,10 +1561,10  <at>  <at>  To ensure that the saved mount options are not erased during a remount,
 specify either the local mount directory, or the server hostname and
 export pathname, but not both, during a remount.  For example,
 .P
-.NF
-.TA 2.5i
+.nf
+.ta 8n
 	mount -o remount,ro /mnt
-.FI
+.fi
 .P
 merges the mount option
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boaz Harrosh | 3 Oct 2011 11:20
Favicon
Gravatar

Re: Block layout status

On 09/29/2011 07:52 PM, Jim Rees wrote:
> Since the call doesn't seem to be happening, here's my status.
> 
> On 16 Sep I sent these bug fixes to Trond for 3.1:
> 
> Jim Rees (2):
>   pnfsblock: fix size of upcall message     
>   pnfsblock: fix return code confusion          
> Peng Tao (3):
>   pnfsblock: fix NULL pointer dereference                
>   pnfsblock: fix writeback deadlock   
>   pnfsblock: add missing rpc_put_mount and path_put
> 
> These are the ones I think are important enough, and low enough risk to
> anyone else, that they should be considered for 3.1 even though it's late in
> the release cycle.  They have not shown up upstream.  Trond?
> 
> On 22 Sep I sent these to Trond for 3.2.  I believe these are all in Benny's
> tree now (sorry about that, Benny):
> 
> Jim Rees (2):
>   pnfsblock: fix return code confusion
>   pnfsblock: fix size of upcall message
> Peng Tao (8):
>   SUNRPC/NFS: make rpc pipe upcall generic
>   pnfsblock: add missing rpc_put_mount and path_put
>   pnfs: make _set_lo_fail generic
> - pnfsblock: init pg_bsize properly
>   pnfs: recoalesce when ld write pagelist fails
>   pnfs: recoalesce when ld read pagelist fails
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Rees | 3 Oct 2011 14:43
Picon

Re: Block layout status

Boaz Harrosh wrote:

  On 09/29/2011 07:52 PM, Jim Rees wrote:
  > Since the call doesn't seem to be happening, here's my status.
  > 
  > On 16 Sep I sent these bug fixes to Trond for 3.1:
  > 
  > Jim Rees (2):
  >   pnfsblock: fix size of upcall message     
  >   pnfsblock: fix return code confusion          
  > Peng Tao (3):
  >   pnfsblock: fix NULL pointer dereference                
  >   pnfsblock: fix writeback deadlock   
  >   pnfsblock: add missing rpc_put_mount and path_put
  > 
  > These are the ones I think are important enough, and low enough risk to
  > anyone else, that they should be considered for 3.1 even though it's late in
  > the release cycle.  They have not shown up upstream.  Trond?
  > 
  > On 22 Sep I sent these to Trond for 3.2.  I believe these are all in Benny's
  > tree now (sorry about that, Benny):
  > 
  > Jim Rees (2):
  >   pnfsblock: fix return code confusion
  >   pnfsblock: fix size of upcall message
  > Peng Tao (8):
  >   SUNRPC/NFS: make rpc pipe upcall generic
  >   pnfsblock: add missing rpc_put_mount and path_put
  >   pnfs: make _set_lo_fail generic
  > - pnfsblock: init pg_bsize properly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Dickson | 3 Oct 2011 14:54
Picon
Favicon

Re: [PATCH] blkmapd: Use getconf(_SC_PAGE_SIZE)


On 10/02/2011 01:27 PM, Luk Claes wrote:
> PAGE_SIZE is not exported by all architectures as it is not fixed: it can depend on the model of the machine.
So it's better to query the system configuration for the actual page size on the machine.
> 
> Signed-off-by: Luk Claes <luk@...>
Committed...

steved.
> ---
>  utils/blkmapd/device-process.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/utils/blkmapd/device-process.c b/utils/blkmapd/device-process.c
> index 27ff374..652a7a8 100644
> --- a/utils/blkmapd/device-process.c
> +++ b/utils/blkmapd/device-process.c
>  <at>  <at>  -296,7 +296,7  <at>  <at>  decode_blk_volume(uint32_t **pp, uint32_t *end, struct bl_volume *vols, int voln
>  		off_t stripe_unit = vol->param.bv_stripe_unit;
>  		/* Check limitations imposed by device-mapper */
>  		if ((stripe_unit & (stripe_unit - 1)) != 0
> -		    || stripe_unit < (off_t) (PAGE_SIZE >> 9))
> +		    || stripe_unit < (off_t) (sysconf(_SC_PAGE_SIZE) >> 9))
>  			return -EIO;
>  		BLK_READBUF(p, end, 4);
>  		READ32(vol->bv_vol_n);
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benny Halevy | 3 Oct 2011 16:43

Re: [PATCH 4/5] nfsd4: construct stateid from clientid and counter

Bruce, it seems with this patch, doing si_opaque.so_id = current_stateid
makes all stateid's unique, regardless of their type.
Is find_stateid_by_type still needed?

And if the opaque part of the stateid isn't unique,
shouldn't find_stateid_by_type go over the hash bucket by itself
to look for other stateid's sharing the same opaque but having
the type it is looking for?

Benny

On 2011-09-19 16:15, J. Bruce Fields wrote:
> Including the full clientid in the on-the-wire stateid allows more
> reliable detection of bad vs. expired stateid's, simplifies code, and
> ensures we won't reuse the opaque part of the stateid (as we currently
> do when the same openowner closes and reopens the same file).
> 
> Signed-off-by: J. Bruce Fields <bfields@...>
> ---
>  fs/nfsd/nfs4state.c |   58 +++++++++++---------------------------------------
>  fs/nfsd/state.h     |   18 ++++-----------
>  2 files changed, 18 insertions(+), 58 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index fdd03f6..922f47d 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
>  <at>  <at>  -49,9 +49,7  <at>  <at> 
>  time_t nfsd4_lease = 90;     /* default lease time */
>  time_t nfsd4_grace = 90;
(Continue reading)

Permalink | Reply | 5 comments |
headers
J. Bruce Fields | 3 Oct 2011 16:57
Picon
Favicon

Re: [PATCH 4/5] nfsd4: construct stateid from clientid and counter

On Mon, Oct 03, 2011 at 04:43:40PM +0200, Benny Halevy wrote:
> Bruce, it seems with this patch, doing si_opaque.so_id = current_stateid
> makes all stateid's unique, regardless of their type.
> Is find_stateid_by_type still needed?
> 
> And if the opaque part of the stateid isn't unique,
> shouldn't find_stateid_by_type go over the hash bucket by itself
> to look for other stateid's sharing the same opaque but having
> the type it is looking for?

Stateid's have actually always been unique--they'd have to be, since
e.g. READ doesn't come with any indication of which type of stateid
you're being given.  All find_stateid_by_type() does is fail when it
doesn't find something of the right type.

I did think at the time that find_stateid_by_type() was a confusing name
for that reason, but couldn't come up with a better idea.  Maybe it
should be find_stateid_of_type() or find_stateid_if_type()....

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Benny Halevy | 3 Oct 2011 17:13

Re: [PATCH 4/5] nfsd4: construct stateid from clientid and counter

On 2011-10-03 16:57, J. Bruce Fields wrote:
> On Mon, Oct 03, 2011 at 04:43:40PM +0200, Benny Halevy wrote:
>> Bruce, it seems with this patch, doing si_opaque.so_id = current_stateid
>> makes all stateid's unique, regardless of their type.
>> Is find_stateid_by_type still needed?
>>
>> And if the opaque part of the stateid isn't unique,
>> shouldn't find_stateid_by_type go over the hash bucket by itself
>> to look for other stateid's sharing the same opaque but having
>> the type it is looking for?
> 
> Stateid's have actually always been unique--they'd have to be, since
> e.g. READ doesn't come with any indication of which type of stateid
> you're being given.  All find_stateid_by_type() does is fail when it
> doesn't find something of the right type.
> 

So I'm still confused.  That's what I thought.
So in what cases find_stateid that find_stateid_by_type calls
will find a stateid structure with a non-matching sc_type?

Benny

> I did think at the time that find_stateid_by_type() was a confusing name
> for that reason, but couldn't come up with a better idea.  Maybe it
> should be find_stateid_of_type() or find_stateid_if_type()....
> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
(Continue reading)

Permalink | Reply | 3 comments |
headers
J. Bruce Fields | 3 Oct 2011 17:38
Picon
Favicon

Re: [PATCH 4/5] nfsd4: construct stateid from clientid and counter

On Mon, Oct 03, 2011 at 05:13:24PM +0200, Benny Halevy wrote:
> On 2011-10-03 16:57, J. Bruce Fields wrote:
> > On Mon, Oct 03, 2011 at 04:43:40PM +0200, Benny Halevy wrote:
> >> Bruce, it seems with this patch, doing si_opaque.so_id = current_stateid
> >> makes all stateid's unique, regardless of their type.
> >> Is find_stateid_by_type still needed?
> >>
> >> And if the opaque part of the stateid isn't unique,
> >> shouldn't find_stateid_by_type go over the hash bucket by itself
> >> to look for other stateid's sharing the same opaque but having
> >> the type it is looking for?
> > 
> > Stateid's have actually always been unique--they'd have to be, since
> > e.g. READ doesn't come with any indication of which type of stateid
> > you're being given.  All find_stateid_by_type() does is fail when it
> > doesn't find something of the right type.
> > 
> 
> So I'm still confused.  That's what I thought.
> So in what cases find_stateid that find_stateid_by_type calls
> will find a stateid structure with a non-matching sc_type?

Suppose, for example, the server gets a DELEGRETURN, looks up the
provided stateid, and finds an open stateid.

At this point either the client is buggy, or else something very
unlikely has happened.  (E.g. a stateid was retired and then reused).

So find_stateid_by_type() returns NULL which the caller will likely
translate to something like BAD_STATEID.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane