You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a rookie mistake on my part, however I had bricks mounting in fstab as /dev/sda1, /dev/sdb1, etc vs UUID. After repairing a host issue, it came back online and re-ordered the /dev/sd* drives, causing some bricks to be flipped/mounted to the wrong paths. Much to my surprise, gluster continued to believe those bricks were correct, and began erasing data on those subvolumes. Would be nice if gluster could write some sort of identifier to each brick to halt if that brick process if the ID doesn't match.
The text was updated successfully, but these errors were encountered:
edrock200
changed the title
Feature Request - Right unique identifier to each brick to halt if brick is mounted in incorrect location
Feature Request - Write unique identifier to each brick to halt if brick is mounted in incorrect location
Jul 29, 2024
Best practice is to use LVM (which has unique name) or FS UUID when mounting. Then, you should create a directory inside the mountpoint, so if the mount operation has failed (or is readonly) GlusterFS would not be able to use the local storage.
This is a rookie mistake on my part, however I had bricks mounting in fstab as /dev/sda1, /dev/sdb1, etc vs UUID. After repairing a host issue, it came back online and re-ordered the /dev/sd* drives, causing some bricks to be flipped/mounted to the wrong paths. Much to my surprise, gluster continued to believe those bricks were correct, and began erasing data on those subvolumes. Would be nice if gluster could write some sort of identifier to each brick to halt if that brick process if the ID doesn't match.
The text was updated successfully, but these errors were encountered: