Re: btrfs csum failed on git .pack file
On Wed, Sep 9, 2009 at 11:01 PM, Oliver Mattos oliver.matto...@imperial.ac.uk wrote: What a strange coincidence that it affected git pack files in both cases. It's almost too improbable... I had similar problems with a broken git repository about two weeks ago. This was on a regular laptop harddrive that's never reported any errors. Unfortunately I rm'ed the repository and cloned it again so I can't check exactly what caused the corruption. Interestingly I've just discovered a broken tar.bz2 file that shows similar symptoms as what's been described here earlier. The first (and by far largest) chunk of the file consists entirely of 0x01 bytes followed by a smaller chunk that appears to be a PNG file and then arch/sparc/include/asm/fhc.h from the linux kernel. After this I have a small chunk of 0x00 bytes followed by arch/sparc/include/asm/floppy.h. This pattern is repeated several times with different include files from the kernel sources and the file ends with a small chunk of 0x01 bytes again. The harddisk in question is: === START OF INFORMATION SECTION === Model Family: Fujitsu MHV series Device Model: FUJITSU MHV2080BH Serial Number:NW05T6425FRY Firmware Version: 00840028 User Capacity:80,025,280,000 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 4a Local Time is:Thu Sep 10 12:40:10 2009 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled As already mentioned it's never reported any errors and I also haven't seen any problems like this before when using ext3 or ext4. The broken file is available at http://omploader.org/vMmJtbg if that's any help. Regards, Bryan Østergaard -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about back references
On Tue, Sep 08, 2009 at 05:40:07PM -0400, Peter Macko wrote: Thanks! I have a follow up question: Are back references reference counted? If so, this should mean that after the file system COWs an inode, it must increase the reference counts of its file extent back references. Do we know what is the overhead? In the case they are not reference counted, how does the system know when to drop the reference? The reference counts live in a tree that is maintained via cow but not reference counted. What are the bookend extents? Is the number of bookend requests in the fourth field of a file extent back reference the number of times the extent occurs within the file? bookends are how we do cow with large extents without needing to read in the entire large extent. Picture a large 128MB extent where you want to overwrite 4K in the middle. What we do is create two pointers to the original extent, and then make a new extent for the new 4K mod. Our pointers end up like this: [ old extent part 1 ] [ new 4k extent ] [ old extent part 2 ] A future mod will be to split and modify the old extent when we know there aren't any other reference holders on it. The bookend system assumes that a given extent is in use by multiple snapshots, where we aren't allowed to change the actual extent records because it is in use in other places. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG? a possible bug for the absence of memory barrier
On Thu, Sep 10, 2009 at 12:15:24AM +0900, 홍신 shin hong wrote: Hello. I am reporting possible bugs caused by the absence of memory barriers. Please examine this issue and let me know your opinion. In add_async_extent(), an async_extent object is allocated and initialized and then links to cow-extents. Memory barriers have an impact when there are multiple CPUs accessing the same data structures at the same time. In the case of add_async_extent only one worker thread is working on that list at a time. However, since there is no memory barrier between the initialization and the linking to the list, these two operations are executed opposite order. And the re-ordering might result race condition. The similar issue is also in join_transaction(). In join_transaction, that list is protected by the trans_mutex. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
slight simplification in transaction.c
Hi there,
While reading source, I found possible simplification
in btrfs_record_root_in_trans
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index cdbb502..7cd7bf9 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -123,12 +123,9 @@ int btrfs_record_root_in_trans(struct btrfs_trans_handle
*trans,
return 0;
mutex_lock(root-fs_info-trans_mutex);
- if (root-last_trans == trans-transid) {
- mutex_unlock(root-fs_info-trans_mutex);
- return 0;
- }
+ if (root-last_trans != trans-transid)
+ record_root_in_trans(trans, root);
- record_root_in_trans(trans, root);
mutex_unlock(root-fs_info-trans_mutex);
return 0;
}
--
Premysl Anydot Hruby, http://www.redrum.cz/
-
I'm a signature virus. Please add me to your signature and help me spread!
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
