From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Jambor Subject: Lilo requirements (Was: Re: Address space operations questions) Date: Sun, 17 Apr 2005 22:21:04 +0200 Message-ID: <8e70aacf0504171321331e44b9@mail.gmail.com> References: <8e70aacf05032616151c958eed@mail.gmail.com> <8e70aacf05032914306a827923@mail.gmail.com> <16970.44996.53630.886769@gargle.gargle.HOWL> <8e70aacf05040616527000e864@mail.gmail.com> <16980.60937.831029.982747@gargle.gargle.HOWL> Reply-To: Martin Jambor Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from zproxy.gmail.com ([64.233.162.202]:59020 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S261512AbVDQUVF convert rfc822-to-8bit (ORCPT ); Sun, 17 Apr 2005 16:21:05 -0400 Received: by zproxy.gmail.com with SMTP id 18so2002845nzp for ; Sun, 17 Apr 2005 13:21:04 -0700 (PDT) To: Nikita Danilov In-Reply-To: <16980.60937.831029.982747@gargle.gargle.HOWL> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Thanks for your reply, I found the the following thing interesting on its own: On 4/7/05, Nikita Danilov wrote: > Consider tools like LILO that want stable block numbers for certain > files. In reiserfs (both v3 and v4) there is an ioctl that disables > relocation for a given file. Besides, I do not think ->bmap() is useless > even when block numbers are volatile, for one thing it allows user level > to track how file is laid out (for example, to measure fragmentation). I tried to google out what behaviour lilo requires filesystems to exhibit without much success... is that information available somnewhere I din't look? Is that simple enought to be explained here? TIA Martin