Windows prevents you from overwriting a block if it contains a mounted volume.
Bruce Sent from my iPhone On Apr 15, 2014, at 10:47 PM, "Elliott, Robert (Server Storage)" <[email protected]> wrote: >>> On 2014-04-15 17:04, Xiaofei Du wrote: >>> [global] >>> bs=4k >>> size=100m >>> direct=1 >>> filename=100mfile > > A few more tips: > - I don't see ioengine=libaio or iodepth=nn in that excerpt. > - use iostat -mxyz 2 while the test is running to see the IO sizes that the > block layer is sending to the LLD, how many block layer merges are occurring, > the IO depth being maintained to the LLD, and the IOPS rate. > - set /sys/block/<drive name>/queue/nomerges to 2 to disable block > layer/scheduler merging. > - your LLD or controller might have its own cache and/or do sequential > merging (coalescing) too. What controller are you using? > - by using a file, you don't know whether it's on the inner tracks or outer > tracks or somewhere in between. > - by using a file, you don't know whether it's fragmented, making sequential > transfers really random to the drive. > - by using a file, if using an "advanced format" drive (with large physical > sectors), you have to be wary of unaligned transfers. Is the partition > aligned so all the accesses really go to the drive aligned to 4 KiB > boundaries? > - by using a tiny file size like 100 MiB, writes could easily get buffered in > a write cache somewhere along the way; 64 and 128 MiB HDD volatile write > cache sizes are common nowadays, and RAID controllers have multi-GiB > non-volatile write caches. > - although you didn't report results with reads, beware that the drive could > end up serving all 100 MiB of random read data from its cache (reads can > always be cached, volatile or not), while throwing away sequential prefetched > read data after returning that data because the drive does not expect the > data to be read again. > - to avoid filesystem interference, directly access the drive with > /dev/disk/by-path, /dev/disk/by-id, or /dev/sdNN type names (or > \\.\PhysicalDriveNN in Windows). If using /dev/sdNN or PhysicalDriveNN, be > very careful not to overwrite your boot drive, since the mapping can change > every reboot; I don't think fio provides any protection from doing so. > > N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·ŸŠˆ§¶›¡Ü¨}©ž²Æ > zÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ&¢)ߢf -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
