All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
	phillips@bonn-fries.net (Daniel Phillips)
Cc: acahalan@cs.uml.edu (Albert D. Cahalan),
	linux-kernel@vger.kernel.org, viro@math.psu.edu,
	phillips@bonn-fries.net, chaffee@cs.berkeley.edu,
	storner@image.dk, mnalis-umsdos@voyager.hr
Subject: Re: FAT32 superiority over ext2 :-)
Date: Mon, 25 Jun 2001 02:03:07 +0200	[thread overview]
Message-ID: <0106250203070J.00430@starship> (raw)
In-Reply-To: <200106242349.f5ONnhP34041@saturn.cs.uml.edu>
In-Reply-To: <200106242349.f5ONnhP34041@saturn.cs.uml.edu>

On Monday 25 June 2001 01:49, Albert D. Cahalan wrote:
> Daniel Phillips writes:
> > On Monday 25 June 2001 00:54, Albert D. Cahalan wrote:
> >> By dumb luck (?), FAT32 is compatible with the phase-tree algorithm
> >> as seen in Tux2. This means it offers full data integrity.
> >> Yep, it whips your typical journalling filesystem. Look at what
> >> we have in the superblock (boot sector):
> >>
> >>     __u32  fat32_length;  /* sectors/FAT */
> >>     __u16  flags;         /* bit 8: fat mirroring, low 4: active fat */
> >>     __u8   version[2];    /* major, minor filesystem version */
> >>     __u32  root_cluster;  /* first cluster in root directory */
> >>     __u16  info_sector;   /* filesystem info sector */
> >>
> >> All in one atomic write, one can...
> >>
> >> 1. change the active FAT
> >> 2. change the root directory
> >> 3. change the free space count
> >>
> >> That's enough to atomically move from one phase to the next.
> >> You create new directories in the free space, and make FAT
> >> changes to an inactive FAT copy. Then you write the superblock
> >> to atomically transition to the next phase.
> >
> > Yes, FAT is what inspired me to go develop the algorithm.  However, two
> > words: 'lost clusters'.  Now that may just be an implemenation detail ;-)
>
> What lost clusters?
>
> Set bit 8 of "flags" (A_BF_BPBExtFlags to Microsoft) to disable
> FAT mirroring. Then the low 4 bits are a 0-based value that
> indicates which copy of the FAT should be used.
>
> Assume we have 2 copies of the FAT, as is (was?) common. I'll call
> them X and Y. When we mount the filesystem, we disable FAT mirroring
> and mark FAT X active.
>
> Now we can make changes to FAT Y without affecting filesystem
> integrity. Windows will not use FAT Y. As is usual with the
> phase-tree algorithm, we use free space to create a new structure
> beside the old one.
>
> Time for a phase change:
>
> We have FAT Y, currently inactive, updated on disk.
> FAT X is active; it describes the current on-disk state.
> We have a new root directory on disk, sitting in free space.
> We have a new filesystem info sector on disk, sitting in free space.
>
> We write one single sector, then:
>
> FAT X becomes inactive, and will not be used by Windows.
> FAT Y becomes active; it describes the new on-disk state.
> The old root directory is marked free in FAT Y. Good!
> The old filesystem info sector is marked free in FAT Y. Good!
>
> Once the superblock goes to disk, FAT X may be written to.

When can we expect the patch?

--
Daniel

  reply	other threads:[~2001-06-25  0:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-24 22:54 FAT32 superiority over ext2 :-) Albert D. Cahalan
2001-06-24 23:22 ` Daniel Phillips
2001-06-24 23:49   ` Albert D. Cahalan
2001-06-25  0:03     ` Daniel Phillips [this message]
2001-06-25 15:04       ` Juri Haberland

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=0106250203070J.00430@starship \
    --to=phillips@bonn-fries.net \
    --cc=acahalan@cs.uml.edu \
    --cc=chaffee@cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mnalis-umsdos@voyager.hr \
    --cc=storner@image.dk \
    --cc=viro@math.psu.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 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.