From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Thu, 3 Jul 2008 16:17:32 +0100 Message-ID: <20080703151731.GD1390@shareable.org> References: <20080625221835.GQ28100@wotan.suse.de> <486CE430.9010902@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, mfasheh@suse.com To: jim owens Return-path: Received: from mail2.shareable.org ([80.68.89.115]:35474 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751782AbYGCPRe (ORCPT ); Thu, 3 Jul 2008 11:17:34 -0400 Content-Disposition: inline In-Reply-To: <486CE430.9010902@hp.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: jim owens wrote: > FIEMAP_EXTENT_NO_BYPASS > > As in "you can't bypass the filesystem" to directly access it. Can we also commit to this, when FIEMAP_EXTENT_NO_BYPASS is *not* set: 1. The data at fe_physical, and *will not move* so long as nothing modifies *that particular file*? 2. Both reading *and writing* the file bypassing the filesystem are ok. The reason for 1 is that some filesystems may move data when _other_ files are modified. Heck, they may do so when other files are simply read, or at some random whim. Those filesystems would set FIEMAP_EXTENT_NO_BYPASS (except for files with chattr 't'), because fe_physical does not correspond to a *stable* location which a program can subsequently use. The reason for 2 is that some filesystems checksum the data and/or replicate it, and won't be readable if you write to it directly. In both these cases, O_DIRECT may *sometimes* work even though directly accessing the physical device is unreliable. So FIEMAP_EXTENT_NO_BYPASS may be treated as "access the file through the filesystem, use O_DIRECT if you still want direct access, and fall back to ordinary file access if that doesn't work". -- Jamie