Subject: Re: PR/34293 CVS commit: src/sys/dev
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 09/10/2006 17:07:19
> > > If you limit dirty buffers to 1/2 of total buffer cache you will
> > > still deadlock. It doesn't matter what limit you put on dirty
> > > buffers. Whenever that limit it reached then vnd cannot process
> > > them because for doing so it would have to exceed that limit. You
> > > must make sure that the filesystem that vnd is calling through
> > > VOP_STRATEGY _can_ allocate new buffers, even those that it
> > > can use for writing.
> > which filesystem are you talking about?
> The filesystem where the virtual device resides on, in that
> my UFS.
how can vnd on UFS allocate new dirty buffer cache
in order to make a progress?
> > > If my patch doesn't make sense, then try to understand why it works.
> > now i've tried your patch. it didn't work for me.
> That's probably because you have a completely different test that
> shows a different problem.
IMO, it's fundamentally the same problem.
> > dd if=/dev/zero of=/mnt/a bs=1m seek=1m (ENOSPC)
> That creates a sparse file starting at offset 1TB.
> > vnconfig vnd1 /mnt/a
> > dd if=/dev/zero of=/dev/vnd1d bs=1m seek=1m (deadlock)
> That would write the sparse file starting from offset 1TB.
yes, they were intentional.
(to make sure it uses indirect blocks, w/o requiring much disk space.)
> > (i can't follow your recipe in the PR because i don't have 10G disk space.)
> You can probably use a smaller file as long as enough data gets
> written. mkfs.ext2 just writes the ext2-metadata, so a simple dd
> would require a much smaller file.
i don't want to waste my time to find a case that the patch can work.
there might be a case, but it doesn't make the patch correct.
> Mine is "callers of vndstrategy", for writing the block device
> that's the same as "callers of write(2)".
no, they are fundamentally different.
the former cleans (or, at least, start to clean) buffers and
the latter dirties buffers.
yes, there are exceptions. eg. write(2) can start async writeback.
but they don't alter the big picture.
> I have a look at your patch.