From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: Usefulness of SEEK_HOLE / SEEK_DATA in generic_file_llseek() Date: Tue, 31 Dec 2013 01:00:51 -0500 Message-ID: <20131231060051.GA17519@thunk.org> References: <20131223231253.GA8376@quack.suse.cz> <52B8D68A.9050902@fb.com> <20131230211831.GE5457@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josef Bacik , linux-fsdevel@vger.kernel.org To: Jan Kara Return-path: Received: from imap.thunk.org ([74.207.234.97]:44647 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811Ab3LaGA6 (ORCPT ); Tue, 31 Dec 2013 01:00:58 -0500 Content-Disposition: inline In-Reply-To: <20131230211831.GE5457@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Dec 30, 2013 at 10:18:31PM +0100, Jan Kara wrote: > > IIRC with the generic implementation we treat everything <= i_size > > as data and i_size as the first hole. The way the spec works is > > that if we are currently at data and do seek_data then we just > > return our current offset, same for a hole. In order to not be a > > jackass and have -EOPNOTSUPP for anybody who didn't implement > > seek_hole/seek_data I just did it this way where the only hole is > > the one that starts at i_size, so seek_data before that is going to > > return the value. > > Correct. My point is that I actually don't see anything 'jackass' in > returning -EOPNOTSUPP. In fact, one useful reason in returning -EOPNOTSUPP is so the userspace program can tell whether or not SEEK_HOLE/SEEK_DATA is really implemented by the low-level file system. If the userspace program knows that it's not available, it might want to fall back to some alternate mechanism, such as scanning the contents of the file blocks which are all zeros. (If the program knows that SEEK_HOLE/SEEK_DATA is really there, it might to avoid the CPU overhead of scanning the data buffers as it does the copy.) - Ted