| Summary: | [SNAPSHOT] : CLI crash while creating CG with description more than 1024C and the CG was not created | ||
|---|---|---|---|
| Product: | Red Hat Gluster Storage | Reporter: | senaik |
| Component: | snapshot | Assignee: | Raghavendra Bhat <rabhat> |
| Status: | CLOSED ERRATA | QA Contact: | senaik |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rhgs-3.0 | CC: | nsathyan, rhinduja, rhs-bugs, rjoseph, ssamanta, storage-qa-internal, vagarwal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | SNAPSHOT | ||
| Fixed In Version: | glusterfs-3.4.1.snap.feb05.2014git-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-09-22 19:30:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
senaik
2013-12-13 09:24:31 UTC
Adding a line to 'Expected Results' section : --------------------------------------------- When a CG is created with description more than 1024C , CG should also be created along with warning message . sosreports : ============ http://rhsqe-repo.lab.eng.blr.redhat.com/bugs_necessary_info/snapshots/1042747/ Same issue is seen while creating snap with description more than 1024C http://review.gluster.org/#/c/6501/ has been sent for review. http://review.gluster.org/#/c/6501/ handles the issue. Version : ======== No crash observed while creating snap with description more than 1024C. Snapshot is created successfully after truncating the description with the message: "Description provided is longer than 1024 characters" gluster snapshot create vol0 -n snap1 -d "Using this feature, an admin can take scheduled or unscheduled snapshots of and thereby backup a Glusterfs volume. This also provides a check-point in time to restore to, if and when necessary. In virtual machine hosted environment, this feature also provides a mechanism to take snapshots of the vm-disks.An online-snapshot is a feature where the file-system and associated data continue to be available for the clients, while the snapshot is being taken. Here the onus lies on the application to periodically sync data, so that the snap created has the desired data consistent view. On the other hand, an offline back-up makes the file-system offline or unavailable for a deterministic time-window till the snapshot is taken. This is usually achieved by doing a flush, followed by a freeze/thaw on the file-system prior to taking a snapshot. While offline snapshots are relatively easy to administer, the inaccessibility to the volume(s)/data is a major disadvantage.At any given point in time, a single gluster volume is accessed by multiple clients. In such a scenario, an offline snapshot/backup does not work because taking snapshots could lead to the whole volume being unavailable for a certain time window. This leads to an unknown scenario/behavior for the applications. Moreover in a Cloud environment such unavailability can result in even more compounded and indeterminate system behavior" snapshot create: description truncated: Description provided is longer than 1024 characters snapshot create: snap1: snap created successfully gluster snapshot list vol0 -d Volume Name : vol0 Number of snaps taken : 1 Number of snaps available : 255 Snap Name : snap1 Snap Time : 2014-02-10 09:06:46 Snap UUID : 97503def-e911-4d7a-ae68-48421aa87220 CG Name : Does not exist CG ID : Does not exist Snap Description : Using this feature, an admin can take scheduled or unscheduled snapshots of and thereby backup a Glusterfs volume. This also provides a check-point in time to restore to, if and when necessary. In virtual machine hosted environment, this feature also provides a mechanism to take snapshots of the vm-disks.An online-snapshot is a feature where the file-system and associated data continue to be available for the clients, while the snapshot is being taken. Here the onus lies on the application to periodically sync data, so that the snap created has the desired data consistent view. On the other hand, an offline back-up makes the file-system offline or unavailable for a deterministic time-window till the snapshot is taken. This is usually achieved by doing a flush, followed by a freeze/thaw on the file-system prior to taking a snapshot. While offline snapshots are relatively easy to administer, the inaccessibility to the volume(s)/data is a major disadvantage.At any given point in time, a single gluster volume is Snap Status : In-use Marking the bug as 'Verified' Marking snapshot BZs to RHS 3.0. Fixing RHS 3.0 flags. Fixing RHS 3.0 flags. Setting flags required to add BZs to RHS 3.0 Errata Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1278.html |