> -----Original Message----- > From: fio-owner@xxxxxxxxxxxxxxx [mailto:fio-owner@xxxxxxxxxxxxxxx] On > Behalf Of Sitsofe Wheeler > Sent: Wednesday, December 21, 2016 4:40 AM > To: Elliott, Robert (Persistent Memory) <elliott@xxxxxxx> > Cc: fio@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 2/2] pmemblk: Clarify fsize is in MiB not MB > > On 21 December 2016 at 07:57, Elliott, Robert (Persistent Memory) > <elliott@xxxxxxx> wrote: > > > >> > * When specifying the filename, if the block pool file does > not > >> already > >> > - * exist, then the pmemblk engine can create the pool file if > >> you specify > >> > + * exist, then the pmemblk engine creates the pool file if > you > >> specify > >> > * the block and file sizes. BSIZE is the block size in > bytes. > >> > - * FSIZEMB is the pool file size in MB. > >> > + * FSIZEMiB is the pool file size in MiB. > >> > >> It might be safer to explicitly say "in megabytes" rather than "in > >> MiB" here because of fio's infamous reversal of the terms M(B)/MiB > >> (https://github.com/axboe/fio/issues/103 ). Can the user > explicitly > >> specify units as is done elsewhere in fio? > > > > "mega" is still the SI power of 10 prefix; mebi would be the IEC > > power of 2 prefix. > > OK. > > > I'm working on a big patch set to clean up the units throughout the > > whole codebase, and hope to post it tomorrow. > > > > For inputs (e.g., parameters in .fio files), kb_base=1000 will > > cause it to use proper units and kb_base=1024 (the default) will > > continue to use wrong units (for compatibility). I'm guessing that > > kb_base=1000 has little use so far (there are several bugs making > > it pretty unusable right now) so we can take it over for this > > purpose. > > Perhaps it would be better to phase out kb_base and just introduce > something like iec_mode instead (perhaps with an alias iecly_correct > to provide snark for those who love powers of 10 sizes)? That way > anyone depending on the buggy kb_base behaviour would at least be > forced to look up the new option when it disappeared. I'll post the first version with kb_base, but am open to a new parameter like that. > Agh... From my perspective fio's interactive output is wide enough as > it stands - it already typically exceeds 80 columns and causes > wrapping until I make the terminal is wider with moderate speed > read/write workloads. > > Example text output: > > > > Jobs: 576 (f=576), 549MiB/s-80.5GiB/s: [w(288),r(288)] [0.0% done] > [r=33200MiB/s,w=25544MiB/s,t=0KiB/s] [r=8499k,w=6539k,t=0 iops] [eta > 06h:59m:53s] The rate limits (either bandwidth or IOPS) are only shown if they are set, so it's a bit better if there are none. I would like to drop the trim rates if trims are not being used. The real worst case is while all the jobs are in different thread states, and you get something like: Jobs: 197 (f=101), rate=197MiB/s-21.7GiB/s: [f(2),_(1),f(2),_(1),f(4),_(2),f(1),_(1),f(6),_(1),f(2),_(3),f(1),_(2), f(1),_(1),f(4),_(2),f(3),_(2),f(3),_(1),f(1),_(1),f(1),E(1),f(7),_(1),f (1),_(3),f(1),_(1),f(1),_(1),f(5),_(3),f(4),E(2),f(1),_(1),f(1),_(2),f( 3),_(2),f(2),_(1),f(2),_(1),f(6),_(2),f(1),_(2),f(1),_(2),f(1),_(2),f(4 ),_(2),f(2),_(1),f(7),_(3),f(3),_(3),f(6),_(2),f(4),_(3),f(16),_(2),f(2 ),_(1),f(7),_(2),f(1),E(1),f(1),_(1),f(3),_(2),f(3),_(1),f(6),_(2),f(1) ,_(1),f(4),E(1),f(2),_(1),f(3),E(1),f(3),_(6),f(1),_(1),f(1),_(2),f(1), _(3),f(1),_(1),f(3),_(1),f(2),_(1),f(6),_(2),f(5),_(1),f(1),_(1),f(1),_ (2),f(1),_(1),E(1),_(2),f(1),E(1),_(2),f(1),_(5),E(1),_(4),f(1),_(1),E( 1),_(1),E(2),_(1),f(5),_(2),f(1),_(2),E(1),_(2),f(2),E(1),_(1),E(1),_(3 ),f(2),_(3),E(1),_(1),E(1),_(5),f(1),_(1),E(1),f(2),E(1),_(1),E(1),_(1) ,f(3),E(1),_(2),E(1),_(4),f(1),_(1),f(1),E(3),_(1),f(1),E(2),_(1),f(1), _(4),E(3),f(1),E(3),_(1),E(1),_(1),f(2),E(2),_(2),E(3),_(1),E(1),_(3),f (1),E(2),_(1),E(2),_(1),E(1),f(1),_(2),E(1),_(1),E(5),_(5),E(6),_(32),E (1),_(52),E(1),_(76)] [100.0% done] [25908MiB/s |19797MiB/s|0K iB/s] [6632K|5068K|0 iops] [eta 00m:00s] > > ... > > drive_0: (groupid=0, jobs=36): err= 0: pid=54154: Tue Dec 20 > 08:17:35 2016 > > write: io=75.7TiB, bw=3145MiB/s (3298MB/s), iops=805k, > runt=25200023msec > > ... > > Run status group 0 (all jobs): > > READ: io=837GiB (899GB), aggrbw=31.9GiB/s (34.2GB/s), > minbw=31.9GiB/s (34.2GB/s), maxbw=31.9GiB/s (34.2GB/s), > mint=26287msec, maxt=26287msec > > WRITE: io=640GiB (687GB), aggrbw=24.4GiB/s (26.2GB/s), > minbw=24.4GiB/s (26.2GB/s), maxbw=24.4GiB/s (26.2GB/s), > mint=26300msec, maxt=26300msec > For reference, the current status group format is: WRITE: io=8788KB, aggrb=1075KB/s, minb=358KB/s, maxb=359KB/s, mint=8166msec, maxt=8172msec > The other problem is that people really do > scrape fio's "normal" output today... I know, I know, it's not > stable, use terse/json or etc but it happens. See > https://www.youtube.com/watch?v=vm1GJMp0QN4#t=17m48s for a Brendan > Gregg fio output parsing war story (punchline is at > https://youtu.be/vm1GJMp0QN4?t=1308 ). Perhaps you only get this new > output in iec_mode? I have to admit showing both the SI unit and the > binary unit forms is the way GNU tools like dd wound up going in the > end. trim values were slipped in fairly recently, even when they're not being used. We could change some of the lines more drastically to try to ensure that parsing fails rather than misinterprets, like: write: io=75.7TiB, bw=3145MiB/s (3298MB/s), iops=805k, runt=25200023msec to write: IOPS=805k, BW=3145MiB/s (3298MB/s, 75.7TiB/7H) > > The SI storage unit wars haven't generated winners - only people who > are confused what the numbers mean and who are angry the units aren't > what they want. The difference used to not matter; when I run the new code on a short benchmark with a slow HDD and get 31.2kB/S (30.4KiB/s), who cares? With large capacities and fast speeds, though, the difference has become quite noticeable. NVDIMMs yield results like 31.9 GiB/s (34.2GB/s), a 7.2% difference. ��.n��������+%������w��{.n�������^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
