From: Oliver Mattos <oliver.mattos08@imperial.ac.uk>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Partial Allocation
Date: Wed, 3 Dec 2008 00:32:56 +0000 [thread overview]
Message-ID: <1228264376.17414.4.camel@mattos-laptop> (raw)
Hi,
I presume that in the design of BTRFS, like most other filesystems, a
block on the underlying storage is either allocated (ie. to store
metadata or file data), or deallocated (possibly blank or containing
garbage left over, but the contents are irrelivant).
Does BTRFS have any system that could allow adding at a later point in
time a feature which would allow "weak" allocation of blocks, by which I
mean the block is allocated (ie. storing useful data), but if another
file needs to be written which has a higher priority and there are not
many free blocks left, then the data could be replaced.
I could forsee uses for features like that as a cache - for example my
web browsing cache is not vital data, and as such doesn't need to use up
disk space, but it might as well use up any disk space that would
otherwise go unused. The cache data can always be regenerated, so
loosing the data isn't a problem.
Other uses of the feature could be for persistant network caches (ie. to
store copies of remote files on the network can they can be accessed
faster locally), but again the cache data isn't critical to the
operation of the system, so could be stored in "weakly allocated"
blocks. Further uses could be caches of compressed files (decompressed
versions of the same files are also saved in other blocks, and depending
on IO and CPU load either the compressed or decompressed version is
used).
>From a user-land perspective, these files could be created with a
special flag which specifies they are only "weakly allocated", which
means any time the file has no open file descriptors it could "vanish"
if the underlying filesystem wants to use the space it occupies for
something else. A file could have a "priority" value which specifies
how important it is, and therefore how likely it is to be erased if a
new block needs to be allocated. The block allocator would use this
information, together with the physical layout of the data to decide
where to place new data to avoid fragmentation while retaining possibly
useful data for future use.
Let me know your ideas on this - at the moment it's only an idea, but
I'm interested to know if a) it would be possible to implement it into a
complex filesystem like btrfs, and b) if it would prove useful if
implemented.
Thanks
Oliver.
PS. I realise this could be implemented with a user space daemon which
polls available disk space and deletes caches when disk space gets low
(as windows does with shadow copies), but that hardly seems ideal, since
it can't intelligently choose which caches to delete to reduce
fragmentation, and large sudden disk allocations will fail.
next reply other threads:[~2008-12-03 0:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-03 0:32 Oliver Mattos [this message]
2008-12-03 1:18 ` Partial Allocation Chris Mason
2008-12-04 12:15 ` Josef Bacik
[not found] <1228162019.5274.36.camel@mattos-laptop>
2008-12-01 23:49 ` Partial allocation Oliver Mattos
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=1228264376.17414.4.camel@mattos-laptop \
--to=oliver.mattos08@imperial.ac.uk \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox