From: "Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>
To: Hans Reiser <reiser@namesys.com>
Cc: reiserfs-list@namesys.com
Subject: Re: Agressive selective pre-allocation
Date: Sat, 14 Dec 2002 03:06:52 +0100 [thread overview]
Message-ID: <20021214030652.H2727@vestdata.no> (raw)
In-Reply-To: <3DF5F679.1000700@namesys.com>; from reiser@namesys.com on Tue, Dec 10, 2002 at 05:13:13PM +0300
On Tue, Dec 10, 2002 at 05:13:13PM +0300, Hans Reiser wrote:
> >An alternative would be the possibility to tell the fs about the
> >properties of the files. Maybe an ioctl to notify the fs that for this
> >particular file the fs should allocate X blocks at the time? That would
> >ensure that the files only get limited fragmentation and performance
> >stays optimal.
>
> Veritas did this, and then their architect regretted that nobody
> actually used that code and advised me not to do it. You may have an
> advantage with open source though in that you can modify the important
> user space programs to use it.
I was more thinking along the lines of:
find /var/log -type f | xargs ioctl REISERFS_SLOW_GROWING
But I guess syslog or whatever is used would have to be modified
for it to happen automaticly on new files. My guess is that
syslog-maintainers would not take patches for features like this unless
it was done in a more generic way that could potentially be used by
other filesystems as well.
> We have some block preallocation code in V3 for files that are kept open
> while being written to. You can look at that code if you want. You can
> also write a plugin for v4 that does what you want.
Are you talking about the allocate on flush code? I'll check that out;
allthough at this point it is of course more interesting to write code
for reiserfs4 than v3 - in particular if the new improved infrastructure
makes it easier.
> While I will not take someone off another task to work on this, I will
> be open to patches from others.
As I wrote in my original mail I don't have time to really work on this
now, but maybe later.
--
Ragnar Kjørstad
next prev parent reply other threads:[~2002-12-14 2:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-10 6:46 Agressive selective pre-allocation Ragnar Kjørstad
2002-12-10 7:26 ` Russell Coker
2002-12-10 7:58 ` Ragnar Kjørstad
2002-12-10 11:12 ` Stefan Fleiter
2002-12-12 8:47 ` Ragnar Kjørstad
2002-12-12 14:46 ` Hans Reiser
2002-12-14 1:56 ` Ragnar Kjørstad
2002-12-10 14:13 ` Hans Reiser
2002-12-14 2:06 ` Ragnar Kjørstad [this message]
2002-12-10 16:43 ` Bruce A. Mallett
2002-12-10 17:17 ` Anders Widman
2002-12-14 2:09 ` Ragnar Kjørstad
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=20021214030652.H2727@vestdata.no \
--to=reiserfs@ragnark.vestdata.no \
--cc=reiser@namesys.com \
--cc=reiserfs-list@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.