Date: Sun, 23 Oct 2011 23:13:13 +0700 From: Victor Sudakov <vas@mpeks.tomsk.su> To: freebsd-questions@freebsd.org Subject: Re: strange behavior of restore(8) Message-ID: <20111023161312.GA46735@admin.sibptus.tomsk.ru> In-Reply-To: <20111022053315.GA30712@admin.sibptus.tomsk.ru> References: <20111021110600.GA19417@admin.sibptus.tomsk.ru> <CAHhngE3Oub-36fE_X4eT_4r8LygQ7D1dbcWjdTn3KCeE95J9uQ@mail.gmail.com> <20111022053315.GA30712@admin.sibptus.tomsk.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Victor Sudakov wrote: > > > > > > I am trying to restore a UFS2 zero level dump sized about 51G. > > > restore has created 6105 directories and no files at all, and now is > > > waiting forever in the runnable state. > > > > I don't have any specific advice here, but if it were me I think my > > next troubleshooting step would be to attach truss to the restore > > process after it gets "stuck," to try to see exactly what it's doing. > > That may give you a clue as to why it's taking so long and whether > > it's actually making any progress. > > It's doing something like that. I should have piped the output > through uniq not to clutter the list, but on second thought, I decided > not to: > > # truss -p 18568 > lseek(4,0x0,SEEK_CUR) = 25395100 (0x1837f9c) > lseek(4,0x0,SEEK_CUR) = 25395100 (0x1837f9c) > lseek(4,0x0,SEEK_CUR) = 25395100 (0x1837f9c) > lseek(4,0x0,SEEK_CUR) = 25395100 (0x1837f9c) restore has been running for more than 48 hours now. Whatever is the matter, it is unacceptable as a backup solution. I will try restoring on an amd64 system tomorrow just to see if it will make any difference. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111023161312.GA46735>