New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Completely filling up a Disperse volume results in unreadable/unhealable files that must be deleted. #2021
Comments
Thank you for your contributions. |
Just because nobody is able to work on this does not mean that this is not a valid issue. This should not be summarily closed by a bot! |
I will try to reproduce and update. |
This is an expected behavior. This is not the right way of configuring bricks, you should have set a limit on bricks so that it could have given a warning before filling it UP. Now, to resolve this you might have to create space on all the bricks (disks) which looks like not possible. So you may have to delete some data manually from backend. I would have deleted those files which are causing EIO. |
Thanks ashish for your response. |
Thank you for your contributions. |
Closing this issue as there was no update since my last update on issue. If this is an issue which is still valid, feel free to open it. |
Completely filling up a Disperse volume results in unreadable
(EIO) and unhealable files that must be deleted. This is
unfortunate, because although the files had append write
failures, the first parts of the files could still be intact
and usable.
The problem first occurred on a volume being used as storage
for video surveillance cameras. The application failed to
clean up space, so completely filled the GlusterFS Disperse volume.
An earlier GlusterFS version was being used, but the problem
was created in a lab environment using the latest version using
the procedure below.
The text was updated successfully, but these errors were encountered: