[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 :)
Andrew