From: Kyle Moffett <mrmacman_g4@mac.com>
To: Antonio Vargas <windenntw@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
John Richard Moser <nigelenki@comcast.net>,
linux-kernel@vger.kernel.org
Subject: Linux VFS architecture questions
Date: Mon, 23 Jan 2006 11:48:21 -0500 [thread overview]
Message-ID: <CEED5F58-EF3D-44D9-9C54-FE1720640E11@mac.com> (raw)
In-Reply-To: <69304d110601230552n4c7656cal9c6901e180e82504@mail.gmail.com>
On Jan 23, 2006, at 08:52:51, Antonio Vargas wrote:
> On 1/23/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
>> The way that I'm considering implementing this is by intentionally
>> fragmenting the allocation bitmap, catalog file, etc, such that
>> each 1/8 or so of the disk contains its own allocation bitmap
>> describing its contents, its own set of files or directories,
>> etc. The allocator would largely try to keep individual btree
>> fragments cohesive, such that one of the 1/8th divisions of the
>> disk would only have pertinent data for itself. The idea would be
>> that when trying to look up an allocation block, in the common
>> case you need only parse a much smaller subsection of the disk
>> structures.
>
> this sounds exactly the same as ext2/ext3 allocation groups :)
Great! I'm trying to learn about filesystem design and
implementation, which is why I started writing my own hfsplus
filesystem (otherwise I would have just used the in-kernel one). Do
you have any recommended reading (either online or otherwise) for
someone trying to understand the kernel's VFS and blockdev
interfaces? I _think_ I understand the basics of buffer_head,
super_block, and have some idea of how to use aops, but it's tough
going trying to find out what functions to call to manage cached disk
blocks, or under what conditions the various VFS functions are
called. I'm trying to write up a "Linux Disk-Based Filesystem
Developers Guide" based on what I learn, but it's remarkably sparse
so far.
One big question I have: HFS/HFS+ have an "extents overflow" btree
that contains extents beyond the first 3 (for HFS) or 8 (for HFS+).
I would like to speculatively cache parts of that btree when the
files are accessed, but not if memory is short, and I would like to
allow the filesystem to free up parts of the btree under the same
circumstances. I have a preliminary understanding of how to trigger
the filesystem to read various blocks of metadata (using
buffer_heads) or file data for programs (by returning a block number
from the appropriate aops function), but how do I allocate data
structures as "easily reclaimable" and indicate to the kernel that it
can ask me to reclaim that memory?
Thanks for the help!
Cheers,
Kyle Moffett
next prev parent reply other threads:[~2006-01-23 16:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-22 6:42 soft update vs journaling? John Richard Moser
2006-01-22 8:51 ` Jan Engelhardt
2006-01-22 18:40 ` John Richard Moser
2006-01-22 19:05 ` Adrian Bunk
2006-01-22 19:08 ` Arjan van de Ven
2006-01-22 19:25 ` Adrian Bunk
2006-01-24 2:33 ` Jörn Engel
2006-01-22 9:31 ` Theodore Ts'o
2006-01-22 18:54 ` John Richard Moser
2006-01-22 21:02 ` Theodore Ts'o
2006-01-22 22:44 ` Kyle Moffett
2006-01-23 7:24 ` Theodore Ts'o
2006-01-23 13:31 ` Mitchell Blank Jr
2006-01-23 13:33 ` Kyle Moffett
2006-01-23 13:52 ` Antonio Vargas
2006-01-23 16:48 ` Kyle Moffett [this message]
2006-01-23 17:00 ` Linux VFS architecture questions Pekka Enberg
2006-01-23 17:50 ` Kyle Moffett
2006-01-23 17:54 ` Randy.Dunlap
2006-01-23 20:48 ` soft update vs journaling? Folkert van Heusden
2006-01-23 1:02 ` John Richard Moser
2006-01-22 19:50 ` Diego Calleja
2006-01-22 20:39 ` Suleiman Souhlal
2006-01-22 20:50 ` Diego Calleja
2006-01-23 1:00 ` John Richard Moser
2006-01-23 1:09 ` Suleiman Souhlal
2006-01-23 2:09 ` John Richard Moser
2006-01-22 19:26 ` James Courtier-Dutton
2006-01-23 0:06 ` John Richard Moser
2006-01-23 5:32 ` Michael Loftis
2006-01-23 18:52 ` John Richard Moser
2006-01-23 19:32 ` Matthias Andree
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=CEED5F58-EF3D-44D9-9C54-FE1720640E11@mac.com \
--to=mrmacman_g4@mac.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nigelenki@comcast.net \
--cc=tytso@mit.edu \
--cc=windenntw@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).