Re: [LSF/MM ATTEND] Stackable Union Filesystem Implementation

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

 



>> One of the big problems was that too many copyups were made on the
>> read-write file system. So we decided to implement an union file
>> system designed for diskless systems, with the following
>> functionalities:
>>
>> 1. union between only one read-only and one read-write file systems
>>
>> 2. if only the file metadata are modified, then do not
>> copy the whole file on the read-write files system but
>> only the metadata (stored with a file named as the file
>> itself prefixed by '.me.')
>   So do you do anything special at CERN so that metadata is often modified
> without data being changed? Because there are only two operations where I
> can imagine this to be useful:
> 1) atime update - but you better turn atime off for unioned filesystem
>    anyway.
> 2) xattr update
>
As already mentioned that the issue that we were facing was that "too
many copyups were made on the  read-write file system".
Writes to a file system in a  unioning file system will produce many
duplicated blocks in memory since it uses a stackable filesystem
approach so response time for a particular operation is also a
concern.

Regards,
Saket Sinha
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux