linux-ext4 - Re: [RFC PATCH 1/1] e2fsprogs: Add undo I/O manager.

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <4667EEC6.8040001@linux.vnet.ibm.com>
Date:	Thu, 07 Jun 2007 17:10:54 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Theodore Tso <tytso@....edu>
CC:	linux-ext4@...r.kernel.org
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, 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html