[Lustre-devel] [RFC] "lctl readonly" modification proposal
Peter.Braam at Sun.COM
Wed Aug 20 10:39:13 PDT 2008
If I remember correctly the flush is only there to try to reduce rollback.
However, given that failover may happen on a system where the software is
not fully responsive, one could question the wisdom of this reduction. In
any case having more replay due to more rollback is harmless.
I do not see a problem removing this, and I would avoid making it an option.
On 8/20/08 5:23 AM, "Alexander Zarochentsev"
<Alexander.Zarochentsev at Sun.COM> wrote:
> Currently "lctl readonly" command is used in recovery-related acceptance
> test as a disk write barrier, any server operations after such a
> barrier do not change disk state. replay-dual.sh:test_14 is an example,
> it uses test-framework.sh:replay_barrier which calls "lctl readonly".
> However "lctl readonly" cannot immediately "freeze" disk state because
> it does device sync right before setting device r/o.
> The additional sync breaks COS unit tests: COS-effect (syncs between
> dependent transactions) is hidden before the R/O barrier because the
> barrier does device sync anyway and COS-effect is invisible after the
> barrier because all disk writes are disabled already.
> Currently syncs are issued twice at different levels of call stack:
> lctl readonly
> mdt_iocontrol -> dt_sync
> __lvfs_set_rdonly -> lvfs_sbdev_sync(dev)
> dev_set_rdonly(dev, jdev)
> Is there any requirement to have a device sync before setting the device
> If not, syncless variant of "lctl readonly" would be more useful for
> testing. If changing of "lctl readonly" behavior is not possible, it
> would be good to have a syncless set R/O operation under another ioctl.
> syncless R/O and a network barrier might be a good simulation of server
> crash without a need of machine restart.
More information about the lustre-devel