4 Replies Latest reply on Sep 14, 2017 7:49 AM by 3538113

    I use the  patter=/pattern=/file/name I found it is not the same data that I wrote in the /file/name

    3538113

      I wrote the data like this :

       

      pattern=/root/vdbench50406/vdbench50406/file1

      sd=sd1,openflags=o_direct,lun=/dev/sddc,offset=0000,range=(0,10%)

       

       

      wd=wd1,sd=sd1,xfersize=8k,rdpct=0,seekpct=0

       

       

      rd=run1,wd=wd1,iorate=2000,elapsed=100,interval=10,warmup=10,threads=1

      ~

       

       

      when  wrote complete I will to read the hexdump the lock device /sddc contents ,but the content are not same as the file , who had ever got this issue or I miss some paramters ?

       

      thanks

        • 1. Re: I use the  patter=/pattern=/file/name I found it is not the same data that I wrote in the /file/name
          Henk Vandenbergh-Oracle

          Doing a random write workload does not guarantee that every block is written to, so that's why you may find the wrong data.

          The only way to make sure that every block is written is to do sequential writes using seekpct=eof

           

          If that still fails for you, please include a small hex print of both your pattern and your data.

           

          Note from the doc:

          Vdbench never accesses block zero on any raw volume. This has been done to make sure that it never overwrites a volume label and/or vtoc.

           

          When you print block0 you will NOT find your data pattern.

           

           

          Henk.

          • 2. Re: I use the  patter=/pattern=/file/name I found it is not the same data that I wrote in the /file/name
            3538113

            Henk, thanks for your answer ,

             

            in my script the seepct-0, which means the sequent ,right ?

            IN my new test I changed it to seepct =eof , also have the same issues,you can get the details in the below messages:

             

            The following are details I use :

             

            >>>>Script:

            pattern=/root/almost_0.dat
            sd=sd1,openflags=o_direct,lun=/dev/emcpowerbj,offset=0000

            wd=wd1,sd=sd1,xfersize=8k,rdpct=0,seekpct=eof

            rd=rd1,wd=wd1,iorate=2000,elapsed=100,interval=10,warmup=10,threads=1

             

            >>>Source pattern I use:

             

            hexdump -s 0 -n 81920 almost_0.dat

            0000000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0001ff0 9dea 6836 5f7e 0b42 0000 0000 0000 0000

            0002000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0003ff0 ae3c 6d2d ec7f 4db8 0000 0000 0000 0000

            0004000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0005ff0 b13f 6c01 3176 8f83 0000 0000 0000 0000

            0006000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0007ff0 7171 46c4 6c0e cb51 0000 0000 0000 0000

            0008000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0009ff0 3566 8001 eeb9 bdcc 0000 0000 0000 0000

            000a000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            000bff0 971d 6197 7e1d d34c 0000 0000 0000 0000

            000c000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            000dff0 5d61 399a 0530 b094 0000 0000 0000 0000

            000e000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            000fff0 44a8 86ab 9e24 7dee 0000 0000 0000 0000

             

            >>>Read from the Block LUN after Write

            # hexdump -s 0 -n 81920 /dev/emcpowerbj

            0000000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0003ff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            0004000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0005ff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            0006000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0007ff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            0008000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0009ff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            000a000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            000bff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            000c000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            000dff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            000e000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            000fff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            0010000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0011ff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            0012000 0000 0000 0000 0000 0000 0000 0000 0000

            *

            0013ff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

            0014000

             

             

            Thanks

            • 3. Re: I use the  patter=/pattern=/file/name I found it is not the same data that I wrote in the /file/name
              Henk Vandenbergh-Oracle

              Vdbench every 8k writes the same data pattern, with one possible glitch: there are some byte reversal issues going on. Just look at the start of your data pattern, and the contents found every 8k:

              0001ff0 9dea 6836 5f7e 0b42 0000 0000 0000 0000   0003ff0 3668 ea9d 420b 7e5f 0000 0000 0000 0000

               

              You'll see that the bytes are in reverse order. This may be caused by the fact that vdbench treats every 32-bits in its data buffers as a 32bit integer.

              You may have to do an extra amount of reversal in your data pattern file.

               

               

              Henk.

              • 4. Re: I use the  patter=/pattern=/file/name I found it is not the same data that I wrote in the /file/name
                3538113

                Henk,

                thanks .

                The high bit and low bit is reverse , Except this , I found ,for the data that wrote to the LUN just choose the first two 8ks data from pattern file  . why it did not choose 8k, 8k ...8k like this ,just choose the first two 8ks data ?

                 

                 

                you can refer to the data I  wrote in the last reply .

                 

                 

                thanks