Bug 1463192 - gfapi: discard glfs object when volume is deleted
Summary: gfapi: discard glfs object when volume is deleted
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: libgfapi
Version: rhgs-3.3
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: ---
Assignee: Niels de Vos
QA Contact: Vivek Das
URL:
Whiteboard:
Depends On: 1463191
Blocks: 1459850
TreeView+ depends on / blocked
 
Reported: 2017-06-20 11:12 UTC by Prasanna Kumar Kalever
Modified: 2019-05-09 11:12 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1463191
Environment:
Last Closed: 2018-11-19 07:35:58 UTC
Embargoed:


Attachments (Terms of Use)
Small test program (4.30 KB, text/plain)
2018-10-08 13:49 UTC, Niels de Vos
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1461808 0 unspecified CLOSED glfs_get_volumeid() returns junk strings 2021-02-22 00:41:40 UTC

Internal Links: 1461808

Description Prasanna Kumar Kalever 2017-06-20 11:12:28 UTC
Description of problem:

currently, once we have a glfs object in hand for a given volume, after deleting and recreating the volume with same name, we still can access new volume using the old glfs object, which is wrong.

Version-Release number of selected component (if applicable):
mainline

How reproducible:
1. write a gfapi program, once you are done calling glfs_init() try creating a file in the volume, now apply break-point there.

2. delete the volume and recreate the volume with the same name.

3. now continue with your program, in the next lines try creating another file in the volume using the same old glfs object

4. surprisingly it allows to create.

My use-case was more like calling glfs_get_volumeid() returns old volume id rather than throwing an error which should say glfs object is not valid or worst case return new volume id, but in my case it returned old uuid.

Refer https://bugzilla.redhat.com/show_bug.cgi?id=1461808#c9 for some more interesting context and sample programs.

Actual results:
with old glfs object we still can access new volume

Expected results:
return invalid object.

Comment 7 Niels de Vos 2018-10-08 13:49:58 UTC
Created attachment 1491665 [details]
Small test program

I am unable to reproduce the problem. Could you explain what I am missing, or better yet, adapt the program?

Compile:

$ gcc -Wall -g -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 -DUSE_POSIX_ACLS=1 -I/usr/include/uuid    -lacl -lgfapi -lglusterfs -lgfrpc -lgfxdr -luuid    test-volume-recreate.c   -o test-volume-recreate

Run:

$ ./test-volume-recreate $HOSTNAME bz1463192 $PWD/bz1463192.log
volume create: bz1463192: success: please start the volume to access data
volume start: bz1463192: success
glfs_set_volfile_server : returned 0
glfs_set_logging : returned 0
glfs_init : returned 0
volume stop: bz1463192: success
volume delete: bz1463192: success
volume create: bz1463192: success: please start the volume to access data
volume start: bz1463192: success
glfs_h_anonymous_write : returned error -1 (Stale file handle)
glfs_fini(fs) returned 0

Comment 8 Niels de Vos 2018-10-08 13:51:11 UTC
The above was tested on glusterfs-4.1.5.

Comment 9 Amar Tumballi 2018-11-19 07:35:58 UTC
Prasanna, I would mark this as CLOSED Upstream, mainly to highlight that this is not critical on OCS setup, and also looks like on upstream master, the issue is not happening too.


Note You need to log in before you can comment on or make changes to this bug.