On 11/29/06, seth vidal <skvidal@xxxxxxxxxxxxxx> wrote:
On Wed, 2006-11-29 at 15:58 -0500, Michael Jennings wrote: > On Wednesday, 29 November 2006, at 15:48:17 (-0500), > Tony Nelson wrote: > > > It disapoints me that you think it is not RPM's responsibility to > > protect its database. > > It is RPM's responsibility to provide database backups as much as it > is the kernel's responsibility to back up your ext2 filesystems. > However, if it were possible to corrupt the ext2 filesystem by performing frequent reads and writes we would consider that a bug in ext2, not in the program making the writes.
OK, lets carry your ext2 example to its end-point. Let's say you identify the physical block in a file, verfify that indeed the block has exactly the content yopu expect by reading the physical device, and you save that pyhsical block number somewhere for later use. <time passes, file is changed/copied> Now you take your physical block no and go read the data (again) from the physical device. Why are you surprised that the contents at the phsical blkno location have changed? The change is certainly not due to ext2 corruption. That is essentially what yum is doing, taking a join key (aka header instance) out of an iterator locking context by opening and closing a Berkeley DB environment repeatedly, i.e. releasing locks. With concurrent access (and no persistent locking), other rpmdb accesses can/will open the rpmdb, thereby changing the contents. I will attempt a reproducer for the yum problem shortly. Should not be very hard. FWIW, there's another kernel problem I saw last night with mmap randomization (which is used by Berkeley DB) in the FC6 kernel that I should be able to identify a reproducer for shortly. 73 de Jeff _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
