[Top][All Lists]

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

Re: universal filesystem convertor

From: Andrew Clausen
Subject: Re: universal filesystem convertor
Date: Thu, 10 Jan 2002 14:17:14 +1100
User-agent: Mutt/1.2.5i

On Wed, Jan 09, 2002 at 11:45:13PM +0300, Serguei Tzukanov wrote:
> Andrew Clausen wrote:
> > Yep, nice idea :)  It will run into problems in low free space.
> > (free space must be > largest file, right).
> This can be solved by special copy, i.e. we get few last pages of the 
> file from primary fs, truncate the file and write these pages at the end 
> of destination file (if secondary fs does not support sparse files, we 
> can write in reversed order :-).

Yep :)

Not supporting sparse files would suck.  Perhaps it would be nice
to hack up support (in a non-standard way) for FAT and friends?
(What fs's don't support sparse files?)
> > Also, your convertfs can also be used as a resizer, right?
> Yes, you are right.
> We can even collect many loop devices into one LVM device, repartition 
> it another way than the real disk and create a totally different 
> physical layout.

Indeed :)

> > I guess it's all rather slow, but nice none-the-less :)
> > You might also be interested in Partition Surprise (google it!)
> It's slow mostly because of journaling.

I can imagine.

When doing copying, you should get all the benefits of caching...

OTOH, this is also a drawback, since you can't control how the
sparse file is allocated.  It might fail.  I guess lots of sync()s
are needed.

Anyway, I've been thinking lots how to do the reshuffle... not
that I've grokked your code yet.

Me-and-riel have designed a qsort-like algorithm to minimize seeks,
and to touch the journal n times, where n is:

        n = 2 * fs_size * log2 (fs_size) / log2 (min (free space, RAM/4))

I haven't done a formal analysis of the seeks, but intuitively, it
does the "scatter-gather" thing in an efficient way...

Anyway, probably a bad idea to attempt implementing this without
understanding/trying your code... but it's too fun!
(Implementing now!)

> Hmm... Partition Surprise will need special handling of reiserfs because 
> of its tail compression.

Well, it needs lots of work for each FS anyway.

> > Ralf B├Ąchle told me he thought there might be problems with using
> > loopback like this... I guess it's working ok?
> Loopback works fine for me on 2.4.17.
> Another thing is that implemented algorithm is somewhat buggy.
> This is still proof-of-concept version.
Fair enough :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]