[Bugs] [Bug 1465123] Fd based fops fail with EBADF on file migration

bugzilla at redhat.com bugzilla at redhat.com
Thu Sep 28 07:44:17 UTC 2017


https://bugzilla.redhat.com/show_bug.cgi?id=1465123

Krutika Dhananjay <kdhananj at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(kdhananj at redhat.c |
                   |om)                         |



--- Comment #12 from Krutika Dhananjay <kdhananj at redhat.com> ---
(In reply to Nithya Balachandran from comment #11)
> (In reply to Krutika Dhananjay from comment #10)
> > It depends on which copy DHT on the client uses to serve metadata fops.
> > 
> > 1. If it is guaranteed that the xattr value on the src and dst copy will
> > eventually be in sync without any out-of-order updates causing them to
> > deviate, then i'm guessing it should be OK.
> 
> > 
> > 2. If until migration completes, DHT on the client serves iatts as part of
> > lookup, stat etc from the correct copy (the copy that has witnessed all the
> > xattrops wound by shard as part of ongoing writes), then it is probably ok.
> 
> 
> What happens if an fxattrop is sent to a migrating file after all xattrs
> have been copied off the src file? That information would not be copied to
> the dst as dht_fxattrop does not perform migration checks.

Do you mean to say that the fxattrop will only be wound on the src file which
will subsequently be unlinked without any further syncing to destination copy?
If so, then it will be a problem. VM operations are very sensitive to incorrect
image size. Lot of our vm-corruption/vm-not-booting problems in the past have
been because somewhere the size read/cached of the image was wrong.

-Krutika

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GiTGNO0qJB&a=cc_unsubscribe


More information about the Bugs mailing list