From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Usefulness of SEEK_HOLE / SEEK_DATA in generic_file_llseek() Date: Tue, 24 Dec 2013 00:12:53 +0100 Message-ID: <20131223231253.GA8376@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Josef Bacik To: linux-fsdevel@vger.kernel.org Return-path: Received: from cantor2.suse.de ([195.135.220.15]:35214 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752344Ab3LWXM4 (ORCPT ); Mon, 23 Dec 2013 18:12:56 -0500 Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, so I've now hit a xfstests failure for UDF which is caused by the implementation of SEEK_HOLE / SEEK_DATA in generic_file_llseek(). UDF uses that function as its .llseek method but it supports holes as any other unix filesystem (e.g. ext2). The test in xfstests assumes that when it creates a file by pwrite(fd, buf, bufsz, off), then SEEK_DATA on offset 0 should return 'off' (off is reasonably rounded) but that's not true for the implementation in generic_file_llseek(). Now I'm not so much interested in that test itself - that can be tweaked to detect that case. But I rather wanted to ask - how useful is it to implement SEEK_HOLE / SEEK_DATA the way it is in generic_file_llseek()? Because it seems to me that any serious user will have to detect whether SEEK_HOLE / SEEK_DATA works reasonably and if not, fall back to some heuristic anyway. So why bother inventing bogus values in generic_file_llseek and thus making detection of working implementation harder? Honza -- Jan Kara SUSE Labs, CR