gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gluster-devel] best practice to ensure data integrity at a concurrent


From: Dongmin Yu
Subject: [Gluster-devel] best practice to ensure data integrity at a concurrent
Date: Wed, 17 Feb 2010 12:05:00 +0000

Hello,

 

I’m trying to store additional metadata like content-type and etc at extended attribute.

 

My client code are like

 

fd = glusterfs_open( path );

glusterfs_write( fd, data, data_length );

glusterfs_close( fd );       //------

glusterfs_setxattr( path, attr_name, attr_value, value_length,0 );

 

My concern is that above client code runs on multiple machines and multi-threaded.

In higher concurrency, client A could write content, client B write content, client B write its attribute then client A write its attribute.

So to speak, file content comes from client B but attribute comes from client A.

 

If I use a lock server, I can guarantee data integrity. But is there a simpler way to store extended attributes at an atomic environment?

I see another function, glusterfs_fsetxattr which accepts open glusterfs_file descriptor. If I rewrite as following, can I guarantee the integrity?

 

fd = glusterfs_open( path );

glusterfs_write( fd, data, data_length );

glusterfs_fsetxattr( fd, attr_name, attr_value, value_length,0 );

glusterfs_close( fd );   

 

 

Thanks

 

DongMin Yu

 

HOSTWAY IDC Corp. / R&D Principal Researcher

TEL. +822 2105 6037

FAX. +822 2105 6019

CELL. +8216 2086 1357

EMAIL: address@hidden

Website: http://www.hostway.com

 

NOTICE:  This email and any file transmitted are confidential and/or legally privileged and intended only for the person(s) directly addressed.  If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited.  If you have received this email in error, please notify the sender immediately and permanently delete the email and files, if any.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]