linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).