check out the syslogs of iptables logs  on ip address access during that
time.
maybe you should move in the future to the centralised logging independent
of vm infrastructure

Am 07.08.2017 2:20 nachm. schrieb <lemonni...@ulrar.net>:

> > It really depends on the application if locks are used. Most (Linux)
> > applications will use advisory locks. This means that locking is only
> > effective when all participating applications use and honour the locks.
> > If one application uses (advisory) locks, and an other application now,
> > well, then all bets are off.
> >
> > It is also possible to delete files that are in active use. The contens
> > will still be served by the filesystem, but there is no accessible
> > filename anymore. If the VMs using those files are still running, there
> > might be a way to create a new filename for the data. If the VMs have
> > been stopped, and the file-descriptior has been closed, the data will be
> > gone :-/
> >
>
> Oh the data was gone long before I stopped the VM, every binary was
> doing I/O errors when accessed, only whatever was in ram (ssh ..) when
> the disk got suppressed was still working.
>
> I'm a bit surpised they could be deleted, but I imagine qemu through
> libgfapi doesn't really access the file as a whole, maybe just the part
> it needs when it needs it. In any case the gluster logs show clearly
> file descriptor errors from 8h47 AM UTC, which seems to match our first
> monitoring alerts. I assume that's when the deletion happened.
>
> Now I just need to figure out what they used to access the volume, I
> hope it's just NFS since that's the only thing I can think of.
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Reply via email to