xfs
[Top] [All Lists]

Re: Locking bmap mappings

To: Steve Lord <lord@xxxxxxx>
Subject: Re: Locking bmap mappings
From: "Andi Kleen" <ak@xxxxxxx>
Date: Tue, 29 Aug 2000 17:24:40 +0200
Cc: "Andi Kleen" <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <200008291441.JAA31979@xxxxxxxxxxxxxxxxxxxx>; from lord@xxxxxxx on Tue, Aug 29, 2000 at 09:41:18AM -0500
References: <ak@xxxxxxx> <200008291441.JAA31979@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Tue, Aug 29, 2000 at 09:41:18AM -0500, Steve Lord wrote:
> > On Mon, Aug 28, 2000 at 04:23:32PM -0500, Steve Lord wrote:
> > > 
> > > > 
> > > > Sorry, I should have been more clear. The locking is required for 
> > > > externa
> l
> > > > users, e.g. the loop device (the current version doesn't do it, but it 
> > > > wi
> ll
> > > > be fixed to do so). loop device cannot access any internal XFS locks. 
> > > > 
> > > > 
> > > > -Andi
> > > 
> > > OK, that's a different kettle of fish....
> > 
> > It would be nice if you could commit (or whatever ptools calls that) it. 
> > 
> > Thanks,
> > 
> > -Andi
> 
> 
> Actually, things are somewhat more broken that this, XFS does not provide
> prepare_write or commit_write address space operations, so I presume this
> means under loopback we would be at best a readonly device. At worst
> totally non-functional.

That's currently the case yes. The plan however is to turn loopback into
a block remapper similar to LVM. It would do direct IO on bmap'ed mappings then
(with some special hacks to fill holes -- loopback never extents files) 
The first step for that is a usable bmap interface for direct IO, which requires
a generic way to pin bmap mappings.


-Andi

<Prev in Thread] Current Thread [Next in Thread>