Re: [BUG] mmap and file init with 0 length

From: Jens Axboe <jens.axboe_at_oracle.com>
Date: Wed, 26 Mar 2008 10:27:14 +0100

On Wed, Mar 26 2008, Zhang, Yanmin wrote:
> On Wed, 2008-03-26 at 10:14 +0100, Jens Axboe wrote:
> > On Wed, Mar 26 2008, Zhang, Yanmin wrote:
> > > On Wed, 2008-03-26 at 09:55 +0100, Jens Axboe wrote:
> > > > On Wed, Mar 26 2008, Zhang, Yanmin wrote:
> > > > > On Wed, 2008-03-26 at 09:20 +0100, Jens Axboe wrote:
> > > > > > On Wed, Mar 26 2008, Zhang, Yanmin wrote:
> > > > > > > fio is killed with a SIGBUS. Pls. see below job file.
> > > > > > >
> > > > > > > Actually, if the ioengine=mmap and rw=write/randwrite, fio just
> > > > > > > unlinks the file and creates a new file whose length is 0. sys_mmap
> > > > > > > could succeed, but later on when fio accesses the mmapped area, kernel
> > > > > > > will send fio a SIGBUS and kill it.
> > > > > > >
> > > > > > >
> > > > > > > Could fio create a real file when ioengine=mmap and
> > > > > > > rw=write/randwrite? For exmaple, below job_file could ask fi oto
> > > > > > > create file data0/f1 whose length is 4G.
> > > > > > >
> > > > > >
> > > > > > I've committed a fix for this, the below one-liner should fix it for
> > > > > > you.
> > > > > >
> > > > > > diff --git a/filesetup.c b/filesetup.c
> > > > > > index e847276..bb43ee5 100644
> > > > > > --- a/filesetup.c
> > > > > > +++ b/filesetup.c
> > > > > > @@ -30,7 +30,8 @@ static int extend_file(struct thread_data *td, struct fio_file *f)
> > > > > > * does that for operations involving reads, or for writes
> > > > > > * where overwrite is set
> > > > > > */
> > > > > > - if (td_read(td) || (td_write(td) && td->o.overwrite))
> > > > > > + if (td_read(td) || (td_write(td) && td->o.overwrite) ||
> > > > > > + (td_write(td) && td->io_ops->flags & FIO_NOEXTEND))
> > > > > > new_layout = 1;
> > > > > > if (td_write(td) && !td->o.overwrite)
> > > > > > unlink_file = 1;
> > > > > This patch does fix it. I downloaded the latest git tarball of fio and got below error.
> > > > >
> > > > >
> > > > > [ymzhang_at_lkp-tt02-x8664 fio]$ fio /tmp/job_file
> > > > > job_group0_sub0: (g=0): rw=randrw, bs=1K-1K/4K-4K, ioengine=vsync, iodepth=256
> > > > > job_group0_sub0: (g=0): rw=randrw, bs=1K-1K/4K-4K, ioengine=vsync, iodepth=256
> > > > > job_group0_sub1: (g=1): rw=randrw, bs=1K-1K/4K-4K, ioengine=vsync, iodepth=256
> > > > > job_group0_sub1: (g=1): rw=randrw, bs=1K-1K/4K-4K, ioengine=vsync, iodepth=256
> > > > > Starting 4 processes
> > > > > fio: failed allocating random map. If running a large number of jobs, try the 'norandommap' option
> > > > > fio: failed allocating random map. If running a large number of jobs, try the 'norandommap' option
> > > > > fio: failed allocating random map. If running a large number of jobs, try the 'norandommap' option
> > > > > fio: failed allocating random map. If running a large number of jobs, try the 'norandommap' option
> > > > >
> > > > >
> > > > > I checked HOWTO that norandommap couldn't guarantee every block is
> > > > > written/read. Is there any other method to solve above error?
> > > >
> > > > It's a bit quirky, fio should probably just fallback to norandommap when
> > > > that happens, it's not a huge deal.
> > > I still want the testing could cover all blocks of a file when the
> > > file is big.
> >
> > Understandable. I checked in a change to allow it to continue, I'll add
> > an option that will enable it so the user gets a choice.
> >
> > > MAX_POOLS=32 looks too hard.
> >
> > I bumped the initial pool size, as an allocation cannot span two pools
> > anyway. So now it's 1mb and 32 pools, so 32mb in total.
> It does work with my job_file.

Good! I'm now adding a pool size and pool nr command line option, so one
doesn't have to recompile fio for even bigger jobs if you run into this
problem in the field.

-- 
Jens Axboe
Received on Wed Mar 26 2008 - 10:27:14 CET

This archive was generated by hypermail 2.2.0 : Wed Mar 26 2008 - 10:30:02 CET