[Stgt-devel] stgt and large devices?

[Ming Zhang]

On Wed, 2007-05-16 at 12:15 +0200, Tomasz Chmielewski wrote:
> Bastian Blank schrieb:
> > On Tue, May 15, 2007 at 04:35:11PM +0200, Tomasz Chmielewski wrote:
> >> when I browse through the beginning of a disk, I can see some familiar 
> >> content, but it is nevertheless different.
> > 
> > Are you able to describe the differences?
> 
> Well, it's hard to describe the difference in binary data.
> 
> First, I did a "dd" of a first 10 MB of the disk or so, for IET and 
> tgtd, compared md5sums - different.
> 
> Which shouldn't happen, as I didn't even mount the disks.
> 
> 
> Then, I opened the files I created with dd in an editor - totally 
> different, not just a couple of bytes here and there.
> 
> 
> So let's make an experiment: create a 10 MB file out of /etc/services 
> (basically, "cat" it several times after each other, until the text 
> document has 10 MB).
> 
> Then, do (part - disk available via iSCSI):
> 
> IET:
> 
> # dd if=/services-big of=part
> # dd if=part of=/part.iet bs=1k count=10000
> 
> When inspected with hexedit, we see text/services file.
> 
> 
> tgtd:
> 
> # dd if=part of=/part.tgtd bs=1k count=10000
> 
> When inspected with hexedit, file is different.
> 
> 
> # diff -u part.iet part.tgtd > part.diff
> 
> It resulted in a 600 kB diff file.
> 
> 
> 
> Whereas part.iet begins as /etc/services file, part.tgtd doesn't - it 
> starts like that:
> 
> rror interpretation service
> afs3-errors     7006/udp                        # error interpretation 
> service
> afs3-bos        7007/tcp                        # basic overseer process
> 
> 
> It begins 1630 lines later.
> 
> # dd if=part of=/part.tgtd2 bs=1k count=10000
> # dd if=part of=/part.tgtd3 bs=1k count=10000
> 
> # md5sum /part.*
> bf38437967c33219c1852d0000b3e593  /part.tgtd2
> c4a9207d7fb97f645b4b30142874d3fd  /part.tgtd3
> 
> # diff -u /part.tgtd2 /part.tgtd3 > /part-gt.diff
> 
> # ls -l /part-gt.diff
> -rw-r--r-- 1 root root 218099 May 16 12:11 /part-gt.diff
> 
> 
> Generally, the data seems *almost* intact, but the order is incorrect etc.

i will write a small code to write some pattern into the disk, for
example, 1st 1MB all 'a', 2nd all 'b',...

write on both and do hexedit and u can see the difference easier.



> 
> 
> So I have two observations:
> 
> - it doesn't happen on x86
> - it happens on ARM
> - it doesn't depend on size of the device as I though at the beginning
> 
>