The only 1 cent that I can add to this argument is that I was led to believe by you and others that Linux kernel don't add functionality on the client side that is not supported on the server side. Last time I made this point I was told that it is ok if they are of by a version or two. You made it clear that this is no longer true and that the Linux client and server are now independent of each other. I spent time working on the server side believing that the client and server will progress more or less together, disappointed to find out that it is not the case any more. Marc. From: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> To: Boaz Harrosh <bharrosh@xxxxxxxxxxx> Cc: Peng Tao <bergwolf@xxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, bhalevy@xxxxxxxxxx, Garth Gibson <garth@xxxxxxxxxxx>, Matt Benjamin <matt@xxxxxxxxxxxx>, Marc Eshel <eshel@xxxxxxxxxxxxxxx>, Fred Isaman <iisaman@xxxxxxxxxx> Date: 11/29/2011 03:30 PM Subject: Re: [PATCH 0/4] nfs41: allow layoutget at pnfs_do_multiple_writes On Tue, 2011-11-29 at 14:58 -0800, Boaz Harrosh wrote: > On 11/29/2011 02:47 PM, Trond Myklebust wrote: > > On Tue, 2011-11-29 at 14:40 -0800, Boaz Harrosh wrote: > >> On 11/29/2011 01:57 PM, Trond Myklebust wrote: > >>>> Also Files when they will support segments and servers that request segments, > >>>> like the CEPH server, will very much enjoy the above, .i.e: Tell me the amount > >>>> you know you want to write. > >>> > >>> Why would we want to add segment support to the pNFS files client??? > >>> Segments are a nuisance that multiply the amount of unnecessary chitchat > >>> between the client and the MDS without providing any tangible > >>> benefits... > >>> > >> > >> Your kidding right? > >> > >> One: it is mandated by the Standard, This is not an option. So a perfectly > >> Standard complaint server is not Supported by Linux because we don't see > >> the point. > > > > Bollocks.. Nothing is "mandated by the Standard". If the server doesn't > > give us a full layout, then we fall back to write through MDS. Why dick > > around with crap that SLOWS YOU DOWN. > > > > NO! MAKE YOU FASTER. > > The kind of typologies I'm talking about a single layout get ever 1GB is > marginal to the gain I get in deploying 100 of DSs. I have thousands of > DSs I want to spread the load evenly. I'm limited by the size of the layout > (Device info in the case of files) So I'm limited by the number of DSs I can > have in a layout. For large files these few devices become an hot spot all > the while the rest of the cluster is idle. I call "bullshit" on that whole argument... You've done sod all so far to address the problem of a client managing layout segments for a '1000 DS' case. Are you expecting that all pNFS object servers out there are going to do that for you? How do I assume that a generic pNFS files server is going to do the same? As far as I know, the spec is completely moot on the whole subject. IOW: I'm not even remotely interested in your "everyday problems" if there are no "everyday solutions" that actually fit the generic can of spec worms that the pNFS layout segments open. > >> Two: There are already file-layout servers out there (multiple) which are > >> waiting for the Linux files-layout segment support, because the underline > >> FS requires Segments and now they do not work with the Linux client. These > >> are CEPH and GPFS and more. > > > > Then they will have a _long_ wait.... > > > > OK, so now I understand. Because when I was talking to Fred before BAT and during > It was very very peculiar to me why he is not already done with that simple stuff. > Because usually Fred is such a brilliant fast programmer that I admire, and that simple > crap? > > But now that explains Yes. It's all a big conspiracy, and we're deliberately holding Fred's genius back in order to disappoint you... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
