[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Visible /.journal

On Dec 31, 2001  12:00 -0500, Theodore Tso wrote:
> On Thu, Dec 27, 2001 at 11:57:03PM -0700, Andreas Dilger wrote:
> > Hmm, what would be involved for the kernel code?  If we caught it between
> > journal recovery, but before the journal was busy, it would be a matter of:
> > 1) read the ext2_inode data into memory from current journal inode number
> > 2) write the ext2_inode data into reserved inode #8, sync write
> > 3) change the journal inode number in the superblock, sync write
> > 4) set dtime for the old journal inode, clear immutable attribute, clear
> >    bit in inode bitmap
> > 5) take a guess that .journal is in the root directory and remove it, or
> >    mark the fs dirty for e2fsck to clean up on the next reboot if we can't
> >    find it there (it should just disappear if the inode is empty and it is
> >    marked unused in the inode bitmap and has a dtime).
> > 
> > This should be pretty safe if the ordering is done correctly.
> You *really* don't want to leave the filesystem in an inconsistent
> state at step (5), since the inode that was formally .journal could
> get reallocated, and then if the user tries to delete .journal, blocks
> that are in use would get marked as freed, at which point they could
> be double-allocated.....   Bad, bad, bad, ju-ju.   
> So you need to search for an entry with the same inode number as the
> journal inode as reported in the superblock entry first, and if you
> can't find it, abort the whole process of trying to move the journal
> then and there.

Yes, I see what you are getting at now.  I think in the end that filesystems
which have journals called anything but .journal or journal.dat will be
vanishingly small, and filesystems which don't have the journal inode in
the filesystem root will be that much smaller.

> Still, it's not *that* much work, but it is extra stuff in the clutter.

Well, if we wanted to avoid this, we could put the "journal relocator"
into a separately loaded module.  Since the number of cases where it will
be used is vanishingly small, it should not be a core part of the kernel.

Likewise, I was considering splitting my online resizing code into a
separate module, because the amount of time that it is actually in use
is very small.

Do you consider having these functions as separate modules an issue?  In
the end, nothing will break if there is a problem loading the module.

Cheers, Andreas
Andreas Dilger

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]