On Thu, Oct 25, 2007 at 02:46:17PM -0400, Jun'ichi Nomura wrote:
> So as far as I understand, the point is:
> 1. it's preferable to resize inode after the resume, if possible
Not quite - I'm not expressing a preference yet.
I'm saying the patches you presented were one option to resolve the
pro
Alasdair,
Jun'ichi Nomura wrote:
> So as far as I understand, the point is:
> 1. it's preferable to resize inode after the resume, if possible
Attached is a modified version of the (2/3) patch.
- The logic is basically the same as before.
- Moved the set-size function outside of the table s
Hi Alasdair,
Thanks for the immediate reply.
So as far as I understand, the point is:
1. it's preferable to resize inode after the resume, if possible
2. it's necessary to have nowait version of bdget() to avoid stall
For the 1st item, I guess the reason is that we want to make the
table swa
On Thu, Oct 25, 2007 at 10:18:02AM -0400, Jun'ichi Nomura wrote:
> There is no guarantee that the I/O flowing through the device again.
> The table might need be replaced again, but to do that, the resume
> should have been completed to let the userspace know it.
Then the first attempt to set the
Hi Alasdair,
Alasdair G Kergon wrote:
> Before reviewing the details of the proposed workaround, I'd like to see
> a deeper analysis of the problem to see that there isn't a cleaner way
> to resolve this.
OK. Let me try.
> For example:
>
> Question) What are the realistic situations we must sup
On Wed, Oct 24, 2007 at 05:25:17PM -0400, Jun'ichi Nomura wrote:
> - For some device-mapper targets (multipath and mirror),
> the mapping table sometimes has to be replaced to cope with device
> failure.
> OTOH, device-mapper flushes all pending I/Os upon table replacement
> and m
6 matches
Mail list logo
