[Gluster-users] problem with missing bricks

Mohit Anchlia mohitanchlia at gmail.com
Sun Jan 1 18:47:03 UTC 2012


Can you post the output of df -h? It looks like you have mounted the
drives as /gluster/brick[0-9]? If that is correct then you can
mitigate that by create a sub directory on that mount points accross
all the bricks, and do writes only inside that sub-dir.

On Sat, Dec 31, 2011 at 8:50 AM, Todd Pfaff <pfaff at rhpcs.mcmaster.ca> wrote:
> Gluster-user folks,
>
> I'm trying to use gluster in a way that may be a considered an unusual use
> case for gluster.  Feel free to let me know if you think what I'm doing
> is dumb.  It just feels very comfortable doing this with gluster.
> I have been using gluster in other, more orthodox configurations, for
> several years.
>
> I have a single system with 45 inexpensive sata drives - it's a self-built
> backblaze similar to that documented at this url but with some upgrades
> and substitutions:
>
>  http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/
>
> We use this system for disk-to-disk backups only, no primary storage,
> nothing mission critical.
>
> For the past two years I have been using this system with linux software
> raid, with the drives organized as multiple raid 5/6/10 sets of 5 drives
> per set.  This has worked ok but I have suffered enough multiple
> simultaneous drive failures to prompt me to explore alternatives to raid.
> Yes, I know, that's what I get for using cheap sata drives.
>
> What I'm experimenting with now is creating gluster distributed-replicated
> volumes on some of these drives, and maybe all in the future if this works
> reasonably well.
>
> At this point I am using 10 of the drives configured as shown here:
>
>  Volume Name: volume1
>  Type: Distributed-Replicate
>  Status: Started
>  Number of Bricks: 5 x 2 = 10
>  Transport-type: tcp
>  Bricks:
>  Brick1: host:/gluster/brick01
>  Brick2: host:/gluster/brick06
>  Brick3: host:/gluster/brick02
>  Brick4: host:/gluster/brick07
>  Brick5: host:/gluster/brick03
>  Brick6: host:/gluster/brick08
>  Brick7: host:/gluster/brick04
>  Brick8: host:/gluster/brick09
>  Brick9: host:/gluster/brick05
>  Brick10: host:/gluster/brick10
>  Options Reconfigured:
>  auth.allow: 127.0.0.1,10.10.10.10
>
>
> For the most part this is working fine so far.  The problem I have run
> into several times now is that when a drive fails and the system is
> rebooted, the volume comes up without that brick.  Gluster happily writes
> to the missing brick's mount point, thereby eventually filling up the root
> filesystem.  Once the root filesystem is full and processes writing to
> gluster space are hung, I can never recover from this state without
> rebooting.
>
> Is there any way to avoid this problem of gluster writing to a brick
> path that isn't really populated by the intended brick filesystem?
> Does gluster not create any sort of signature or meta-data that
> indicates whether or not a path is really a gluster brick?
> How do others deal with missing bricks?
>
> I realize that ultimately I should get the bricks replaced as soon as
> possible but there may be times when I want to continue running for some
> time with a "degraded" volume if you will.
>
> Any and all ideas, suggestions, comments, criticisms are welcome.
>
> Cheers and Happy New Year,
> Todd
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users



More information about the Gluster-users mailing list