[Gluster-devel] Is it possible to turn an existing filesystem (with data) into a GlusterFS brick ?
L.S., I was wondering if it would be possible to turn an existing filesystem with data (ext4 with files en dirs) into a GlusterFS brick ? I can't find much info about it except the following remark at [1] which seems to indicate it is not possible yet: Data import tool Create a tool which will allow importing already existing data in the brick directories into the gluster volume. This is most likely going to be a special rebalance process. So that would mean i would always have to: - first create an GlusterFS brick on an empty filesystem - after that copy all the data into the mounted GlusterFS brick - never ever copy something into the filesystem (or manipulate it otherwise) used as a GlusterFS brick directly (without going through a GlusterFS client mount) because there is no checking / healing between GlusterFS's view on the data and the data in the underlying brick filesystem ? Is this a correct view ? -- Sander Eikelenboom [1] https://gluster.readthedocs.io/en/latest/Developer-guide/Projects/ ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Is it possible to turn an existing filesystem (with data) into a GlusterFS brick ?
Friday, November 11, 2016, 3:47:26 PM, you wrote: > Reposting to gluster-users as this is not development related. I posted @devel, because in the most likely case of "No", it could become a feature request ;-) -- Sander > On November 11, 2016 6:32:49 AM PST, Pranith Kumar Karampuri > wrote: > > On Fri, Nov 11, 2016 at 8:01 PM, Pranith Kumar Karampuri > wrote: > On Fri, Nov 11, 2016 at 6:24 PM, Saravanakumar Arumugam > wrote: > > On 11/11/2016 06:03 PM, Sander Eikelenboom wrote: > > L.S., > > I was wondering if it would be possible to turn an existing filesystem with > data > (ext4 with files en dirs) into a GlusterFS brick ? > > It is not possible, at least I am not aware about any such solution yet. > > > I can't find much info about it except the following remark at [1] which > seems > to indicate it is not possible yet: > > Data import tool > > Create a tool which will allow importing already existing data in > the brick > directories into the gluster volume. > This is most likely going to be a special rebalance process. > > So that would mean i would always have to: > - first create an GlusterFS brick on an empty filesystem > - after that copy all the data into the mounted GlusterFS brick > - never ever copy something into the filesystem (or manipulate it otherwise) > used as a GlusterFS brick directly (without going through a GlusterFS > client mount) > > because there is no checking / healing between GlusterFS's view on the data > and the data in the > underlying brick filesystem ? > > Is this a correct view ? > > > you are right ! > Once the data is copied into Gluster, it internally creates meta-data about > data(file/dir). > Unless you copy it via Gluster mount point, it is NOT possible to create > such meta-data. > No, it is possible. You just need to be a bit creative. > Could you let me know how many such bricks you have which you want to convert > to glusterfs. It seems like you want replication as well. So if you give me > all this information. With your help may be we can at least come up with a > document on how this can be done. > Once the import is complete, whatever you are saying about not touching the > brick directly and doing everything from the mount point holds. But we can > definitely convert an existing ext4 directory structure into a volume. > > > > Thanks, > Saravana > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Is it possible to turn an existing filesystem (with data) into a GlusterFS brick ?
Friday, November 11, 2016, 3:31:05 PM, you wrote: > On Fri, Nov 11, 2016 at 6:24 PM, Saravanakumar Arumugam > wrote: > > On 11/11/2016 06:03 PM, Sander Eikelenboom wrote: > > L.S., > > I was wondering if it would be possible to turn an existing filesystem with > data > (ext4 with files en dirs) into a GlusterFS brick ? > > It is not possible, at least I am not aware about any such solution yet. > > > I can't find much info about it except the following remark at [1] which > seems > to indicate it is not possible yet: > > Data import tool > > Create a tool which will allow importing already existing data in > the brick > directories into the gluster volume. > This is most likely going to be a special rebalance process. > > So that would mean i would always have to: > - first create an GlusterFS brick on an empty filesystem > - after that copy all the data into the mounted GlusterFS brick > - never ever copy something into the filesystem (or manipulate it otherwise) > used as a GlusterFS brick directly (without going through a GlusterFS > client mount) > > because there is no checking / healing between GlusterFS's view on the data > and the data in the > underlying brick filesystem ? > > Is this a correct view ? > > > you are right ! > Once the data is copied into Gluster, it internally creates meta-data about > data(file/dir). > Unless you copy it via Gluster mount point, it is NOT possible to create > such meta-data. > No, it is possible. You just need to be a bit creative. > Could you let me know how many such bricks you have which you want to convert > to glusterfs. It seems like you want replication as well. So if you give me > all this information. With your help may be we can at least come up with a > document on how this can be done. Hi Saravanakumar, Thanks for your swift reply. Well the most achievable workflow to me seems: 1) Start with one filesystem already filled with data 2) Let glusterfs create a glusterfs volume with only that FS as brick 3) Have some tool scan that volume/brick and check / compare the filesystem data with glusterfs metadata. And have a option to repair / generate the missing (or wrong) glusterfs metadata based on the filesystem data 4) If whished for add other (empty) bricks 5) Start the gluster volume and/or healing / replication What seems to be missing is a tool for (3). I think that could also be useful when trying to recover from total disaster (where glusterfs bricks are brokedown and you end up with lose bricks. At least you would be able to keep the filesystem data, remove the .glusterfs metadata dir. Then you can use low level filesystem tools and rebuild your glusterfs volume and brick inplace, instead of to move it out which could be difficult datasize wise. -- Sander > > > Thanks, > Saravana > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Is it possible to turn an existing filesystem (with data) into a GlusterFS brick ?
Friday, November 11, 2016, 4:28:36 PM, you wrote: > Feature requests to in Bugzilla anyway. > Create your volume with the populated brick as brick one. Start it and "heal > full". gluster> volume create testvolume transport tcp gluster> 192.168.1.1:/mnt/glusterfs/testdata/brick force volume create: private: success: please start the volume to access data gluster> volume heal testvolume full Launching heal operation to perform full self heal on volume testvolume has been unsuccessful on bricks that are down. Please check if all brick processes are running. gluster> volume start testvolume volume start: testvolume: success gluster> volume heal testvolume full Launching heal operation to perform full self heal on volume testvolume has been unsuccessful on bricks that are down. Please check if all brick processes are running. So it seems healing only works on volumes with 2 or more bricks. So that doesn't seem to workout very well. -- Sander > On November 11, 2016 7:12:03 AM PST, Sander Eikelenboom > wrote: > > Friday, November 11, 2016, 3:47:26 PM, you wrote: > Reposting to gluster-users as this is not development related. > I posted @devel, because in the most likely case of "No", it could become a > feature request ;-) > -- > Sander > On November 11, 2016 6:32:49 AM PST, Pranith Kumar Karampuri > wrote: > > On Fri, Nov 11, 2016 at 8:01 PM, Pranith Kumar Karampuri > wrote: > On Fri, Nov 11, 2016 at 6:24 PM, Saravanakumar Arumugam > wrote: > > On 11/11/2016 06:03 PM, Sander Eikelenboom wrote: > > L.S., > > I was wondering if it would be possible to turn an existing filesystem with > data > (ext4 with files en dirs) into a GlusterFS brick ? > > It is not possible, at least I am not aware about any such solution yet. > > > I can't find much info about it except the following remark at [1] which > seems > to indicate it is not possible yet: > > Data import tool > > Create a tool which will allow importing already existing data in > the brick > directories into the gluster volume. > This is most likely going to be a special rebalance process. > > So that would mean i would always have to: > - first create an GlusterFS brick on an empty filesystem > - after that copy all the data into the mounted GlusterFS brick > - never ever copy something into the filesystem (or manipulate it otherwise) > used as a GlusterFS brick directly (without going through a GlusterFS > client mount) > > because there is no checking / healing between GlusterFS's view on the data > and the data in the > underlying brick filesystem ? > > Is this a correct view ? > > > you are right ! > Once the data is copied into Gluster, it internally creates meta-data about > data(file/dir). > Unless you copy it via Gluster mount point, it is NOT possible to create > such meta-data. > No, it is possible. You just need to be a bit creative. > Could you let me know how many such bricks you have which you want to > convert to glusterfs. It seems like you want replication as well. So if you > give me all this information. With your help may be we can at least come up > with a document on how this can be done. > Once the import is complete, whatever you are saying about not touching the > brick directly and doing everything from the mount point holds. But we can > definitely convert an existing ext4 directory structure into a volume. > > > > Thanks, > Saravana > > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Linux 5.2-RC regression bisected, mounting glusterfs volumes fails after commit: fuse: require /dev/fuse reads to have enough buffer capacity
L.S., While testing a linux 5.2 kernel I noticed it fails to mount my glusterfs volumes. It repeatedly fails with: [2019-06-11 09:15:27.106946] W [fuse-bridge.c:4993:fuse_thread_proc] 0-glusterfs-fuse: read from /dev/fuse returned -1 (Invalid argument) [2019-06-11 09:15:27.106955] W [fuse-bridge.c:4993:fuse_thread_proc] 0-glusterfs-fuse: read from /dev/fuse returned -1 (Invalid argument) [2019-06-11 09:15:27.106963] W [fuse-bridge.c:4993:fuse_thread_proc] 0-glusterfs-fuse: read from /dev/fuse returned -1 (Invalid argument) [2019-06-11 09:15:27.106971] W [fuse-bridge.c:4993:fuse_thread_proc] 0-glusterfs-fuse: read from /dev/fuse returned -1 (Invalid argument) etc. etc. Bisecting turned up as culprit: commit d4b13963f217dd947da5c0cabd1569e914d21699: fuse: require /dev/fuse reads to have enough buffer capacity The glusterfs version i'm using is from Debian stable: ii glusterfs-client3.8.8-1 amd64 clustered file-system (client package) ii glusterfs-common3.8.8-1 amd64 GlusterFS common libraries and translator modules A 5.1.* kernel works fine, as does a 5.2-rc4 kernel with said commit reverted. -- Sander
Re: [Gluster-devel] [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)
On 12/06/2019 13:25, Kirill Smelkov wrote: > On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote: >> On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov wrote: >> >>> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for >>> header room change be accepted? >> >> Yes, next cycle. For 4.2 I'll just push the revert. > > Thanks Miklos. Please consider queuing the following patch for 5.3. > Sander, could you please confirm that glusterfs is not broken with this > version of the check? > > Thanks beforehand, > Kirill Sure will give it a spin this evening and report back. -- Sander ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)
On 12/06/2019 13:25, Kirill Smelkov wrote: > On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote: >> On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov wrote: >> >>> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for >>> header room change be accepted? >> >> Yes, next cycle. For 4.2 I'll just push the revert. > > Thanks Miklos. Please consider queuing the following patch for 5.3. > Sander, could you please confirm that glusterfs is not broken with this > version of the check? > > Thanks beforehand, > Kirill Hmm unfortunately it doesn't build, see below. -- Sander In file included from ./include/linux/list.h:9:0, from ./include/linux/wait.h:7, from ./include/linux/wait_bit.h:8, from ./include/linux/fs.h:6, from fs/fuse/fuse_i.h:17, from fs/fuse/dev.c:9: fs/fuse/dev.c: In function ‘fuse_dev_do_read’: fs/fuse/dev.c:1336:14: error: ‘fuse_in_header’ undeclared (first use in this function) sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write)) ^ ./include/linux/kernel.h:818:40: note: in definition of macro ‘__typecheck’ (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^ ./include/linux/kernel.h:842:24: note: in expansion of macro ‘__safe_cmp’ __builtin_choose_expr(__safe_cmp(x, y), \ ^~ ./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’ #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >) ^ fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, ^ fs/fuse/dev.c:1336:14: note: each undeclared identifier is reported only once for each function it appears in sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write)) ^ ./include/linux/kernel.h:818:40: note: in definition of macro ‘__typecheck’ (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^ ./include/linux/kernel.h:842:24: note: in expansion of macro ‘__safe_cmp’ __builtin_choose_expr(__safe_cmp(x, y), \ ^~ ./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’ #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >) ^ fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, ^ fs/fuse/dev.c:1336:39: error: ‘fuse_write_in’ undeclared (first use in this function) sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write)) ^ ./include/linux/kernel.h:818:40: note: in definition of macro ‘__typecheck’ (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^ ./include/linux/kernel.h:842:24: note: in expansion of macro ‘__safe_cmp’ __builtin_choose_expr(__safe_cmp(x, y), \ ^~ ./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’ #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >) ^ fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, ^ ./include/linux/kernel.h:842:2: error: first argument to ‘__builtin_choose_expr’ not a constant __builtin_choose_expr(__safe_cmp(x, y), \ ^ ./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’ #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >) ^ fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, ^ scripts/Makefile.build:278: recipe for target 'fs/fuse/dev.o' failed make[3]: *** [fs/fuse/dev.o] Error 1 scripts/Makefile.build:489: recipe for target 'fs/fuse' failed make[2]: *** [fs/fuse] Error 2
Re: [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)
On 12/06/2019 16:12, Kirill Smelkov wrote: > On Wed, Jun 12, 2019 at 03:03:49PM +0200, Sander Eikelenboom wrote: >> On 12/06/2019 13:25, Kirill Smelkov wrote: >>> On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote: >>>> On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov wrote: >>>> >>>>> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for >>>>> header room change be accepted? >>>> >>>> Yes, next cycle. For 4.2 I'll just push the revert. >>> >>> Thanks Miklos. Please consider queuing the following patch for 5.3. >>> Sander, could you please confirm that glusterfs is not broken with this >>> version of the check? >>> >>> Thanks beforehand, >>> Kirill >> >> >> Hmm unfortunately it doesn't build, see below. >> [...] >> fs/fuse/dev.c:1336:14: error: ‘fuse_in_header’ undeclared (first use in this >> function) >>sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write)) > > Sorry, my bad, it was missing "struct" before fuse_in_header. I > originally compile-tested the patch with `make -j4`, was distracted onto > other topic and did not see the error after returning due to long tail > of successful CC lines. Apologize for the inconvenience. Below is a > fixed patch that was both compile-tested and runtime-tested with my FUSE > workloads (non-glusterfs). > > Kirill > Just tested and it works for me, thanks ! -- Sander
