> No, not really. In fact every other comment about glusterfs(d) reads like > "this is a standard application regarding the fs, therefore it cannot be > responsible for problem A or bug B". Now, if it is to be judged as one of many > applications on the one hand, then it should be able to cope with situations > that every standard application can cope with either - other applications > using the same fs. glusterfs is a standard application regarding the fs, therefore it cannot be responsible for problems showing up in the kernel. glusterfs is not expected to work properly if you modify the backend export directory directly bypassing the mountpoint. This is the baseline premise for using glusterfs. > _The_ advantage of the whole glusterfs concept is exactly that it is _no_ fs > with a own and special disk layout. It (should) run(s) on top of an existing > fs that can be used just like a fs may be used - including backup (with rsync > or whatever), restore and file operations of any kind. glusterfs uses a disk based filesystem as its backend. This in no way implies that it can share the backend with other applications and work without problems. glusterfs needs _exclusive_ access to this export directory. That is how it is designed to work. If you backup one backend, you can restor it only as that very backend. What you are trying is to do is use one backend as another subvolumes backend. If you expect copying over the backend by skipping the xattrs, while modifying those very files from the mountpoint to just work, then the expectation is improperly set. Please copy in all your content only from the mountpoint. > If subvolumes are indeed closed storages then they would be in no way > different than nbd, enbd, whatever-nbd. For various reasons we don't want > these solutions. GlusterFS is surely not a solution where you can freely modify the backend directly. For proper operation of the filesystem, the only supported mode of usage is through the mountpoint. Whatever modification you do with the backend is done at your own risk. Avati
