[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.xbyk6eur0ncgu9@vitalif.vhome>
Date: Fri, 28 Feb 2014 01:12:04 +0400
From: "Vitaliy Filippov" <vitalif@...rcmc.ru>
To: linux-ext4@...r.kernel.org, "Phillip Susi" <psusi@...ntu.com>
Subject: Re: A tool that allows changing inode table sizes
> Wow! That is quite a project, and this patch manager sounds very
> nice. Good work!
Thanks :)
Since that initial post I've also implemented a simple 'patchbd' kernel
module - http://svn.yourcmc.ru/viewvc.py/vitalif/trunk/sftl/patchbd.c
(don't look at sftl*, it's some old academic try to implement a software
FTL); it now has different format of patch files, so patch_io_manager is
also rewritten... It's still quite a hack of course: block maps for
example are logically stored twice - once explicitly and once in the
underlying FS extent tree... But it's working, opposed to an LVM snapshot
than made my system hang when being actively written; it's fast since
there are no additional kernel threads or work queues (except loop thread
of course), it just proxies bio's to other devices... and you can finally
mount and test a 'patched' block device... :)
Also I've done testing on a real harddrive (that 3TB one) and actually
fixed one bug after that testing :) also I've left the patch block device
mounted for a ~week, ... and the patch file had grown up to 20GB. Then
I've applied it with e2patch. Everything went OK. :)
What I'll do next is trying to actually port it into resize2fs...
--
With best regards,
Vitaliy Filippov
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists