Theodore Tso wrote:
On Wed, Jun 06, 2007 at 03:32:27PM +0530, Aneesh Kumar K.V wrote:
If we allow to change the block size in between that would mean the
records that we store in the tdb database will be of variable size (
different block sizes). That would also add all the code/complexity that
i have in is_trans_overlapping. So if we are looking at avoiding the
above for() loop then we should have constant block size (4K ?). But in
your above statement, you are counting overhead as a percentage of
blocksize. So how do we handle this ?
As I suggested in my previous mail message, the block size rarely
changes (mke2fs being the primary counter-example, and then only in a
fairly restricted case). So as far as the tdb is concerned, we have
to use a constant blocksize (the first one which is used when writing
to the i/o block). So the undo manager would save away the blocksize
the first time it was written to --- and yes, we would have to store
that information in the tdb file so the restore program knows what
block size is used, but that's easy; just write out the blocksize that
out as an ascii number (to avoid byte swapping issues) with the key
"blocksize" :-).
I don't think we need to store the blocksize because we can use the
data.dsize that is returned from tdb_fetch as the block size. For the
replay below is what i have right now.
for (key = tdb_firstkey(tdb); key.dptr; key = tdb_nextkey(tdb, key)) {
data = tdb_fetch(tdb, key);
blk_num = *(unsigned long *)key.dptr;
location = blk_num * data.dsize;
printf("Replayed transaction of size %d at location %ld\n", data.dsize,
blk_num);
lseek(fd, location, SEEK_SET);
write(fd, data.dptr, data.dsize);
}
What version of e2fsprogs are you developing against?
Right now i am manually linking it against libtdb.
dpkg --search /usr/lib/libtdb.so
tdb-dev: /usr/lib/libtdb.so
Any particular reason you're not using the development version from
Mercurial for your development? In general it's good practice to send
patches against the latest develoment tip. What caught my eye of that
particular comment was that it was pretty much saying that you weren't
doing that....
Nothing particular. In the beginning i have imported the extent based
patches into a git repository and i continued using the same. Once we
all agree with the approach followed by the code i will port the same to
the code found in mercurial.
-aneesh
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
