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
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
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
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
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 support
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,
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
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
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
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
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 may
12 matches
Mail list logo
