Re: [Gluster-devel] Readdir d_off encoding
On Mon, Dec 22, 2014 at 02:04:37PM -0500, J. Bruce Fields wrote: > It'd also be nice to see any proposals for a completely correct > solution, even if it's something that will take a while. All I can > think of is protocol extensions, but that's just what I know. I tried to think a little about this over the holidays: say we could scrap NFS and start from scratch, what would we do?: - larger NFS readdir cookies: if NFS cookies were 128 bits, then gluster could stick the filesystem's offset in the lower 64 bits and its own data in the upper 64 bits. This doesn't work if anyone else does this, though: if we change to 128 bits here then people may eventually want to do the same thing to filesystem and systemcall interfaces too and then we're back at square one. If people want to be able to stack arbitrary readdir implementations the we can't really choose a fixed size limit any more. - stateful readdir: make clients open the directory, read through it from start to finish, then close it. That's all clients really want to do anyway--they don't need to seek back to offsets returned arbitrarily long ago. However, they do need to be able to resend the last readdir request in case the reply was lost, and they do need to be able to resume reading a directory after a server reboot. So I think that would still leave gluster needing to keep a (persistent, on-disk) cache mapping the NFS cookies it hands out to the offsets in the backend directories. The difference is just that it would only have to cache the small number of entries that are in use by current readdirs in progress instead of potentially having to keep them all forever. I don't know, does that help much? --b. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] REMINDER: Weekly Gluster Community meeting today at 12:00 UTC
On 01/07/2015 04:35 PM, Vijay Bellur wrote: Hi all, In about 60 minutes from now we will have the regular weekly Gluster Community meeting. Meeting details: - location: #gluster-meeting on Freenode IRC - date: every Wednesday - time: 7:00 EST, 12:00 UTC, 13:00 CET, 17:30 IST (in your terminal, run: date -d "12:00 UTC") - agenda:https://public.pad.fsfe.org/p/gluster-community-meetings Currently the following items are listed: * Roll Call * Status of last weeks action items * GlusterFS 3.6 * GlusterFS 3.5 * GlusterFS 3.4 * GlusterFS Next * Open Floor Meeting minutes & log from today available at [1] and [2]. Thanks, Vijay [1] http://meetbot.fedoraproject.org/gluster-meeting/2015-01-07/gluster-meeting.2015-01-07-12.02.html [2] http://meetbot.fedoraproject.org/gluster-meeting/2015-01-07/gluster-meeting.2015-01-07-12.02.log.html ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Some reviews/merges needed
Hi, I've some patches pending to be reviewed/merged. If someone has some time to look at it I'll appreciate it: http://review.gluster.org/8434/ A memory leak, though current code shouldn't trigger it. It's been also reviewed. Only merge needed. http://review.gluster.org/9031/ (master) http://review.gluster.org/9032/ (release-3.6) Fixes an spurious error that can cause crashes. Not sure if this has been addressed in another patch. If so I'll abandon it, otherwise this needs to be reviewed and merged. http://review.gluster.org/9079/ This fix is for master. The corresponding backport to release-3.6 has already been merged. It has a +1. http://review.gluster.org/9407/ Fixes a bug in ec that could cause EIO errors when some brick is damaged or replaced. I'll backport it to 3.6 once merged. http://review.gluster.org/9316/ This is a new timer implementation that avoids some races present in the current implementation and adds flexibility. It's still a work in progress, but any feedback on public interfaces and internal structure will be welcome. Thanks for your time, Xavi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] [Gluster-users] REMINDER: Weekly Gluster Community meeting today at 12:00 UTC
Hi all, In about 60 minutes from now we will have the regular weekly Gluster Community meeting. Meeting details: - location: #gluster-meeting on Freenode IRC - date: every Wednesday - time: 7:00 EST, 12:00 UTC, 13:00 CET, 17:30 IST (in your terminal, run: date -d "12:00 UTC") - agenda:https://public.pad.fsfe.org/p/gluster-community-meetings Currently the following items are listed: * Roll Call * Status of last weeks action items * GlusterFS 3.6 * GlusterFS 3.5 * GlusterFS 3.4 * GlusterFS Next * Open Floor The last topic has space for additions. If you have a suitable topic to discuss, please add it to the agenda. Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] bit rot
On 01/07/2015 12:48 PM, Raghavendra Bhat wrote: Hi, As per the design dicussion it was mentioned that, there will be one BitD running per node which will take care of all the bricks of all the volumes running on that node. But, here once thing that becomes important is doing graph changes for the BitD process upon enabling/disabling of bit-rot functionality for the volumes. With more and more graph changes, there is more chance of BitD running out of memory (as of now the older graphs in glusterfs are not cleaned up). Both NFS and SHD processes have same problem, but upon graph switch the daemons are restarted. Is there any reason this approach is not taken? Pranith So for now it will be better to have one BitD per volume per node. In this case, there will not be graph changes in BitD. It will be started for a volume upon enabling bit-rot functionality for that volume and will be brought down when bit-rot is disabled for a volume. Regards, Raghavendra Bhat ___ 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
