lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 07 Jun 2007 17:10:54 +0530
From:	"Aneesh Kumar K.V" <>
To:	Theodore Tso <>
Subject: Re: [RFC PATCH 1/1] e2fsprogs: Add undo I/O manager.

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, 
                 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/
>> tdb-dev: /usr/lib/
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists