On 07/28/2015 05:12 AM, Christoph Hellwig wrote:
On Fri, Jul 24, 2015 at 10:36:45AM -0600, Jens Axboe wrote:
Right, I don't think we need to do that though. If you look at the flags
usage, it's all over the map. Some use test/set_bit, some set it just by
OR'ing the mask. There's no reason we
On Fri, Jul 24, 2015 at 10:36:45AM -0600, Jens Axboe wrote:
> Right, I don't think we need to do that though. If you look at the flags
> usage, it's all over the map. Some use test/set_bit, some set it just by
> OR'ing the mask. There's no reason we can't make this work without relying
> on
On 07/28/2015 05:12 AM, Christoph Hellwig wrote:
On Fri, Jul 24, 2015 at 10:36:45AM -0600, Jens Axboe wrote:
Right, I don't think we need to do that though. If you look at the flags
usage, it's all over the map. Some use test/set_bit, some set it just by
OR'ing the mask. There's no reason we
On Fri, Jul 24, 2015 at 10:36:45AM -0600, Jens Axboe wrote:
Right, I don't think we need to do that though. If you look at the flags
usage, it's all over the map. Some use test/set_bit, some set it just by
OR'ing the mask. There's no reason we can't make this work without relying
on
On 07/24/2015 04:49 AM, Christoph Hellwig wrote:
On Wed, Jul 22, 2015 at 03:59:46PM -0600, Jens Axboe wrote:
One possible solution would be to shrink bi_flags to an unsigned int, no
problems fitting that in. Then we could stuff bi_error in that (new) hole,
and we would end up having the same
On Wed, Jul 22, 2015 at 03:59:46PM -0600, Jens Axboe wrote:
> One possible solution would be to shrink bi_flags to an unsigned int, no
> problems fitting that in. Then we could stuff bi_error in that (new) hole,
> and we would end up having the same size again.
As long as we use
On Wed, Jul 22, 2015 at 03:59:46PM -0600, Jens Axboe wrote:
One possible solution would be to shrink bi_flags to an unsigned int, no
problems fitting that in. Then we could stuff bi_error in that (new) hole,
and we would end up having the same size again.
As long as we use set/test/clear_bt
On 07/24/2015 04:49 AM, Christoph Hellwig wrote:
On Wed, Jul 22, 2015 at 03:59:46PM -0600, Jens Axboe wrote:
One possible solution would be to shrink bi_flags to an unsigned int, no
problems fitting that in. Then we could stuff bi_error in that (new) hole,
and we would end up having the same
On 07/22/2015 12:51 PM, Jens Axboe wrote:
On 07/20/2015 07:29 AM, Christoph Hellwig wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the
On 07/20/2015 07:29 AM, Christoph Hellwig wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the drawback of only communicating a single possible
On 07/20/2015 07:29 AM, Christoph Hellwig wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the drawback of only communicating a single possible
On 07/22/2015 12:51 PM, Jens Axboe wrote:
On 07/20/2015 07:29 AM, Christoph Hellwig wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the
On Mon, 20 Jul 2015 15:29:37 +0200 Christoph Hellwig wrote:
> Currently we have two different ways to signal an I/O error on a BIO:
>
> (1) by clearing the BIO_UPTODATE flag
> (2) by returning a Linux errno value to the bi_end_io callback
>
> The first one has the drawback of only
On 07/20/2015 03:29 PM, Christoph Hellwig wrote:
> Currently we have two different ways to signal an I/O error on a BIO:
>
> (1) by clearing the BIO_UPTODATE flag
> (2) by returning a Linux errno value to the bi_end_io callback
>
> The first one has the drawback of only communicating a single
On Mon, 20 Jul 2015 15:29:37 +0200 Christoph Hellwig h...@lst.de wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the drawback of only
On 07/20/2015 03:29 PM, Christoph Hellwig wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the drawback of only communicating a single
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the drawback of only communicating a single possible
error (-EIO), and the second one has the drawback of
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the drawback of only communicating a single possible
error (-EIO), and the second one has the drawback of
18 matches
Mail list logo
