Messages in this thread | | | Date | Wed, 23 Feb 2005 12:09:28 -0800 | From | Andrew Morton <> | Subject | Re: Help tracking down problem --- endless loop in __find_get_block_slow |
| |
zensonic@zensonic.dk (Thomas S. Iversen) wrote: > > > OK, so we're looking for the buffer_head for block 101 and the first > > buffer_head which is attached to the page represents block 100. So the > > next buffer_head _should_ represent block 101. Please print it out: > > Not quite the same, but simelar: > > Feb 23 14:50:24 localhost kernel: __find_get_block_slow() failed. block=102, > b_blocknr=128, next=129 > Feb 23 14:50:24 localhost kernel: b_state=0x00000013, b_size=2048 > Feb 23 14:50:24 localhost kernel: device blocksize: 2048 > Feb 23 14:50:24 localhost kernel: ------------[ cut here ]------------
Something has caused the page at offset 51 (block 102) to have buffer_heads for blocks 128 and 129 attached to it.
> > Could be UFS. But what does "transparent block encryption and sector > > shuffling" mean? How is the sector shuffling implemented? > > GDBE is a block level encrypter. It encrypts the actual sectors > transparently via the GEOM API (corresponds to the devicemapper api in linux). > > GBDE assigns a key for each block, thereby introducing keysectors. > Furthermore the sectors are remapped so that one can not guess where e.g. > metadata is located on the physical disk. It is a rather simple remap:
I'd be suspecting that the sector remapping is the cause of the problem. How is it implemented? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |