On Friday, April 18, 2014 9:13:00 PM UTC-5, Nikolaus Rath wrote: > > Randy Black <[email protected] <javascript:>> writes: > > On Friday, April 18, 2014 12:13:14 PM UTC-5, Nikolaus Rath wrote: > >> > >> Randy Black <[email protected] <javascript:>> writes: > >> > I am using s3ql on a vagrant vm (VirtualBox) CentOS 6.5 attaching to > a > >> > swift cluster using keystone authentication. The vm did not unmount > >> > clean. > >> > >> What does that mean? How can you mount (or unmount) a vm (virtual > >> machine)? > >> > > Unmount the drive clean. > > What drive? >
Mount point. > > > Vagrant manages your virtual machine, it's a > > light weight way to make and reproduce vm's for testing. It is still a > > Virtualbox vm or vmware if you choose to go with that hypervisor. > Either > > way, what my brain said was unmount the dirve, what my fingers said was > > unmount,with no specification. > > Sorry, I still have no idea what you actually did. You seem to use the > words vm, drive, and s3ql mountpoint interchangeably, although (to me) > they have very distinct meanings. > The vm is a vagrant managed virtualbox vm. > > >> > I ran a fsck.s3ql on the storage url and it get; > >> > > >> >> Backend reports that file system is still mounted elsewhere. Either > >> >> the file system has not been unmounted cleanly or the data has not > yet > >> >> propagated through the backend. In the later case, waiting for a > while > >> >> should fix the problem, in the former case you should try to run > fsck > >> >> on the computer where the file system has been mounted most > recently. > >> >> Enter "continue" to use the outdated data anyway: > >> > >> This sounds as if the virtual machine running mount.s3ql crashed, and > >> you then ran ran fsck.s3ql on a different system or a new vm. Is that > >> correct? > >> > >> Then this is expected behavior, you need to run fsck.s3ql on the same > vm > >> where you last mounted the file system. This is where the data is. > > > > it was the same vm, power cycles (crash) and fsck.s3ql reported back the > > same message on multiple attempts. > > Did you run it as the same user, with the same home directory, with the > same options? > Yes, same user, mountpoint and vm (machine). > > Did you unmount the s3ql file system, or did you power cycle the vm? In > the latter case, it's quite possible that you lost the contents of the > ~/.s3ql directory. In that case there is obviously nothing that s3ql can > do to restore the data. > > >> > I deleted the metadata out of the swift container > >> > >> Do you mean you manually deleted objects in the swift container? Why > did > >> you do that? This is a recipe for desaster. > > > > Agree, thats why I am using it in a test env now so I can understand and > > avoid those issues in a prod/dev environment. > > I still don't understand what gave you the idea to do this in the first > place. > The world may never know.... ;) A few reason that came to mind as I was doing it. 1.) I wanted to see what would happen. 2.) it was a staging cluster with random disposable data. 3.) Spin extra cycles getting to know the product. Again, Thanks for your time. I'll try and be sensitive to it. We would all rather you be working on code vs. answering the forum. Randy > > Best, > Nikolaus > > -- > GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F > Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
