linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: John Richard Moser <nigelenki@comcast.net>, linux-kernel@vger.kernel.org
Subject: Re: soft update vs journaling?
Date: Sun, 22 Jan 2006 17:44:08 -0500	[thread overview]
Message-ID: <4D75B95E-2595-4B60-91B3-28AD469C3D39@mac.com> (raw)
In-Reply-To: <20060122210238.GA28980@thunk.org>

On Jan 22, 2006, at 16:02, Theodore Ts'o wrote:
>> Online resizing is ever safe?  I mean, with on-disk filesystem  
>> layout support I could somewhat believe it for growing; for  
>> shrinking you'd need a way to move files around without damaging  
>> them (possible).  I guess it would be.
>>
>> So how does this work?  Move files -> alter file system superblocks?
>
> The online resizing support in ext3 only grows the filesystems; it  
> doesn't shrink it.  What is currently supported in 2.6 requires you  
> to reserve space in advance.  There is also a slight modification  
> to the ext2/3 filesystem format which is only supported by Linux  
> 2.6 which allows you to grow the filesystem without needing to move  
> filesystem data structures around; the kernel patches for  
> actualling doing this new style of online resizing aren't yet in  
> mainline yet, although they have been posted to ext2-devel for  
> evaluation.

 From my understanding of HFS+/HFSX, this is actually one of the  
nicer bits of that filesystem architecture.  It stores the data- 
structures on-disk using extents in such a way that you probably  
could hot-resize the disk without significant RAM overhead (both grow  
and shrink) as long as there's enough free space.  Essentially, every  
block on the disk is represented by an allocation block, and all data  
structures refer to allocation block offsets.  The allocation file  
bitmap itself is comprised of allocation blocks and mapped by a set  
of extent descriptors.  The result is that it is possible to fragment  
the allocation file, catalog file, and any other on-disk structures  
(with the sole exception of the 1K boot block and the 512-byte volume  
headers at the very start and end of the volume).

At the moment I'm educating myself on the operation of MFS/HFS/HFS+/ 
HFSX and the linux kernel VFS by writing a completely new combined  
hfsx driver, which I eventually plan to add online-resizing support  
and a variety of other features to.

One question though: Does anyone have any good recent references to  
"How to write a blockdev-based Linux Filesystem" docs?  I've searched  
the various crufty corners of the web, Documentation/, etc, and found  
enough to get started, but (for example), I had a hard time  
determining from the various sources what a struct file_system_type  
was supposed to have in it, and what the available default  
address_space/superblock ops are.

Cheers,
Kyle Moffett

--
They _will_ find opposing experts to say it isn't, if you push hard  
enough the wrong way.  Idiots with a PhD aren't hard to buy.
   -- Rob Landley




  reply	other threads:[~2006-01-22 22:44 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 [this message]
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               ` Linux VFS architecture questions Kyle Moffett
2006-01-23 17:00                 ` 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=4D75B95E-2595-4B60-91B3-28AD469C3D39@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nigelenki@comcast.net \
    --cc=tytso@mit.edu \
    /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).