He's a simple example to (hopefully) make it clear:
$ cd /srv/node/vdc/quarantined/containers/3a7b4bae41a17d0f54b247c727b4f0cd
$ ls -l
total 20
-rw------- 1 swift swift 18432 Aug 15 2016
3a7b4bae41a17d0f54b247c727b4f0cd.db
$ sudo swift-container-info ./3a7b4bae41a17d0f54b247c727b4f0cd.db
Traceback (most recent call last):
File "/usr/bin/swift-container-info", line 32, in <module>
print_info('container', *args, **vars(options))
File "/usr/lib/python2.7/dist-packages/swift/cli/info.py", line 327,
in print_info
info = broker.get_info()
File "/usr/lib/python2.7/dist-packages/swift/container/backend.py",
line 501, in get_info
with self.get() as conn:
File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
return self.gen.next()
File "/usr/lib/python2.7/dist-packages/swift/common/db.py", line 366,
in get
self.possibly_quarantine(*sys.exc_info())
File "/usr/lib/python2.7/dist-packages/swift/common/db.py", line 347,
in possibly_quarantine
renamer(self.db_dir, quar_path, fsync=False)
File "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line
1094, in renamer
os.rename(old, new)
OSError: [Errno 16] Device or resource busy
On 15/06/17 14:06, Mark Kirkwood wrote:
Thanks for the explanation Clay!
As to why, well suppose you have a quarantined container...and want to
see where it thinks it should be. - you'll call swift-container-info
on it right? That calls get_info - so will attempt to re-quarantine
the file...which is unexpected - and scary (it will try to move away
the directory too)! Also means you can't get the metadata as the
script bails before printing it.
regards
Mark
On 15/06/17 13:55, Clay Gerrard wrote:
Pretty sure that's true and mostly optimistic on the part of the db
replicator which is more in the data path for replication - than say
rsync object replication.
If you look at ssync or ec reconstructor you'll see it's quite
possible for them to trip built in DiskFile quarantine behavior
during replication as well!
I wouldn't say it's "by design" but we've never been shy to
quarantine anytime we encounter invalid data - the storage wsgi
servers can quarantine for example - if you happen to hit the right
object at the right time.
Why? ;)
-Clay
On Wed, Jun 14, 2017 at 6:16 PM Mark Kirkwood
<[email protected]
<mailto:[email protected]>> wrote:
This was highlighted to me recently, and after doing some
experiments it
seems that the 'job descriptions' for replicators vs auditors is
different for objects vs containers (and probably accounts).
For objects:
- replicator will move objects to where they should go
- auditor will check validity + quarantine as required
For containers (and possibly accounts - haven't checked but code
looks
similar)
- replicator will move objects to where they should go and check
validity + quarantine as required
- auditor will check validity and quarantine as required
This looks a bit like the container replicator is treading on the
auditors toes - is this intended and/or am I missing something?
In terms of *why* this happens, it seems to be due to:
- ContainerBroker.get_info using a self.get which resolves to
DatabaseBroker.get
- DatabaseBroker.get calls self.possibly_quarantine
So anywhere that these brokers call 'get_info' results in a
potential
quarantine...this *looks* like it might be accidental function
creepage
- thoughts?
(This code analysis done on Mitaka/2.7.0)
regards
Mark
_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
<mailto:[email protected]>
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
