Re: After the FreeBSD VM crash, file system in VM got rolled back to some old previous state causing data loss
> > On 08/07/2013 01:56, Wojciech Puchar wrote: > > > > not possible in FreeBSD with UFS. > > > > but if you run virtualbox under linux i cannot say much... > > This happened with FreeBSD guest with UFS (journaled soft-updates) and > FreeBSD host. > What is out of normal, it rolled back for many hours (~20). > > Yuri > > Could be you are using *Immutable images *as type of disk for guest VM 1. *Immutable images.* When an image is switched to "immutable" mode, a differencing image is created as well. As with snapshots, the parent image then becomes read-only, and the differencing image receives all the write operations. Every time the virtual machine is started, all the immutable images which are attached to it have their respective differencing image thrown away, effectively resetting the virtual machine's virtual disk with every restart. http://www.virtualbox.org/manual/ch05.html //BR, Sergey ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re:dtrace filename lookups from fd (Serg Slobodyanyuk)
> > > Date: Fri, 1 Jun 2012 17:00:20 +0100 > From: "Steven Hartland" > > As a first foray into dtrace I wanted to create a little > script which shows the amount of disk read / write activity. > > Now the DtraceToolkit includes rwsnoop but this uses Solaris > specific requests and on looking around it seems like > using rwsnoop vn_fullpath may be the way to go. > > Has anyone done anything similar to this before or has any > tips on going about this? > >Regards >Steve > HI, Some times ago I decided to do the same - port rwsnoop to FreeBSD(8.2 R). FreeBSD vfs code quiet different from solaris code so I asked for help Kostik and he directed me to vn_fullpath() routine after that I wrote working port of rwsnoop. But script generate alot of errors like "invalid address (0x) in action" even on data that should be there(from my point of view). After several tries to debug it I left it as is. You can run it with "| grep -v invalid" or direct STDERR to /dev/null. Maybe Hackers could look at it and say what's wrong :-) Changed part of code: this->fp = &(curthread->td_proc->p_fd->fd_ofiles[self->fd]); this->vp = (struct vnode *)((*(this->fp))->f_vnode); this->cache_dst = &((this->vp)->v_cache_dst); this->ncp = (&((this->vp)->v_cache_dst)) != NULL ? (&((this->vp)->v_cache_dst))->tqh_first : 0; self->ncname = this->ncp ? (this->ncp->nc_name != 0 ? stringof(this->ncp->nc_name) : "") : "" Link to script: https://docs.google.com/open?id=0B7olr28SbDyNZktLMG51UHVxNW8 //Br. Serg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
