|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* One #!/usr/bin/env python and three #!/usr/bin/python were overlooked
in all the other python fixups. Ugh.
* Two new python files missed the memo about #!/usr/bin/python3.
* One #!/usr/bin/env bash.
Various distribution packaging policies have strong wording about
the use of #!/usr/bin/env ...
Note: this patch does not change the use of #!/usr/bin/env bash in
the two files extras/{clang-checker.sh,check_goto.pl} as these are
not included in any packages. (Although I'm not actually sure why
anyone would ever use '/usr/bin/env {sh,bash}' as I'm not aware of
any version-specific differences like there are with, e.g., python.)
* One #!/usr/bin/bash.
On Fedora and CentOS > 6, /bin is a symlink to /usr/bin, so it
makes little difference. But Debian & Ubuntu still have separate
/bin and /usr/bin; and sh and bash are in /bin, not /usr/bin.
(Historically, in BSD and SYSV Unix it was /bin/sh.)
Note: Fedora and CentOS package build runs a script that converts
all /bin/sh and /bin/bash to /usr/bin/sh and /usr/bin/bash.
Change-Id: I9171265829af78dd0cd7622c22b56d22179ff8a3
updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
|
|
spec-files:
https://review.gluster.org/#/c/18854/
Overview:
* Cloudsync maintains three file states in it's inode-ctx i.e
1 - LOCAL,
2 - REMOTE,
3 - DOWNLOADING.
* A data modifying fop is allowed only if the state is LOCAL.
If the state is REMOTE or DOWNLOADING, client will download
or wait for the download to finish initiated by other client.
* Multiple download and upload from different clients are synchronized
by inodelk.
* In POSIX a state check is done (part of different commit)before
allowing the fop to continue. If the state is remote/downloading the
fop is unwound with EREMOTE. The client will then download the file
and continue with the fop again.
* Basic Algo for fop (let's say write fop):
- If LOCAL -> resume fop
- If REMOTE ->
- INODELK
- STAT (this gets state and heal the state if needed)
- DOWNLOAD
- resume fop
Note:
* Developers will need to write plugins for download, based on the
remote store they choose. In phase-1, support will be added for
one remote store per volume. In future, more options for multiple
remote stores will be explored.
TODOs:
- Implement stat/lookup/readdirp to return size info from xattr
- Make plugins configurable
- Implement unlink fop
- Add metrics collection
- Add sharding support
Design Contributions:
Aravinda V K <avishwan@redhat.com>
Amar Tumballi <amarts@redhat.com>
Ram Ankireddypalle <areddy@commvault.com>
Susant Palai <spalai@redhat.com>
updates: #387
Change-Id: Iddf711ee7ab4e946ae3e472ff62791a7b85e6d4b
Signed-off-by: Susant Palai <spalai@redhat.com>
|