On Thursday 21 August 2014 at 00:30:45, Edward Shishkin wrote: > > On 08/20/2014 10:34 PM, Ivan Shapovalov wrote: > > On Wednesday 20 August 2014 at 01:39:42, Edward Shishkin wrote: > >> On 08/20/2014 12:32 AM, Ivan Shapovalov wrote: > >>> From `git log` I've seen that VFS people intend to replace ->aio_read() and > >>> ->aio_write() of struct file_operations with new methods ->read_iter() and > >>> ->write_iter(). > >>> > >>> (Along with a couple of related new helpers, differing from previous just in > >>> calling _iter methods instead of aio_ ones.) > >>> > >>> From other filesystems it seems that these are simple drop-in replacements > >>> (however, well, I have zero familiarity with VFS). So here is a question: > >>> is there any intentional reason that generic_file_aio_write() is not used > >>> in reiser4? > >> > >> Currently reiser4 is a set of two filesystems which differ in methods > >> of handling regular files. For VFS we provide "dispatchers", which pass > >> management to appropriate plugin (UNIX_FILE or CRYPTCOMPRESS). > >> > >> UNIX_FILE plugin doesn't use generic write for performance reasons > >> (I'll try to find the respective mailing thread). CRYPTCOMPRESS doesn't > >> use it for compatibility reasons: I don't know how how to rewrite it > >> gracefully using the generic write method. > >> > >> Edward. > > > > Thanks for explanation! So, does this patch make any sense? > > > I haven't looked at this carefully yet, but likely it is correct. > > Thanks, > Edward. Turned out it isn't.. The iter_file_splice_write() requires ->write_iter to be set, or a NULL dereference happens. At first I've thought that we're out of luck and will need to use the fallback splice implementation (default_file_splice_write), but just setting ->write_iter to generic_file_write_iter strangely worked. (By "it works" I mean "splice finishes successfully and does not cause data corruptions"). Could you please comment on this? :) Thanks, -- Ivan Shapovalov / intelfx /
Attachment:
signature.asc
Description: This is a digitally signed message part.