There is no need but it could happen accidentally and I think it should be protect or should not be permissible.
On Mon, Apr 17, 2017 at 8:36 AM, Atin Mukherjee <amukh...@redhat.com> wrote: > > > On Mon, 17 Apr 2017 at 08:23, ABHISHEK PALIWAL <abhishpali...@gmail.com> > wrote: > >> Hi All, >> >> Here we have below steps to reproduce the issue >> >> Reproduction steps: >> >> >> >> root@128:~# gluster volume create brick 128.224.95.140:/tmp/brick force >> ----- create the gluster volume >> >> volume create: brick: success: please start the volume to access data >> >> root@128:~# gluster volume set brick nfs.disable true >> >> volume set: success >> >> root@128:~# gluster volume start brick >> >> volume start: brick: success >> >> root@128:~# gluster volume info >> >> Volume Name: brick >> >> Type: Distribute >> >> Volume ID: a59b479a-2b21-426d-962a-79d6d294fee3 >> >> Status: Started >> >> Number of Bricks: 1 >> >> Transport-type: tcp >> >> Bricks: >> >> Brick1: 128.224.95.140:/tmp/brick >> >> Options Reconfigured: >> >> nfs.disable: true >> >> performance.readdir-ahead: on >> >> root@128:~# gluster volume status >> >> Status of volume: brick >> >> Gluster process TCP Port RDMA Port Online Pid >> >> ------------------------------------------------------------ >> ------------------ >> >> Brick 128.224.95.140:/tmp/brick 49155 0 Y 768 >> >> >> >> Task Status of Volume brick >> >> ------------------------------------------------------------ >> ------------------ >> >> There are no active volume tasks >> >> >> >> root@128:~# mount -t glusterfs 128.224.95.140:/brick gluster/ >> >> root@128:~# cd gluster/ >> >> root@128:~/gluster# du -sh >> >> 0 . >> >> root@128:~/gluster# mkdir -p test/ >> >> root@128:~/gluster# cp ~/tmp.file gluster/ >> >> root@128:~/gluster# cp tmp.file test >> >> root@128:~/gluster# cd /tmp/brick >> >> root@128:/tmp/brick# du -sh * >> >> 768K test >> >> 768K tmp.file >> >> root@128:/tmp/brick# rm -rf test --------- delete the test directory and >> data in the server side, not reasonable >> >> root@128:/tmp/brick# ls >> >> tmp.file >> >> root@128:/tmp/brick# du -sh * >> >> 768K tmp.file >> >> *root@128:/tmp/brick# du -sh (brick dir)* >> >> *1.6M .* >> >> root@128:/tmp/brick# cd .glusterfs/ >> >> root@128:/tmp/brick/.glusterfs# du -sh * >> >> 0 00 >> >> 0 2a >> >> 0 bb >> >> 768K c8 >> >> 0 c9 >> >> 0 changelogs >> >> 768K d0 >> >> 4.0K health_check >> >> 0 indices >> >> 0 landfill >> >> *root@128:/tmp/brick/.glusterfs# du -sh (.glusterfs dir)* >> >> *1.6M .* >> >> root@128:/tmp/brick# cd ~/gluster >> >> root@128:~/gluster# ls >> >> tmp.file >> >> *root@128:~/gluster# du -sh * (Mount dir)* >> >> *768K tmp.file* >> >> >> >> In the reproduce steps, we delete the test directory in the server side, >> not in the client side. I think this delete operation is not reasonable. >> Please ask the customer to check whether they do this unreasonable >> operation. >> > > What's the need of deleting data from backend (i.e bricks) directly? > > >> *It seems while deleting the data from BRICK, metadata will not deleted >> from .glusterfs directory.* >> >> >> *I don't know whether it is a bug of limitations, please let us know >> about this?* >> >> >> Regards, >> >> Abhishek >> >> >> On Thu, Apr 13, 2017 at 2:29 PM, Pranith Kumar Karampuri < >> pkara...@redhat.com> wrote: >> >>> >>> >>> On Thu, Apr 13, 2017 at 12:19 PM, ABHISHEK PALIWAL < >>> abhishpali...@gmail.com> wrote: >>> >>>> yes it is ext4. but what is the impact of this. >>>> >>> >>> Did you have a lot of data before and you deleted all that data? ext4 if >>> I remember correctly doesn't decrease size of directory once it expands it. >>> So in ext4 inside a directory if you create lots and lots of files and >>> delete them all, the directory size would increase at the time of creation >>> but won't decrease after deletion. I don't have any system with ext4 at the >>> moment to test it now. This is something we faced 5-6 years back but not >>> sure if it is fixed in ext4 in the latest releases. >>> >>> >>>> >>>> On Thu, Apr 13, 2017 at 9:26 AM, Pranith Kumar Karampuri < >>>> pkara...@redhat.com> wrote: >>>> >>>>> Yes >>>>> >>>>> On Thu, Apr 13, 2017 at 8:21 AM, ABHISHEK PALIWAL < >>>>> abhishpali...@gmail.com> wrote: >>>>> >>>>>> Means the fs where this brick has been created? >>>>>> On Apr 13, 2017 8:19 AM, "Pranith Kumar Karampuri" < >>>>>> pkara...@redhat.com> wrote: >>>>>> >>>>>>> Is your backend filesystem ext4? >>>>>>> >>>>>>> On Thu, Apr 13, 2017 at 6:29 AM, ABHISHEK PALIWAL < >>>>>>> abhishpali...@gmail.com> wrote: >>>>>>> >>>>>>>> No,we are not using sharding >>>>>>>> On Apr 12, 2017 7:29 PM, "Alessandro Briosi" <a...@metalit.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Il 12/04/2017 14:16, ABHISHEK PALIWAL ha scritto: >>>>>>>>> >>>>>>>>> I have did more investigation and find out that brick dir size is >>>>>>>>> equivalent to gluster mount point but .glusterfs having too much >>>>>>>>> difference >>>>>>>>> >>>>>>>>> >>>>>>>>> You are probably using sharding? >>>>>>>>> >>>>>>>>> >>>>>>>>> Buon lavoro. >>>>>>>>> *Alessandro Briosi* >>>>>>>>> >>>>>>>>> *METAL.it Nord S.r.l.* >>>>>>>>> Via Maioliche 57/C - 38068 Rovereto (TN) >>>>>>>>> Tel.+39.0464.430130 - Fax +39.0464.437393 >>>>>>>>> www.metalit.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Gluster-users mailing list >>>>>>>> gluster-us...@gluster.org >>>>>>>> http://lists.gluster.org/mailman/listinfo/gluster-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Pranith >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Pranith >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> >>>> Regards >>>> Abhishek Paliwal >>>> >>> >>> >>> >>> -- >>> Pranith >>> >> >> >> >> -- >> >> >> >> >> Regards >> Abhishek Paliwal >> _______________________________________________ >> Gluster-users mailing list >> gluster-us...@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-users > > -- > - Atin (atinm) > -- Regards Abhishek Paliwal
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel