Bug 840919 - Change in files ownership and flags after re-balancing
Change in files ownership and flags after re-balancing
Status: CLOSED DUPLICATE of bug 852361
Product: GlusterFS
Classification: Community
Component: posix (Show other bugs)
3.3.0
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Vijay Bellur
:
Depends On:
Blocks: 852580
  Show dependency treegraph
 
Reported: 2012-07-17 11:19 EDT by Atanas Dimitrov
Modified: 2012-09-13 05:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 852580 (view as bug list)
Environment:
Last Closed: 2012-09-13 05:52:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rebalancing log (219.09 KB, text/x-log)
2012-07-17 11:19 EDT, Atanas Dimitrov
no flags Details

  None (edit)
Description Atanas Dimitrov 2012-07-17 11:19:29 EDT
Created attachment 598672 [details]
rebalancing log

Description of problem:
after rebalancing on a extended volume(bricks added) the rights of the files in the volume changed to- ownership:root
=====================================
for example:
-rw-r--r--. 1 root root     589824 Jul 17 18:00 368a8bf9-9990-43a1-8b1c-34d30c740628
=====================================
and they were like this, before the rebalancing:
=====================================
-rwxrwxrwx. 1 qemu qemu     589824 Jul 17 11:57 e168ec07-a1e2-485d-aa9d-a07d508e9f6c
=====================================
Also every new file created in that volume is created with 
-rw-r--r--. 1 root root, although the up directory is owned by qemu and before the rebalancing every new file was getting the proper flags and ownership.

 

Version-Release number of selected component (if applicable):
glusterfs-3.3.0-2.fc16- it is fedora package on Fedora 16

How reproducible:
add bricks to stripe-replicated-distributed volume and rebalance it.

Steps to Reproduce:
1.Add bricks to striped-replicated-distributed volume
2. Make volume layer-fix 
3. Make volume rebalance start
  
Actual results:
all the files in the volume and all the newly created change their owner to root and flags to "-rw-r--r--."- so 644.

Expected results:
to retain the behaviour before the rebalancing- every newly created file was owned by user:qemu, group:qemu. and flags 777.

Additional info:
all the time, i got:
[2012-07-17 13:08:38.671157] E [stripe-helpers.c:271:stripe_ctx_handle] 0-dis-magnetics-3-stripe-2: Failed to get stripe-size
[2012-07-17 13:08:38.671209] E [stripe.c:212:stripe_lookup_cbk] 0-dis-magnetics-3-stripe-2: Error getting fctx info from dict
but in the source rpm ChangeLog i saw that these two were already addressed in source commits. I'm not sure if these are related.

During the rebalancing there were some failures but i'm not sure if they're related to the root ownership thing- i'm sending the whole rebalancing log.

================All the failures on one host.
  Node Rebalanced-files          size       scanned      failures         status
                               ---------      -----------   -----------   -----------   -----------   ------------
                               localhost                0            0         1710          133      completed
                                   host1              151   1225920000         1857            0      completed
                                   host2              252   3509917696         2109           32      completed
=======================
Comment 1 shishir gowda 2012-09-13 05:52:10 EDT
This seems to be a duplicate of bug 852361.
The issue was with rebalance creating destination files with root ownership. It would set the ownership to original after migration was complete.
But, since the user did not run with force option, the free space check (dst has less space than src) prevents migration, the link file would end up with wrong permissions.

*** This bug has been marked as a duplicate of bug 852361 ***

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