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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
