summaryrefslogtreecommitdiffstats
path: root/xlators/features/snapview-server/src/snapview-server.h
Commit message (Collapse)AuthorAgeFilesLines
* uss/gluster: generate gfid for snapshot files from snapname and gfidvmallika2016-03-101-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | If 'a' and 'b' are hardlinks, we need to generate a virtual gfid for these files so that the inode number for 'a' and 'b' are same. Generate gfid as below: gfid_of_a = MD5(snapname + back_end_gfid(a)) if '/dir1/a' and '/dir2/b' are hardlinks, then inode number should be same for all below files: /mnt/.snaps/snap1/dir1/a /mnt/.snaps/snap1/dir2/b /mnt/dir1/.snaps/snap1/a /mnt/dir2/.snaps/snap1/b Change-Id: Ifda793455610e554f3f1e4cbb90d44c02cda4b0f BUG: 1171703 Signed-off-by: vmallika <vmallika@redhat.com> Reviewed-on: http://review.gluster.org/9255 Smoke: Gluster Build System <jenkins@build.gluster.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Rajesh Joseph <rjoseph@redhat.com>
* build: do not #include "config.h" in each fileNiels de Vos2015-05-291-5/+0
| | | | | | | | | | | | | | | | | | Instead of including config.h in each file, and have the additional config.h included from the compiler commandline (-include option). When a .c file tests for a certain #define, and config.h was not included, incorrect assumtions were made. With this change, it can not happen again. BUG: 1222319 Change-Id: I4f9097b8740b81ecfe8b218d52ca50361f74cb64 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: http://review.gluster.org/10808 Tested-by: Gluster Build System <jenkins@build.gluster.com> Tested-by: NetBSD Build System Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
* uss: CIFS gives error while accessing .snaps directoryRajesh Joseph2014-12-031-6/+0
| | | | | | | | | | | | | | | | | | | | | CIFS sends getxattr call while accessing .snaps directory. snapview server should return ENODATA if getxattr is called on .snaps folder. Also flush on .snaps folder should be handled. Windows client sends and getxattr call on the parent folder of .snaps with a special key to get the real filename of a file. This is used by samba to do case insensitive check of files. Fixed few FreeBSD compilation error. bug: 1168875 Change-Id: I74d5cb4419568c8ed8709ba6d1ddff0e41392204 Signed-off-by: Rajesh Joseph <rjoseph@redhat.com> Reviewed-on: http://review.gluster.org/9211 Reviewed-by: Raghavendra Bhat <raghavendra@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* uss/gluster: creating file/directories inside .snaps should fail withvmallika2014-11-131-2/+4
| | | | | | | | | | | | | | | EROFS When an attempt is made to create file/directories inside .snaps, it fails with wrong error message as "Stale file handle". It should fail with "Read-only file system" Change-Id: I3a812a0afc4762cbb71ab180b9394c866e576a66 BUG: 1159840 Signed-off-by: vmallika <vmallika@redhat.com> Reviewed-on: http://review.gluster.org/9039 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* USS : Display only the activated snapshotsSachin Pandit2014-11-121-1/+4
| | | | | | | | | | | | | | | Instead of displaying all the snapshots in the uss world, it is better if we display only the activated snapshots. Change-Id: I70d3ec212b62ec15956ae3e826bc4201d8dedd17 BUG: 1155042 Signed-off-by: Sachin Pandit <spandit@redhat.com> Reviewed-on: http://review.gluster.org/8958 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Avra Sengupta <asengupt@redhat.com> Reviewed-by: Rajesh Joseph <rjoseph@redhat.com> Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com> Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
* features/snapview-server: check if the reference to the snapshot world isRaghavendra Bhat2014-10-281-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | correct before doing any fop The following operations might lead to problems: * Create a file on the glusterfs mount point * Create a snapshot (say "snap1") * Access the contents of the snapshot * Delete the file from the mount point * Delete the snapshot "snap1" * Create a new snapshot "snap1" Now accessing the new snapshot "snap1" gives problems. Because the inode and dentry created for snap1 would not be deleted upon the deletion of the snapshot (as deletion of snapshot is a gluster cli operation, not a fop). So next time upon creation of a new snap with same name, the previous inode and dentry itself will be used. But the inode context contains old information about the glfs_t instance and the handle in the gfapi world. Directly accessing them without proper check leads to ENOTCONN errors. Thus the glfs_t instance should be checked before accessing. If its wrong, then right instance should be obtained by doing the lookup. Change-Id: Idca0c8015ff632447cea206a4807d8ef968424fa BUG: 1151004 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> Reviewed-on: http://review.gluster.org/8917 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* snapview-server: get the handle if its absent before doing any fopRaghavendra Bhat2014-09-121-0/+29
| | | | | | | | | | | | | | | | | | | | | | | * Now that NFS server does inode linking in readdirp, it can resolve the gfid (i.e. find the right inode from its inode table) present in the filehandle sent by the NFS client on which a fop came. So instead of sending the lookup on that entry, it directly sends the fop. But snapview-server does not get the handle for the entries in readdirp (because doing a lookup on each entry via gfapi would be costly. So it waits till a lookup is done on that inode, to get the handle and the fs instance and fill it in the inode context). So when NFS resoves the gfid and directly sends the fop, snapview-server will not be able to perform the fop as the inode contet would not contain the fs instance and the handle. So fops should check for the handle before doing gfapi calls. If the handle and fs instance are not present in the inode context they should get them by doing an explicit lookup on the entry. Change-Id: Idd648fbcc3ff6aadc3b63ff236561ca967b92f5d BUG: 1115949 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> Reviewed-on: http://review.gluster.org/8324 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* snapview-server: register a callback with glusterd to get notificationsRaghavendra Bhat2014-09-081-21/+60
| | | | | | | | | | | | | | | * As of now snapview-server is polling (sending rpc requests to glusterd) to get the latest list of snapshots at some regular time intervals (non configurable). Instead of that register a callback with glusterd so that glusterd sends notifications to snapd whenever a snapshot is created/deleted and snapview-server can configure itself. Change-Id: I17a274fd2ab487d030678f0077feb2b0f35e5896 BUG: 1119628 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> Reviewed-on: http://review.gluster.org/8150 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* Get snapshot info dynamically via new rpc and infra for snapview-server to ↵Anand Subramanian2014-06-151-9/+53
| | | | | | | | | | | refresh snaplist BUG: 1105439 Change-Id: I4bb312a53d88f6f4955e69a3ef2b4955ec17f26d Signed-off-by: Anand Subramanian <anands@redhat.com> Reviewed-on: http://review.gluster.org/8001 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* user servicable snapshotsRaghavendra Bhat2014-05-291-0/+88
Change-Id: Idbf27dbe088e646a8ab81cedc5818413795895ea Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> Signed-off-by: Anand Subramanian <anands@redhat.com> Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> Reviewed-on: http://review.gluster.org/7700 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>