From: Andreas Dilger <adilger@clusterfs.com>
To: "daniel.poelzleithner" <poelzi@poelzi.org>
Cc: "Vladimir V. Saveliev" <vs@namesys.com>,
Matt Stegman <matts@ksu.edu>,
reiserfs-list@namesys.com
Subject: Re: reiser4 metas/bmap problem
Date: Thu, 29 Jul 2004 22:42:02 -0400 [thread overview]
Message-ID: <20040730024202.GO1439@schnapps.adilger.int> (raw)
In-Reply-To: <4109B2BC.4040600@poelzi.org>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
On Jul 30, 2004 04:30 +0200, daniel.poelzleithner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Vladimir V. Saveliev wrote:
> | reiser4 should do the same, i agree. However, reiser4 has another
> | feature we call relocation (flush may allocate another disk blocks for a
> | file if it finds it more optimal) which is undesirable for bmapped files.
> | We will probably have to invent some woraround for that.
>
> Whats about a flag that can be set through metas, that will prevent the
> relocation ? That would be no workaround, that would be a feature :)
Lilo knows to set "notail" on files that it is bmapping so that the tail
is unpacked into a real block that won't move. That attribute could be
re-used for this purpose and all would be well.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-07-30 2:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-28 23:26 reiser4 metas/bmap problem Matt Stegman
2004-07-29 1:25 ` Andreas Dilger
2004-07-29 7:41 ` Hans Reiser
2004-07-29 7:48 ` Vladimir V. Saveliev
2004-07-30 18:37 ` Hans Reiser
2004-07-30 19:26 ` Andreas Dilger
2004-07-31 11:43 ` Vladimir V. Saveliev
2004-07-31 17:08 ` Christophe Saout
2004-08-01 12:18 ` Vladimir V. Saveliev
2004-07-29 8:07 ` Vladimir V. Saveliev
2004-07-30 2:30 ` daniel.poelzleithner
2004-07-30 2:42 ` Andreas Dilger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040730024202.GO1439@schnapps.adilger.int \
--to=adilger@clusterfs.com \
--cc=matts@ksu.edu \
--cc=poelzi@poelzi.org \
--cc=reiserfs-list@namesys.com \
--cc=vs@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.