On 31 Mar 2016, at 18:05, Wouter Verhelst <[email protected]> wrote: >>>> Although I'm implementing a server at the moment where I'd like to >>>> do just that with lengths in excess of 2^31. > > Why?
Because golang represents lengths to 'read' as 'int' which is platform dependent 32 bit or 64 bit SIGNED integer depending on platform. Offsets are all 64 bit. I'm sure other platforms (admittedly not POSIX) may have signed size types. I know that in practice *lengths* > 2^31 are hardly ever used by any client, so I'd like to say "the maximum length you can send me is 2^31 - 1". This is better than putting in a special code path (with the possibility of introducing bugs, and which will be hard in practice to test without 2GB of memory to spare, and 2GB on disk, which is hard to put in unit tests) just to handle something that most clients won't want anyway, and which they are likely to have code to fragment themselves so they can do 64 bit length reads. That extra code path is just an opportunity for things to go wrong. >>> Oh, good point - particularly true if you are targeting 32-bit hardware >>> where ssize_t limits read() and write() to 2^31 bytes in a transaction >>> (and in that case, both CMD_READ and CMD_WRITE should consider this case). >>> >>> But what do we do about Wouter's request that we not permit EOVERFLOW >>> without structured replies being negotiated? Does that mean that >>> CMD_WRITE cannot reply with EOVERFLOW unless structured replies are >>> negotiated? >> >> I'm guessing EIO? > > No. > > Large-file support on 32 bit architectures has existed since several > decades now. We should not cater to that; people should just write > software that can handle LFS offsets. It's not offsets that are the issue, it's lengths. I'd also like to say "I'd like my offsets / lengths to be a multiple of 4k" so I can open O_DIRECT. Or at least say "can you cope with only offsets / lengths that are a multiple of 4k, as if so I can perform better". But this should probably be on a different wish-list! -- Alex Bligh ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
