Re: [Gluster-users] Self healing metadata info
Patric, Thank you very much. I will do some testing on the index file, the document is very helpful to understand the technique and the robustness of self healing. JPro On Friday, January 25, 2013, Patric Uebele wrote: > Hi JPro, > > perhaps the attached doc does explain it a bit. > > Best regards, > > Patric > > On Fri, 2013-01-25 at 01:26 -0500, Java Pro wrote: > > Hi, > > > > > > If a brick is down and comes back up later, how does Glusterfs know > > which files in this brick need to be 'self-healed'? > > > > > > Since the metadata of whether to 'heal' is stored as an xattr in a > > replica on other bricks. Does Glusterfs scan these files on the other > > bricks to see if one is "accusing" its replica and therefore need to > > "heal" its replica? > > > > > > In short, does Glusterfs keep a record of "writes" to a brick when a > > brick is down and apply these "writes" to the brick when its backup? > > > > > > > > > > Thanks, > > JPro > > > > ___ > > Gluster-users mailing list > > Gluster-users@gluster.org > > http://supercolony.gluster.org/mailman/listinfo/gluster-users > > -- > Patric Uebele > Solution Architect Storage > > Red Hat GmbH > Technopark II, Haus C > Werner-von-Siemens-Ring 14 > 85630 Grasbrunn > Germany > > Office:+49 89 205071-162 > Cell: +49 172 669 14 99 > mailto:patric.ueb...@redhat.com > > gpg keyid: 48E64CC1 > gpg fingerprint: C63E 6320 A03B 4410 D208 4EE7 12FC D0E6 48E6 4CC1 > > > Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn > Handelsregister: Amtsgericht Muenchen HRB 153243 > Geschaeftsfuehrer: Mark Hegarty, Charlie Peters, Michael Cunningham, > Charles Cachera > ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
[Gluster-users] mixing brick sizes and increasing replica counts
2 questions I posed to ##gluster yesterday, wanted to see if anyone on teh mailing list had thoughts: #1: Mixing brick sizes in a distributed replicated volume: We have a 5x2 dist-rep volume, with bricks that are all 28TB(1 per node). Our building block has been Dell R515's w/ 12 3TB drives. Now it sounds like we might actually be getting some of the same systems, but w/ 4TB drives. So, instead of ~28TB usable, we would end up w/ ~40TB usable. Assuming we added these in pairs, for the replica count = 2, to turn this into a 6x2, or a 7x2, what would happen? Best case:After a rebalance, a slightly higher % of files (from the rebalance, as well as net new data), would end up on the larger brick replica pairs "meh" case: Gluster doesn't know/care about the size, and therefor only the smallest brick size will even be used in full, meaning 12TB per "big brick" would essentially never be used.. The "best case", doesn't seem that unreasonable to me, but I've got a suspicion the gluster isn't really aware of the brick sizes so the "meh" case seems more likely ...any official work on this? Perhaps a feature request? Question #2: Same 5x2 dist-rep volume, if we got another 5 bricks (lets assume same size), and wanted to turn this into a 5x3 volume, what would be involved? I found this: http://community.gluster.org/q/expand-a-replica-volume/ but still wasn't 100% clear. Could I just add the bricks and specify the new replica count when i add them? What about deleting the volume, and recreating and letting gluster heal/balance to the new "empty" set of nodes? Any insight, especially form experience, anyone has with either of these will be a huge help! Thanks! -- Matthew Nicholson matthew_nichol...@harvard.edu Research Computing Specialist FAS Research Computing Harvard University ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Self healing metadata info
Hi Patric, your paper shows clearly you are infected by the fs-programmer-virus :-) Noone else would give you tags/gfids/inode nums of a file inside a logfile instead of the full true filename, simply because looking at the logfile days/months/years later you know exactly nothing about the files affected by e.g. a self heal. Can you explain why a fs cannot give the user/admin the files' name currently fiddling around in a logfile instead of a cryptic number? For the completeness in split-brain case I would probably do a gluster volume heal prefer command which prefers the files' copy on and triggers the self-heal for that file. As an addition you would be able to allow gluster volume heal prefer (without filename) to generally prefer files on and trigger self-heal for all files. There are cases where admins do not care about the actual copy but more about the accessibility of the file per se. Everything is easy around self-heal/splitbrain if you deal with 5 files affected. But dealing with 5000 files instead shows you that no admin is probably able to look at every single file. So he should be able to choose some general option like gluster volume heal prefer where can be: (as above) "length", choose longest file always "date", choose latest file date always "delete", simply remove all affected files ... Regards, Stephan On Fri, 25 Jan 2013 10:11:07 +0100 Patric Uebele wrote: > Hi JPro, > > perhaps the attached doc does explain it a bit. > > Best regards, > > Patric > > On Fri, 2013-01-25 at 01:26 -0500, Java Pro wrote: > > Hi, > > > > > > If a brick is down and comes back up later, how does Glusterfs know > > which files in this brick need to be 'self-healed'? > > > > > > Since the metadata of whether to 'heal' is stored as an xattr in a > > replica on other bricks. Does Glusterfs scan these files on the other > > bricks to see if one is "accusing" its replica and therefore need to > > "heal" its replica? > > > > > > In short, does Glusterfs keep a record of "writes" to a brick when a > > brick is down and apply these "writes" to the brick when its backup? > > > > > > > > > > Thanks, > > JPro > > > > ___ > > Gluster-users mailing list > > Gluster-users@gluster.org > > http://supercolony.gluster.org/mailman/listinfo/gluster-users > > -- > Patric Uebele > Solution Architect Storage > > Red Hat GmbH > Technopark II, Haus C > Werner-von-Siemens-Ring 14 > 85630 Grasbrunn > Germany > > Office:+49 89 205071-162 > Cell: +49 172 669 14 99 > mailto:patric.ueb...@redhat.com > > gpg keyid: 48E64CC1 > gpg fingerprint: C63E 6320 A03B 4410 D208 4EE7 12FC D0E6 48E6 4CC1 > > > Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn > Handelsregister: Amtsgericht Muenchen HRB 153243 > Geschaeftsfuehrer: Mark Hegarty, Charlie Peters, Michael Cunningham, > Charles Cachera ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
