* Re: layoutcommit space reservation for the objlayout driver
[not found] <1538636805.101.1410805338811.JavaMail.root@thunderbeast.private.linuxbox.com>
@ 2014-09-15 18:22 ` Daniel Gryniewicz
2014-09-15 21:11 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Gryniewicz @ 2014-09-15 18:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Benny Halevy, linux-nfs, Boaz Harrosh
----- "Christoph Hellwig" <hch@lst.de> wrote:
> On Mon, Sep 15, 2014 at 12:05:55PM +0300, Boaz Harrosh wrote:
> > I do not understand. This used to work just fine. Please point me
> to
> > the patch that broke it?
> > (And since when are we allowed to brake old code?)
>
> I bet it still works the same way it does as commited, which doesn't
> make it right. The way the NFS XDR buffer allocations work seems to
> be
> that you can actually slightly overun it without things falling
> apart,
> but that doesn't make it right. E.g. it took a fairly larger overrun
> in the block layout driver to finally find the issues, and most of
> the
> time it was just silent truncations, real corruption happened less
> often.
>
> But to make sure things work properly in the long run you'd really
> want
> to have the proper allocation.
This is probably the case, then. The object layout layoutupdate is only 16 bytes long and is fixed size, so it wouldn't take much extra space for it to never hit.
Daniel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: layoutcommit space reservation for the objlayout driver
2014-09-15 18:22 ` layoutcommit space reservation for the objlayout driver Daniel Gryniewicz
@ 2014-09-15 21:11 ` Christoph Hellwig
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2014-09-15 21:11 UTC (permalink / raw)
To: Daniel Gryniewicz; +Cc: Benny Halevy, linux-nfs, Boaz Harrosh
On Mon, Sep 15, 2014 at 02:22:33PM -0400, Daniel Gryniewicz wrote:
> This is probably the case, then. The object layout layoutupdate is only 16 bytes long and is fixed size, so it wouldn't take much extra space for it to never hit.
Yes, I suspect at the moment we just overallocate the XDR buffer due
to slab or nfs implementation details, which are bound to chance as some
point without notice.
^ permalink raw reply [flat|nested] 6+ messages in thread
* layoutcommit space reservation for the objlayout driver
@ 2014-09-14 16:46 Christoph Hellwig
2014-09-15 9:05 ` Boaz Harrosh
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2014-09-14 16:46 UTC (permalink / raw)
To: Boaz Harrosh, Benny Halevy; +Cc: linux-nfs
Currently the NFS client does not reserved any space for the layoutupdate
field when encoding a layoutcommit. For the file layout driver which doesn't
have a layoutupdate that's obviously fine, and for the block layoutdriver
I just fixed the issue in my series by allowing to split in a set of
preallocated pages. The objlayout driver still needs this fixed, either
by convincing Trond to increase the reservatation for the few objlayout
fields, or by splicing in the pages like the block layout driver does.
Can someone with an objlayout setup take care of this?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: layoutcommit space reservation for the objlayout driver
2014-09-14 16:46 Christoph Hellwig
@ 2014-09-15 9:05 ` Boaz Harrosh
2014-09-15 17:12 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Boaz Harrosh @ 2014-09-15 9:05 UTC (permalink / raw)
To: Christoph Hellwig, Benny Halevy; +Cc: linux-nfs
On 09/14/2014 07:46 PM, Christoph Hellwig wrote:
> Currently the NFS client does not reserved any space for the layoutupdate
> field when encoding a layoutcommit. For the file layout driver which doesn't
> have a layoutupdate that's obviously fine, and for the block layoutdriver
> I just fixed the issue in my series by allowing to split in a set of
> preallocated pages. The objlayout driver still needs this fixed, either
> by convincing Trond to increase the reservatation for the few objlayout
> fields, or by splicing in the pages like the block layout driver does.
>
> Can someone with an objlayout setup take care of this?
>
I do not understand. This used to work just fine. Please point me to
the patch that broke it?
(And since when are we allowed to brake old code?)
It will take me a bit of time to get up to speed. Do you want to attempt
a patch and I'll test it?
Thanks
Boaz
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: layoutcommit space reservation for the objlayout driver
2014-09-15 9:05 ` Boaz Harrosh
@ 2014-09-15 17:12 ` Christoph Hellwig
2014-09-16 8:32 ` Boaz Harrosh
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2014-09-15 17:12 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Christoph Hellwig, Benny Halevy, linux-nfs
On Mon, Sep 15, 2014 at 12:05:55PM +0300, Boaz Harrosh wrote:
> I do not understand. This used to work just fine. Please point me to
> the patch that broke it?
> (And since when are we allowed to brake old code?)
I bet it still works the same way it does as commited, which doesn't
make it right. The way the NFS XDR buffer allocations work seems to be
that you can actually slightly overun it without things falling apart,
but that doesn't make it right. E.g. it took a fairly larger overrun
in the block layout driver to finally find the issues, and most of the
time it was just silent truncations, real corruption happened less
often.
But to make sure things work properly in the long run you'd really want
to have the proper allocation.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: layoutcommit space reservation for the objlayout driver
2014-09-15 17:12 ` Christoph Hellwig
@ 2014-09-16 8:32 ` Boaz Harrosh
0 siblings, 0 replies; 6+ messages in thread
From: Boaz Harrosh @ 2014-09-16 8:32 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Benny Halevy, linux-nfs
On 09/15/2014 08:12 PM, Christoph Hellwig wrote:
> On Mon, Sep 15, 2014 at 12:05:55PM +0300, Boaz Harrosh wrote:
>> I do not understand. This used to work just fine. Please point me to
>> the patch that broke it?
>> (And since when are we allowed to brake old code?)
>
> I bet it still works the same way it does as commited, which doesn't
> make it right. The way the NFS XDR buffer allocations work seems to be
> that you can actually slightly overun it without things falling apart,
> but that doesn't make it right. E.g. it took a fairly larger overrun
> in the block layout driver to finally find the issues, and most of the
> time it was just silent truncations, real corruption happened less
> often.
>
> But to make sure things work properly in the long run you'd really want
> to have the proper allocation.
>
Thanks Christoph for explaining. OK make sense what you said. Actually I
know why it works. You know that extra page we have at nfs-xdr for if
a struct spans two pages than the xdr code will memcpy it it a spare
buffer contiguous and return that. Ha, no, that is for decoding.
But I bet for encoding there is spare buffers as well.
I will try to push for a two 64bit growth at the core reservation for
pnf-obj. No point in adding a full page for extra 16 bytes. I bet it
will not change anything because of the reserved space.
I'm not familiar with this code, I'll try to find where
core reservation is allocated for layout update?
Thanks
Boaz
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-09-16 8:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1538636805.101.1410805338811.JavaMail.root@thunderbeast.private.linuxbox.com>
2014-09-15 18:22 ` layoutcommit space reservation for the objlayout driver Daniel Gryniewicz
2014-09-15 21:11 ` Christoph Hellwig
2014-09-14 16:46 Christoph Hellwig
2014-09-15 9:05 ` Boaz Harrosh
2014-09-15 17:12 ` Christoph Hellwig
2014-09-16 8:32 ` Boaz Harrosh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).