| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ric asked me to look at replacing the GPL licensed MD5 code with
something better, i.e. perhaps faster, and with a less restrictive
license, etc. So I took a couple hour holiday from working on
wrapping up the client_t and did this.
OpenSSL (nee SSLeay) is released under the OpenSSL license, a BSD/MIT
style license. OpenSSL (libcrypto.so) is used on Linux, OS X and *BSD,
Open Solaris, etc. IOW it's universally available on the platforms we
care about. It's written by Eric Young (eay), now at EMC/RSA, and I
can say from experience that the OpenSSL implementation of MD5 (at least)
is every bit as fast as RSA's proprietary implementation (primarily
because the implementations are very, very similar.) The last time I
surveyed MD5 implementations I found they're all pretty much the same
speed.
I changed the APIs (and ABIs) for the strong and weak checksums.
Strictly speaking I didn't need to do that. They're only called on
short strings of data, i.e. pathnames, so using int32_t and uint32_t
is ostensibly okay. My change is arguably a better, more general API
for this sort of thing. It's also what bit me when gerrit/jenkins
validation failed due to glusterfs segv-ing. (I didn't pay close enough
attention to the implementation of the weak checksum. But it forced me
to learn what gerrit/jenkins are doing and going forward I can do better
testing before submitting to gerrit.)
Now resubmitting with a BZ
Change-Id: I545fade1604e74fc68399894550229bd57a5e0df
BUG: 807718
Signed-off-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Reviewed-on: http://review.gluster.com/3019
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. What
--------
This change introduces an infrastructure change in the filesystem
which lets filesystem operation address objects (inodes) just by its
GFID. Thus far GFID has been a unique identifier of a user-visible
inode. But in terms of addressability the only mechanism thus far has
been the backend filesystem path, which could be derived from the
GFID only if it was cached in the inode table along with the entire set
of dentry ancestry leading up to the root.
This change essentially decouples addressability from the namespace. It
is no more necessary to be aware of the parent directory to address a
file or directory.
2. Why
-------
The biggest use case for such a feature is NFS for generating
persistent filehandles. So far the technique for generating filehandles
in NFS has been to encode path components so that the appropriate
inode_t can be repopulated into the inode table by means of a recursive
lookup of each component top-down.
Another use case is the ability to perform more intelligent self-healing
and rebalancing of inodes with hardlinks and also to detect renames.
A derived feature from GFID filehandles is anonymous FDs. An anonymous FD
is an internal USABLE "fd_t" which does not map to a user opened file
descriptor or to an internal ->open()'d fd. The ability to address a file
by the GFID eliminates the need to have a persistent ->open()'d fd for the
purpose of avoiding the namespace. This improves NFS read/write performance
significantly eliminating open/close calls and also fixes some of today's
limitations (like keeping an FD open longer than necessary resulting
in disk space leakage)
3. How
-------
At each storage/posix translator level, every file is hardlinked inside
a hidden .glusterfs directory (under the top level export) with the name
as the ascii-encoded standard UUID format string. For reasons of performance
and scalability there is a two-tier classification of those hardlinks
under directories with the initial parts of the UUID string as the directory
names.
For directories (which cannot be hardlinked), the approach is to use a symlink
which dereferences the parent GFID path along with basename of the directory.
The parent GFID dereference will in turn be a dereference of the grandparent
with the parent's basename, and so on recursively up to the root export.
4. Development
---------------
4a. To leverage the ability to address an inode by its GFID, the technique is
to perform a "nameless lookup". This means, to populate a loc_t structure as:
loc_t {
pargfid: NULL
parent: NULL
name: NULL
path: NULL
gfid: GFID to be looked up [out parameter]
inode: inode_new () result [in parameter]
}
and performing such lookup will return in its callback an inode_t
populated with the right contexts and a struct iatt which can be
used to perform an inode_link () on the inode (without a parent and
basename). The inode will now be hashed and linked in the inode table
and findable via inode_find().
A fundamental change moving forward is that the primary fields in a
loc_t structure are now going to be (pargfid, name) and (gfid) depending
on the kind of FOP. So far path had been the primary field for operations.
The remaining fields only serve as hints/helpers.
4b. If read/write is to be performed on an inode_t, the approach so far
has been to: fd_create(), STACK_WIND(open, fd), fd_bind (in callback) and
then perform STACK_WIND(read, fd) etc. With anonymous fds now you can do
fd_anonymous (inode), STACK_WIND (read, fd). This results in great boost
in performance in the inbuilt NFS server.
5. Misc
-------
The inode_ctx_put[2] has been renamed to inode_ctx_set[2] to be consistent
with the rest of the codebase.
Change-Id: Ie4629edf6bd32a595f4d7f01e90c0a01f16fb12f
BUG: 781318
Reviewed-on: http://review.gluster.com/669
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
| |
|
|
|
|
|
|
|
|
| |
helper functions were more than 800 lines
Signed-off-by: Amar Tumballi <amar@gluster.com>
Signed-off-by: Anand Avati <avati@gluster.com>
BUG: 3158 (Keep code more readable and clean)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=3158
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- In addition to posix, protocol/server also adds a check to make sure that
iobuf allocated to hold readdir/readdirp response can hold all the dentries,
rpc and proc (readdir/readdirp) header.
Signed-off-by: Raghavendra G <raghavendra@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 1430 (encoding of readdirp response fails occasionally)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1430
|
| |
|
|
|
|
|
|
| |
Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 329 (Replacing memory allocation functions with mem-type functions)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=329
|
| |
|
|
|
|
|
|
| |
Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 971 (dynamic volume management)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=971
|
| |
|
|
|
|
| |
translator.
Signed-off-by: Anand V. Avati <avati@amp.gluster.com>
|
| |
|
