On Thu, 17 Oct 2019 at 13:49, smitha sunder <sundersmitha@xxxxxxxxx> wrote: > > Hi Robert, > > Since I want to use blocksize_unaligned=1 , I had to get rid of direct=1 : > > Per man page : > blocksize_unaligned, bs_unaligned > If set, any size in blocksize_range may be used. This typically won't > work with direct I/O, as that normally requires sector alignment. > > # fio --name=job1 --filename=/dev/nvme0n1 --rw=randwrite > --ioengine=libaio --number_ios=1 --debug=io --bs_unaligned=1 > --bs=1029 --direct=1 > fio: set debug option io > fio: bs_unaligned may not work with raw io > On Wed, Oct 16, 2019 at 8:12 AM Elliott, Robert (Servers) > <elliott@xxxxxxx> wrote: > > > > > -----Original Message----- > > > From: fio-owner@xxxxxxxxxxxxxxx [mailto:fio-owner@xxxxxxxxxxxxxxx] On Behalf Of smitha sunder > > > Sent: Tuesday, October 15, 2019 4:37 PM > > > To: fio <fio@xxxxxxxxxxxxxxx> > > > Subject: unaligned IO and starting LBA > > > > > > Hello, > > > > > > I have a 512 byte formatted nvme drive and I want to send an unaligned > > > IO and here’s the fio command line I am using , fio version fio-3.7 > > > > > > # fio --name=job1 --filename=/dev/nvme0n1 --rw=randwrite > > > --ioengine=libaio --number_ios=1 --debug=io --bs_unaligned=1 > > > --bs=1029 A blocksize of 1029 is neither a multiple of 4096 nor 512! You simply can't send I/O that is not aligned (and is not a multiple) of the device's logical block size down to a device so something will have to "fix" things for you. > > > Shouldn’t I see D7BD7CE as the starting LBA for the write based on the > > > above offset (0x1af7af9cec) ? > > > > Without direct=1 you're exercising the OS page cache logic, > > not directly accessing the drive. Robert's right - when you have buffering going on the linux kernel will quietly do a read-modify-write (two reads assuming it didn't already have those blocks in memory, a modify, then two writes) because you straddled a block. -- Sitsofe | http://sucs.org/~sits/
