Project

General

Profile

Bug #24867

ceph.file.layout can not set by setfattr

Added by yuanli zhu over 5 years ago. Updated over 5 years ago.

Status:
Need More Info
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
fs
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

I can get the ceph.file.layout by using getfattr.

[root@node1 ~]# getfattr -n ceph.file.layout /nas/cephfs/test.txt
getfattr: Removing leading '/' from absolute path names
  1. file: nas/cephfs/test.txt
    ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=16777216 pool=ecdata"

but i can not set the ceph.file.layout.stripe_count.

[root@node1 ~]# setfattr -n ceph.file.layout.stripe_count -v 1 /nas/cephfs/test.txt
setfattr: /nas/cephfs/test.txt: Directory not empty

also i want to add one attr like ceph.file.layout.protect.

[root@node1 ~]# getfattr -n ceph.file.layout /nas/cephfs/test.txt
getfattr: Removing leading '/' from absolute path names
  1. file: nas/cephfs/test.txt
    ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=16777216 protect=0 pool=ecdata"

i can not set ceph.file.layout.protect again.

[root@node1 ~]# setfattr -n ceph.file.layout.protect -v 1 /nas/cephfs/test.txt
setfattr: /nas/cephfs/test.txt: Directory not empty

History

#1 Updated by yuanli zhu over 5 years ago

When the layout fields of a file are modified using setfattr, this file must be empty, otherwise an error will occur.

how to explain this ,why the file must be empty?

#2 Updated by yuanli zhu over 5 years ago

How to remove this restriction

#3 Updated by Nathan Cutler over 5 years ago

  • Project changed from Ceph to CephFS

#4 Updated by Patrick Donnelly over 5 years ago

  • Status changed from New to Need More Info

Is the file empty? You cannot set the layout on a file that has non-zero size.

#5 Updated by yuanli zhu over 5 years ago

I already know the mistake,the file I set has non-zero size,But i also want to set the non-zero size file.I want to delete the code below:

if (cur->get_projected_inode()->size ||
cur->get_projected_inode()->truncate_seq > 1) {
respond_to_request(mdr, -ENOTEMPTY);
return;
}

in Server.cc->handle_set_vxattr

I wonder if this will cause other mistakes.

#6 Updated by Patrick Donnelly over 5 years ago

yuanli zhu wrote:

I already know the mistake,the file I set has non-zero size,But i also want to set the non-zero size file.I want to delete the code below:

if (cur->get_projected_inode()->size ||
cur->get_projected_inode()->truncate_seq > 1) {
respond_to_request(mdr, -ENOTEMPTY);
return;
}

in Server.cc->handle_set_vxattr

I wonder if this will cause other mistakes.

It will. Changing the layout will confuse the client and cause it to write to the file's data stripes differently from the previous layout. File data may be clobbered, turned to gibberish, etc.

Migrating a file to a different layout is an idea that's come up periodically but an efficient and understandable mechanism for doing so is unsettled.

#7 Updated by yuanli zhu over 5 years ago

Patrick Donnelly wrote:

yuanli zhu wrote:

I already know the mistake,the file I set has non-zero size,But i also want to set the non-zero size file.I want to delete the code below:

if (cur->get_projected_inode()->size ||
cur->get_projected_inode()->truncate_seq > 1) {
respond_to_request(mdr, -ENOTEMPTY);
return;
}

in Server.cc->handle_set_vxattr

I wonder if this will cause other mistakes.

It will. Changing the layout will confuse the client and cause it to write to the file's data stripes differently from the previous layout. File data may be clobbered, turned to gibberish, etc.

Migrating a file to a different layout is an idea that's come up periodically but an efficient and understandable mechanism for doing so is unsettled.

I want add one attr to ceph.file.layout.like ceph.file.layout.protect.I can add to file_layout_t success,but i can not modify it.

struct file_layout_t {
// file -> object mapping
uint32_t stripe_unit; ///< stripe unit, in bytes,
uint32_t stripe_count; ///< over this many objects
uint32_t object_size; ///< until objects are this big
uint32_t protect; //modify by zyli

int64_t pool_id;        ///< rados pool id
string pool_ns; ///< rados pool namespace
file_layout_t(uint32_t su=0, uint32_t sc=0, uint32_t os=0,uint32_t pro=0)
: stripe_unit(su),
stripe_count(sc),
object_size(os),
protect(pro),
pool_id(-1) {
}

in fs_types.h

[root@node1 ~]# getfattr -n ceph.file.layout.protect /nas/cephfs/zyli.txt
getfattr: Removing leading '/' from absolute path names
  1. file: nas/cephfs/zyli.txt
    ceph.file.layout.protect="0"
[root@node1 ~]# setfattr -n ceph.file.layout.protect -v 4 /nas/cephfs/zyli.txt
[root@node1 ~]#
[root@node1 ~]# getfattr -n ceph.file.layout.protect /nas/cephfs/zyli.txt
getfattr: Removing leading '/' from absolute path names
  1. file: nas/cephfs/zyli.txt
    ceph.file.layout.protect="0"

[root@node1 ~]#

Also available in: Atom PDF