Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem
11.07.2013 17:43, Reid Linnemann написав(ла): So recently I was trying to transfer a root-on-ZFS zpool from one pair of disks to a single, larger disk. As I am wont to do, I botched the transfer up and decided to destroy the ZFS filesystems on the destination and start again. Naturally I was up late working on this, being sloppy and drowsy without any coffee, and lo and behold I issued my 'zfs destroy -R' and immediately realized after pressing [ENTER[ that I had given it the source's zpool name. oops. Fortunately I was able to interrupt the procedure with only /usr being destroyed from the pool and I was able to send/receive the truly vital data in my /var partition to the new disk and re-deploy the base system to /usr on the new disk. The only thing I'm really missing at this point is all of the third-party software configuration I had in /usr/local/etc and my apache data in /usr/local/www. You can try to experiment with zpool hidden flags. Look at this command: zpool import -N -o readonly=on -f -R /pool It will try to import pool in readonly mode so no data would be written on it. It also doesn't mount anything on import so if any fs is damaged you have less chances triggering a coredump. Also zpool import has a hidden -T switch that gives you ability to select transaction that you want to try to restore. You'll need a list of available transaction though: zdb -ul This one when given a vdev lists all uberblocks with their respective transaction ids. You can take the highest one (it's not the last one) and try to mount pool with: zpool import -N -o readonly=on -f -R /pool -F -T Then check available filesystems. -- Sphinx of black quartz, judge my vow. ___ 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: Error on building cross-gcc
On Fri, Jul 12, 2013 at 12:06:32AM -0300, Otac?lio wrote: > Dears > > I'm tryning to build cross-gcc with this command line > > make TGTARCH=arm TGTABI=freebsd10 > > or > > make TGTARCH=arm TGTABI=freebsd8 > > on a > > FreeBSD squitch 8.4-RELEASE FreeBSD 8.4-RELEASE #27: Mon Jun 10 08:52:47 > BRT 2013 ota@squitch:/usr/obj/usr/src/sys/SQUITCH i386 > > > but all times I got > > /usr/ports/devel/cross-gcc/work/build/./gcc/xgcc > -B/usr/ports/devel/cross-gcc/work/build/./gcc/ > -B/usr/local/arm-freebsd10/bin/ -B/usr/local/arm-freebsd10/lib/ -isystem > /usr/ports/devel/cross-gcc/work/build/./gcc -isystem > /usr/local/arm-freebsd10/include -isystem > /usr/local/arm-freebsd10/sys-include-g -O2 -pipe > -fno-strict-aliasing -mbig-endian -O2 -g -O2 -pipe -fno-strict-aliasing > -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings > -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -fno-inline -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc > -I. -I. -I../../.././gcc -I../../.././../gcc-4.5.4/libgcc > -I../../.././../gcc-4.5.4/libgcc/. > -I../../.././../gcc-4.5.4/libgcc/../gcc > -I../../.././../gcc-4.5.4/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o > -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c > ../../.././../gcc-4.5.4/libgcc/../gcc/libgcc2.c \ > > In file included from ../../.././../gcc-4.5.4/libgcc/../gcc/tsystem.h:44:0, > from ../../.././../gcc-4.5.4/libgcc/../gcc/libgcc2.c:29: > /usr/ports/devel/cross-gcc/work/build/./gcc/include/stddef.h:59:24: > fatal error: sys/_types.h: No such file or directory > compilation terminated. > gmake[4]: ** [_muldi3.o] Erro 1 Did you compile cross-binutils first? Check back next week. Work is being done on this port. > > > Someone can give me a hint about what is happen? > > Thanks a lot > -Otacilio > ___ > 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" -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Kernel dumps [was Re: possible changes from Panzura]
On 10 July 2013 19:07, Vincent Hoffman wrote: > > There was some work on something similar at one point, not sure what > came of it. > http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020164.html The code referenced there has been used in production since 2005 or so, and is based on an earlier implementation for FreeBSD 4.x that dates to 2000. Despite some shortcomings in the implementation it has proved quite reliable in practice. It hasn't made it into the tree yet for reasons raised in this thread. The primary issue is that it allocates mbufs in the packet sending path, and so relies on a number of kernel subsystems to be in a consistent state. It doesn't use the stack, routing table, or driver interrupt interfaces though. It could likely be made committable with a relatively small effort to switch to preallocating an mbuf+cluster or two at configuration time. More information is on the FreeBSD wiki, at https://wiki.freebsd.org/Netdump ___ 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: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem
Hey presto! /> zfs list NAME USED AVAIL REFER MOUNTPOINT bucket 485G 1.30T 549M legacy bucket/tmp21K 1.30T21K legacy bucket/usr 29.6G 1.30T 29.6G /mnt/usr bucket/var 455G 1.30T 17.7G /mnt/var bucket/var/srv 437G 1.30T 437G /mnt/var/srv There's my old bucket! Thanks much for the hidden -T argument, Volodymyr! Now I can get back the remainder of my missing configuration. On Fri, Jul 12, 2013 at 7:33 AM, Volodymyr Kostyrko wrote: > 11.07.2013 17:43, Reid Linnemann написав(ла): > > So recently I was trying to transfer a root-on-ZFS zpool from one pair of >> disks to a single, larger disk. As I am wont to do, I botched the transfer >> up and decided to destroy the ZFS filesystems on the destination and start >> again. Naturally I was up late working on this, being sloppy and drowsy >> without any coffee, and lo and behold I issued my 'zfs destroy -R' and >> immediately realized after pressing [ENTER[ that I had given it the >> source's zpool name. oops. Fortunately I was able to interrupt the >> procedure with only /usr being destroyed from the pool and I was able to >> send/receive the truly vital data in my /var partition to the new disk and >> re-deploy the base system to /usr on the new disk. The only thing I'm >> really missing at this point is all of the third-party software >> configuration I had in /usr/local/etc and my apache data in >> /usr/local/www. >> > > You can try to experiment with zpool hidden flags. Look at this command: > > zpool import -N -o readonly=on -f -R /pool > > It will try to import pool in readonly mode so no data would be written on > it. It also doesn't mount anything on import so if any fs is damaged you > have less chances triggering a coredump. Also zpool import has a hidden -T > switch that gives you ability to select transaction that you want to try to > restore. You'll need a list of available transaction though: > > zdb -ul > > This one when given a vdev lists all uberblocks with their respective > transaction ids. You can take the highest one (it's not the last one) and > try to mount pool with: > > zpool import -N -o readonly=on -f -R /pool -F -T > > Then check available filesystems. > > -- > Sphinx of black quartz, judge my vow. > ___ 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: Kernel dumps [was Re: possible changes from Panzura]
On 7/12/13 10:01 PM, Ed Maste wrote: On 10 July 2013 19:07, Vincent Hoffman wrote: There was some work on something similar at one point, not sure what came of it. http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020164.html The code referenced there has been used in production since 2005 or so, and is based on an earlier implementation for FreeBSD 4.x that dates to 2000. Despite some shortcomings in the implementation it has proved quite reliable in practice. It hasn't made it into the tree yet for reasons raised in this thread. The primary issue is that it allocates mbufs in the packet sending path, and so relies on a number of kernel subsystems to be in a consistent state. It doesn't use the stack, routing table, or driver interrupt interfaces though. It could likely be made committable with a relatively small effort to switch to preallocating an mbuf+cluster or two at configuration time. More information is on the FreeBSD wiki, at https://wiki.freebsd.org/Netdump I would say this is one of the features I've looked for a LOT over the last 20 years. ___ 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" ___ 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: Error on building cross-gcc
On 12/07/2013 10:14, Diane Bruce wrote: > On Fri, Jul 12, 2013 at 12:06:32AM -0300, Otac?lio wrote: >> Dears >> >> I'm tryning to build cross-gcc with this command line >> >> make TGTARCH=arm TGTABI=freebsd10 >> >> or >> >> make TGTARCH=arm TGTABI=freebsd8 >> >> on a >> >> FreeBSD squitch 8.4-RELEASE FreeBSD 8.4-RELEASE #27: Mon Jun 10 08:52:47 >> BRT 2013 ota@squitch:/usr/obj/usr/src/sys/SQUITCH i386 >> >> >> but all times I got >> >> /usr/ports/devel/cross-gcc/work/build/./gcc/xgcc >> -B/usr/ports/devel/cross-gcc/work/build/./gcc/ >> -B/usr/local/arm-freebsd10/bin/ -B/usr/local/arm-freebsd10/lib/ -isystem >> /usr/ports/devel/cross-gcc/work/build/./gcc -isystem >> /usr/local/arm-freebsd10/include -isystem >> /usr/local/arm-freebsd10/sys-include-g -O2 -pipe >> -fno-strict-aliasing -mbig-endian -O2 -g -O2 -pipe -fno-strict-aliasing >> -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings >> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes >> -Wold-style-definition -isystem ./include -fno-inline -g >> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc >> -I. -I. -I../../.././gcc -I../../.././../gcc-4.5.4/libgcc >> -I../../.././../gcc-4.5.4/libgcc/. >> -I../../.././../gcc-4.5.4/libgcc/../gcc >> -I../../.././../gcc-4.5.4/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o >> -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c >> ../../.././../gcc-4.5.4/libgcc/../gcc/libgcc2.c \ >> >> In file included from ../../.././../gcc-4.5.4/libgcc/../gcc/tsystem.h:44:0, >> from ../../.././../gcc-4.5.4/libgcc/../gcc/libgcc2.c:29: >> /usr/ports/devel/cross-gcc/work/build/./gcc/include/stddef.h:59:24: >> fatal error: sys/_types.h: No such file or directory >> compilation terminated. >> gmake[4]: ** [_muldi3.o] Erro 1 > > Did you compile cross-binutils first? > > Check back next week. Work is being done on this port. >> >> >> Someone can give me a hint about what is happen? >> >> Thanks a lot >> -Otacilio >> ___ Yes I compile cross-binutils first. It is a dependency. Thank you! ___ 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"
