From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 1/4] vfs: vfs-level fiemap interface Date: Wed, 8 Oct 2008 00:43:52 +0100 Message-ID: <20081007234351.GA20134@shareable.org> References: <1223071147-27180-1-git-send-email-tytso@mit.edu> <1223071147-27180-2-git-send-email-tytso@mit.edu> <20081004021251.GA29174@mit.edu> <48EA55AC.2060102@hp.com> <20081006210706.GB8139@mit.edu> <20081007101207.GA10406@infradead.org> <20081007130008.GA3503@shareable.org> <20081007134814.GA7311@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , jim owens , linux-fsdevel@vger.kernel.org, Mark Fasheh , Michael Kerrisk , linux-abi@vger.kernel.org To: Theodore Tso Return-path: Received: from mail2.shareable.org ([80.68.89.115]:56386 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758263AbYJGXn6 (ORCPT ); Tue, 7 Oct 2008 19:43:58 -0400 Content-Disposition: inline In-Reply-To: <20081007134814.GA7311@mit.edu> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Theodore Tso wrote: > > FIEMAP_EXTENT_READ_ENCODED > > FIEMAP_EXTENT_WRITE_ENCODED > > If some application which wishes to use FIEMAP really wants to know > whether it's safe to write to an extent while the fs is unmounted, we > can add that flag later --- but I'm not that sure we really want to go > there. I agree. If it were ever added, it would have the opposite sense to FIEMAP_EXTENT_ENCODED: set would mean "can write". Sounds messy and suggests the sense of FIEMAP_EXTENT_ENCODED should be reversed so that _set_ means safe to read - effectively "not safe unless filesystem explicitly says it is". But it's functionally adequate, not a real bike shed colour clash :-) > Do you have a use in mind for this interface where this would be > useful? Barely imaginable uses: boot loader, BIOS-stage device tester or similar logging to a preallocated file, or a userspace benchmark testing direct block device access to a preallocated file. It's not something I'm interested in, just that it's barely conceivable, and I only thought of it when Chris mentioned shared data blocks. So no. I just wanted to clarify, because on most filesystems you _can_ write to the data blocks safely, and that's an assumption that Joe Obscure Boot Loader Hacker (who isn't familiar with modern filesystems) might be tempted by. One more thing, then: How can you safely use !(flags & FLAG_EXTENT_ENCODED) anyway in userspace code which is filesystem-independent? What tells you that the data isn't moved after calling FIEMAP and before unmounting, by unrelated activity on the filesystem? So should filesystems also set FLAG_EXTENT_ENCODED if there is any chance the data will move without any explicit operation on that file, even though the data itself is stored unencoded in data blocks? -- Jamie