lkml.org 
[lkml]   [2006]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateFri, 5 May 2006 16:54:37 +0200
FromJens Axboe <>
SubjectRe: [PATCH] loop.c: respect bio barrier and sync
On Thu, May 04 2006, Constantine Sapuntzakis wrote:
> I believe that the loop block device does not currently respect
> barriers or syncs issued by its clients. As a result, I have seen
> corrupted log errors when a loopback mounted ext3 file system is
> remounted after a hard stop.
>
> The attached patch attempts to fix this problem by respecting the
> barrier and sync flags on the I/O request. The sync_file function was
> cut-and-paste from the implementation of fsync (I think there's no fd
> so I can't call fsync) to allow the patch to be deployed as an updated
> module. Is there another function that could be used?
>
> Comments are welcome. I am not on the list so please cc: me on any
> response..

Please inline your patches, so one can actually comment on them...

- You should handle sync_file() failure. If we don't have !f_op (will
that ever hit, btw?) or ->fsync(), then fail the barrier with
-EOPNOTSUPP. For fsync failure, well... You probably want to just
error the bio with -EIO then.

- bio_sync() doesn't have the semantics you define it to, it is a hint
to the block layer to start request processing instead of plugging. So
don't treat it as a barrier, ignore it.

- Does this work for all loop_device types?

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-05 16:57    [from the cache]
©2003-2010