tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [GSoC 2013] Defragmentation for FFS

> I have not many technical toughs about the online version yet.
> Expect that some black magic has to be done, to redirect the I/O
> operations to the main memory, or other free parts on the hard disk.

Seems to me this should be just a question of updating in-core data as
well as on-disk data...but admittedly this is coming from someone who
hasn't tried doing even the offline version.  (Closest I've come is the
program that became resize_ffs.  Related but definitely different.)

> To my understanding, VFS has no support for things like that.  So
> this will be hard.

I'm not sure VFS will/should know anything about it.  Since
fragmentation is a filesystem-specific thing, it seems to me this
should all happen inside ffs; I wouldn't expect the VFS layer to know
anything about it.

> 1. Set the fs_clean to false.
> 2. copy data blocks
> 3. update metadata
> 4. flush to disk
> 5. Set fs_clean to true
> 6. continue with the next data move operation, i.e. goto 1.

Actually, I suspect you'd get better crash tolerance out of

fs_clean = false
for each data move operation {
        allocate new blocks
        flush allocation bitmaps
        copy data blocks
        flush copied block contents
        update metadata (inode, indirect blocks)
        flush changed metadata
        deallocate old blocks
        flush allocation bitmaps
fs_clean = true

As for fs_clean, I see little point in setting fs_clean to true after
each copy only to immediately set it false again in almost all cases.

As for the flushing, the idea is that a crash at any point 
will leave the filesystem in good enough shape for fsck to fix: some
metadata may point to old locations, some to new, but both copies are
the same; and every block that is allocated in either the old state or
the new is marked allocated - fsck can free up data blocks which are
marked allocated but not actually referenced just fine.

The above can probably be optimized somewhat - for example, I suspect
the last flush inside the loop can be dropped in many (all?) cases -
but something like it should be workable.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index