linux-ext4 - Re: [PATCH 1/4] 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46B2B3E7.3030807@linux.vnet.ibm.com>
Date:	Fri, 03 Aug 2007 10:19:43 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Andreas Dilger <adilger@...sterfs.com>
CC:	tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/4] e2fsprogs: Add undo I/O manager



Andreas Dilger wrote:
> On Aug 03, 2007  00:02 +0530, Aneesh Kumar K.V wrote:
>> Andreas Dilger wrote:
>>> Is this the mtime and UUID of the new filesystem or the old one?  It
>>> should be the UUID and mtime of the new filesystem, so that the
>>> undo file can be verified against the current superblock.  This poses
>>> a bit of a problem, because that information isn't saved until after
>>> the mke2fs run is finished.
>>>
>>> One possibility is to overwrite this information at the end of mke2fs
>>> after the new UUID and mtime are written?
>> This can be done by writing the file system identity during the the 
>> io_channel_close.
>> How about this patch on top of the last series. I will merge this into the 
>> patcheset
> 
> I thought about this also, but in fact for most uses of the undo manager
> we want to save the information at the start instead of the end, so it
> is possible to undo e.g. a partial e2fsck that crashes before it finishes.
> Only with mke2fs (and, I guess tune2fs -U) does the UUID change at the
> end.

I am not sure whether saving the information at start is needed. I understand
that what we are looking for is the case when the application crashes without
doing a io_channel_close. In that case i would say the user can use the
--force option and replay the data from the tdb file. The UUID could very well
be changed on the disk before the application crashed. So even if we save
UUID at the start, there are cases where it won't match with the disk UUID.


That actually brings me to another change. I would be moving the block size
recording changes from write_file_system_identity to a separate function 
and will be calling it at the first write. That make sure we have a record
that carry the blocksize even though we don't have one with mtime and UUID
in the tdb file.


> 
> Also, can you check if mke2fs does any non-iomanager output?  I think
> there is code to "zap" the old superblock at the start and old RAID info
> at the end of the block device, and I'm not sure if this uses the normal
> IO manager or not.
> 


The zap_sector and zap_zero uses the io manager to zero out the blocks. So
they should be ok. I found that when we use -J device=<journal-device>. mke2fs
uses unix I/O manager to write to the journal super block. I guess that is ok
because we are not tracking changes to journal device.

I found that the journal_super_block have only space for 48 s_users
UUID entries. But in ext2fs_add_journal_device we are not checking
the limit. Does that mean repeated mke2fs with -J can lead to corruption ?

-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