On Mon, Jul 23, 2018 at 8:21 PM, Gudrun Mareike Amedick < g.amed...@uni-luebeck.de> wrote:
> Hi, > > we're planning a dispersed volume with at least 50 project directories. > Each of those has its own quota ranging between 0.1TB and 200TB. Comparing > XFS > project quotas over several servers and bricks to make sure their total > matches the desired value doesn't really sound practical. It would probably > be > possible to create and maintain 50 volumes and more, but it doesn't seem > to be a desirable solution. The quotas aren't fixed and resizing a volume is > not as trivial as changing the quota. > > Quota was in the past and still is a very comfortable way to solve this. > > But what is the new recommended way for such a setting when the quota is > going to be deprecated? > > Thanks for the feedback. Helps us to prioritize. Will get back on this. -Amar > Kind regards > > Gudrun > Am Donnerstag, den 19.07.2018, 12:26 +0530 schrieb Amar Tumballi: > > Hi all, > > > > Over last 12 years of Gluster, we have developed many features, and > continue to support most of it till now. But along the way, we have figured > out > > better methods of doing things. Also we are not actively maintaining > some of these features. > > > > We are now thinking of cleaning up some of these ‘unsupported’ features, > and mark them as ‘SunSet’ (i.e., would be totally taken out of codebase in > > following releases) in next upcoming release, v5.0. The release notes > will provide options for smoothly migrating to the supported configurations. > > > > If you are using any of these features, do let us know, so that we can > help you with ‘migration’.. Also, we are happy to guide new developers to > > work on those components which are not actively being maintained by > current set of developers. > > > > List of features hitting sunset: > > > > ‘cluster/stripe’ translator: > > > > This translator was developed very early in the evolution of GlusterFS, > and addressed one of the very common question of Distributed FS, which is > > “What happens if one of my file is bigger than the available brick. Say, > I have 2 TB hard drive, exported in glusterfs, my file is 3 TB”. While it > > solved the purpose, it was very hard to handle failure scenarios, and > give a real good experience to our users with this feature. Over the time, > > Gluster solved the problem with it’s ‘Shard’ feature, which solves the > problem in much better way, and provides much better solution with existing > > well supported stack. Hence the proposal for Deprecation. > > > > If you are using this feature, then do write to us, as it needs a proper > migration from existing volume to a new full supported volume type before > > you upgrade. > > > > ‘storage/bd’ translator: > > > > This feature got into the code base 5 years back with this patch[1]. > Plan was to use a block device directly as a brick, which would help to > handle > > disk-image storage much easily in glusterfs. > > > > As the feature is not getting more contribution, and we are not seeing > any user traction on this, would like to propose for Deprecation. > > > > If you are using the feature, plan to move to a supported gluster volume > configuration, and have your setup ‘supported’ before upgrading to your new > > gluster version. > > > > ‘RDMA’ transport support: > > > > Gluster started supporting RDMA while ib-verbs was still new, and very > high-end infra around that time were using Infiniband. Engineers did work > > with Mellanox, and got the technology into GlusterFS for better data > migration, data copy. While current day kernels support very good speed with > > IPoIB module itself, and there are no more bandwidth for experts in > these area to maintain the feature, we recommend migrating over to TCP (IP > > based) network for your volume. > > > > If you are successfully using RDMA transport, do get in touch with us to > prioritize the migration plan for your volume. Plan is to work on this > > after the release, so by version 6.0, we will have a cleaner transport > code, which just needs to support one type. > > > > ‘Tiering’ feature > > > > Gluster’s tiering feature which was planned to be providing an option to > keep your ‘hot’ data in different location than your cold data, so one can > > get better performance. While we saw some users for the feature, it > needs much more attention to be completely bug free. At the time, we are not > > having any active maintainers for the feature, and hence suggesting to > take it out of the ‘supported’ tag. > > > > If you are willing to take it up, and maintain it, do let us know, and > we are happy to assist you. > > > > If you are already using tiering feature, before upgrading, make sure to > do gluster volume tier detach all the bricks before upgrading to next > > release. Also, we recommend you to use features like dmcache on your LVM > setup to get best performance from bricks. > > > > ‘Quota’ > > > > This is a call out for ‘Quota’ feature, to let you all know that it will > be ‘no new development’ state. While this feature is ‘actively’ in use by > > many people, the challenges we have in accounting mechanisms involved, > has made it hard to achieve good performance with the feature. Also, the > > amount of extended attribute get/set operations while using the feature > is not very ideal. Hence we recommend our users to move towards setting > > quota on backend bricks directly (ie, XFS project quota), or to use > different volumes for different directories etc. > > > > As the feature wouldn’t be deprecated immediately, the feature doesn’t > need a migration plan when you upgrade to newer version, but if you are a > new > > user, we wouldn’t recommend setting quota feature. By the release dates, > we will be publishing our best alternatives guide for gluster’s current > > quota feature. > > > > Note that if you want to contribute to the feature, we have project > quota based issue open[2] Happy to get contributions, and help in getting a > > newer approach to Quota. > > > > > > These are our set of initial features which we propose to take out of > ‘fully’ supported features. While we are in the process of making the > > user/developer experience of the project much better with providing well > maintained codebase, we may come up with few more set of features which we > > may possibly consider to move out of support, and hence keep watching > this space. > > > > [1] - http://review.gluster.org/4809 > > > > [2] - https://github.com/gluster/glusterfs/issues/184 > > > > > > Regards, > > > > Vijay, Shyam, Amar > > > > > > _______________________________________________ > > Gluster-users mailing list > > Gluster-users@gluster.org > > https://lists.gluster.org/mailman/listinfo/gluster-users -- Amar Tumballi (amarts)
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-users