On Thu, May 07, 2020 at 10:50:40AM -0600, Jens Axboe wrote: > On 5/7/20 10:48 AM, Jeremy Allison wrote: > > On Thu, May 07, 2020 at 10:43:17AM -0600, Jens Axboe wrote: > >> > >> Just like for regular system calls, applications must be able to deal > >> with short IO. > > > > Thanks, that's a helpful definitive reply. Of course, the SMB3 > > protocol is designed to deal with short IO replies as well, and > > the Samba and linux kernel clients are well-enough written that > > they do so. MacOS and Windows however.. > > I'm honestly surprised that such broken clients exists! Even being > a somewhat old timer cynic... > > > Unfortunately they're the most popular clients on the planet, > > so we'll probably have to fix Samba to never return short IOs. > > That does sound like the best way forward, short IOs is possible > with regular system calls as well, but will definitely be a lot > more frequent with io_uring depending on the access patterns, > page cache, number of threads, and so on. OK, I just want to be *REALLY CLEAR* what you're telling me (I've already written the pread/pwrite wrappers for Samba that deal with short IO but want to ensure I understand fully before making any changes to Samba). You're saying that on a bog-standard ext4 disk file: ret = pread(fd, buf, count, offset); can return *less* than count bytes if there's no IO error and the file size is greater than offset+count and no one else is in the middle of a truncate etc. ? And: ret = pwrite(fd, buf, count, offset); can return less* than count bytes if there's no IO error and there's ample space on disk ? I have to say I've *never* seen that happen, and Samba is widely enough used that IO corruption from short reads/writes from MacOSX and Windows clients would have been widely reported by now. Look at how quickly someone spotted disk corruption because of the change in userspace-visible behavior of the io_uring interface. We only shipped that code 03 March 2020 and someone *already* found it. Jeremy.
