Re: dump -L
Colleagues, Right now I am watching a dump: [EMAIL PROTECTED] ~] dump -b64 -5Lau /home DUMP: Connection to big.sibptus.tomsk.ru established. DUMP: Date of this level 5 dump: Sat Aug 18 14:02:16 2007 DUMP: Date of last level 0 dump: Sun Aug 12 11:10:56 2007 DUMP: Dumping snapshot of /dev/ad0s2f (/home) to /dev/nsa0 on host big DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 3249348 tape blocks. at the same moment: [EMAIL PROTECTED] ~] snapinfo -v /home /dev/ad0s2f mounted on /home no snapshots found [EMAIL PROTECTED] ~] ll /home/.snap/ total 0 [EMAIL PROTECTED] ~] Is this normal? Does it mean that dump is not really dumping a snapshot though it says it is? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Victor Sudakov wrote: Colleagues, Right now I am watching a dump: [EMAIL PROTECTED] ~] dump -b64 -5Lau /home DUMP: Connection to big.sibptus.tomsk.ru established. DUMP: Date of this level 5 dump: Sat Aug 18 14:02:16 2007 DUMP: Date of last level 0 dump: Sun Aug 12 11:10:56 2007 DUMP: Dumping snapshot of /dev/ad0s2f (/home) to /dev/nsa0 on host big DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 3249348 tape blocks. at the same moment: [EMAIL PROTECTED] ~] snapinfo -v /home /dev/ad0s2f mounted on /home no snapshots found [EMAIL PROTECTED] ~] ll /home/.snap/ total 0 [EMAIL PROTECTED] ~] Is this normal? Does it mean that dump is not really dumping a snapshot though it says it is? man dump (the section regarding -L) says The snapshot is unlinked as soon as the dump starts, and is thus removed when the dump is complete. What this means to you is that the snapshot is only visible on the file system for as long as it takes dump to start reading from it, dump will have an open filehandle to the snapshot so it can be unlinked from the filesystem and as soon as dump closed its handle then the snapshot is removed. Similar to when you delete a large logfile a program has open and forget to HUP/stop/restart the program, the logfile's diskspace isnt released until the the program closes its file handle. Vince ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Vince wrote: Right now I am watching a dump: [EMAIL PROTECTED] ~] dump -b64 -5Lau /home DUMP: Connection to big.sibptus.tomsk.ru established. DUMP: Date of this level 5 dump: Sat Aug 18 14:02:16 2007 DUMP: Date of last level 0 dump: Sun Aug 12 11:10:56 2007 DUMP: Dumping snapshot of /dev/ad0s2f (/home) to /dev/nsa0 on host big DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 3249348 tape blocks. at the same moment: [EMAIL PROTECTED] ~] snapinfo -v /home /dev/ad0s2f mounted on /home no snapshots found [EMAIL PROTECTED] ~] ll /home/.snap/ total 0 [EMAIL PROTECTED] ~] Is this normal? Does it mean that dump is not really dumping a snapshot though it says it is? man dump (the section regarding -L) says The snapshot is unlinked as soon as the dump starts, and is thus This explains why there is no visible snapshot file in /home/.snap/ However, I thought that snapinfo should be aware even of unlinked snapshots. Just like mdconfig -l still shows the backingstore file even if it has been unlinked. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
On 06/08/07, Victor Sudakov [EMAIL PROTECTED] wrote: Does nobody know the answer, or am I the only one experiencing the problem? I don't know the answer, but I get essentially the same behaviour. I have never seen any data loss, I gave an example below. The file wins.dat was not dumped. It is indeed missing from the tape. If this is not a data loss, what is it then? Not to perpetuate an argument for its own sake, but I suppose I meant data loss to mean the loss of files that _should_ exist, as opposed to files that _could_ exist. A fine line, but in my /laissez faire/ universe a quite salient one. As to whether wins.dat should exist is beyond me. If you believe it should, then that would be data loss by my metric. I apologise for any confusion, -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
[EMAIL PROTECTED] wrote: Does nobody know the answer, or am I the only one experiencing the problem? I don't know the answer, but I get essentially the same behaviour. I have never seen any data loss, I gave an example below. The file wins.dat was not dumped. It is indeed missing from the tape. If this is not a data loss, what is it then? Not to perpetuate an argument for its own sake, but I suppose I meant data loss to mean the loss of files that _should_ exist, as opposed to files that _could_ exist. A fine line, but in my /laissez faire/ universe a quite salient one. As to whether wins.dat should exist is beyond me. If you believe it should, then that would be data loss If it (or any other file) does exist in the filesystem, it should exist also in the backup. Otherwise we have a defective backup. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
On 07/08/07, Victor Sudakov [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Does nobody know the answer, or am I the only one experiencing the problem? I don't know the answer, but I get essentially the same behaviour. I have never seen any data loss, I gave an example below. The file wins.dat was not dumped. It is indeed missing from the tape. If this is not a data loss, what is it then? Not to perpetuate an argument for its own sake, but I suppose I meant data loss to mean the loss of files that _should_ exist, as opposed to files that _could_ exist. A fine line, but in my /laissez faire/ universe a quite salient one. As to whether wins.dat should exist is beyond me. If you believe it should, then that would be data loss If it (or any other file) does exist in the filesystem, it should exist also in the backup. Otherwise we have a defective backup. You are begging the question. The functional definition of a live filesystem is one in which you cannot guarantee the state to be determineable across time. Snapshots might make it more likely, being faster, but they still have to work in time*. To put it another way: by the time any part of the system knows the state of any part of the system, it is wrong. I would like to point out that I am not saying that dump does not have a bug, but that this is not evidence in and of itself for it. *And no matter what anyone tells you, time is not infinitely divisible. -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 i had it too, sometimes even restore is unable to restore well -1-9 dumps :( I thought this should _never_ happen when dumping a snapshot. What is it? Thanks in advance for any input. I am ready to provide additional info if required to understand the problem. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
expected next file 12345, got 23456 I'm seeing this too. It's always exactly one inode per file system. not one, sometimes even tens. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
On 05/08/07, Victor Sudakov [EMAIL PROTECTED] wrote: Victor Sudakov wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? I don't know the answer, but I get essentially the same behaviour. I have never seen any data loss, though. I just tended to assume it was either harmless or the world was going to end, neither of which cases I could seem to rule out definitively. -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
[EMAIL PROTECTED] wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? I don't know the answer, but I get essentially the same behaviour. I have never seen any data loss, I gave an example below. The file wins.dat was not dumped. It is indeed missing from the tape. If this is not a data loss, what is it then? [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
On Mon, Aug 06, 2007 at 02:18:57PM +0700, Victor Sudakov wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? I don't know the answer, but I get essentially the same behaviour. I have never seen any data loss, I gave an example below. The file wins.dat was not dumped. It is indeed missing from the tape. If this is not a data loss, what is it then? [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 Uh-oh :-(. I have no idea how the code works, but just a wild guess: what happens when a file is being created and a snapshot taken at the same time? Isn't there a tiny window between inode creation and directory update? Or is file creation an atomic operation w.r.t. snapshots and dump? Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
On Mon, Aug 06, 2007 at 09:56:15AM +0700, Victor Sudakov wrote: Victor Sudakov wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? Here is another example: [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 Using 'dump -L' doesn't prevent you or something running on the system from deleting a file after the directory has been created and written. The first thing dump does is create a list of files (including directories) to dump. It creates a list of inodes for the files and then does all the dumping from that list of inodes. If a file is then deleted after that inode list is made, then it will not get written to the dump media. But, the list will still have the inode for the file. When restore looks for files, it searches in inode order and makes a note if an inode is missing from the media that it expected (because of the list) to be there.It is only a true error if that file really should have been there and wasn't. The only time I have had that happen was when the media (tape) couldn't be read properly. Usually then you also get other errors. jerry -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
In response to Jerry McAllister [EMAIL PROTECTED]: On Mon, Aug 06, 2007 at 09:56:15AM +0700, Victor Sudakov wrote: Victor Sudakov wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? Here is another example: [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 Using 'dump -L' doesn't prevent you or something running on the system from deleting a file after the directory has been created and written. The first thing dump does is create a list of files (including directories) to dump. It creates a list of inodes for the files and then does all the dumping from that list of inodes. If a file is then deleted after that inode list is made, then it will not get written to the dump media. But, the list will still have the inode for the file. When restore looks for files, it searches in inode order and makes a note if an inode is missing from the media that it expected (because of the list) to be there.It is only a true error if that file really should have been there and wasn't. The only time I have had that happen was when the media (tape) couldn't be read properly. Usually then you also get other errors. Ok, but using -L causes dump to create a filesystem snapshot, which is read- only, meaning that nobody can delete a file from it during the dump process. My guess would be that something is causing the snapshot to fail, which will cause dump to issue a warning and then continue without making a snapshot. Can you provide the output of dump while doing the dump? -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Bill Moran wrote: Here is another example: [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 [dd] My guess would be that something is causing the snapshot to fail, which will cause dump to issue a warning and then continue without making a snapshot. It is not likely. Can you provide the output of dump while doing the dump? [EMAIL PROTECTED] ~] dump -b64 -0La /var DUMP: Date of this level 0 dump: Mon Aug 6 22:43:07 2007 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/mirror/gm1s1f (/var) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 21553084 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Jerry McAllister wrote: Victor Sudakov wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? Here is another example: [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 Using 'dump -L' doesn't prevent you or something running on the system from deleting a file after the directory has been created and written. Excuse me? 'dump -L' creates a snapshot which is (or should be) a frozen copy of the filesystem, and then dumps the snapshot. The first thing dump does is create a list of files (including directories) to dump. It creates a list of inodes for the files and then does all the dumping from that list of inodes. If a file is then deleted after that inode list is made, then it will not get written to the dump media. How can a file be deleted from a snapshot? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
cpghost wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? I don't know the answer, but I get essentially the same behaviour. I have never seen any data loss, I gave an example below. The file wins.dat was not dumped. It is indeed missing from the tape. If this is not a data loss, what is it then? [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 Uh-oh :-(. I have no idea how the code works, but just a wild guess: what happens when a file is being created and a snapshot taken at the same time? I would very much like to know that. Creating a snapshot can take several minutes on a large modern HDD. Many files can be changed during those minutes. Isn't there a tiny window between inode creation and directory update? Or is file creation an atomic operation w.r.t. snapshots and dump? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Victor Sudakov wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Does nobody know the answer, or am I the only one experiencing the problem? Here is another example: [EMAIL PROTECTED] ~] restore -b64 -rN ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape expected next file 267, got 4 expected next file 2828988, got 2828987 -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dump -L
Colleagues, I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I thought this should _never_ happen when dumping a snapshot. What is it? Thanks in advance for any input. I am ready to provide additional info if required to understand the problem. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
On Tue, Jul 24, 2007 at 06:54:01PM +0700, Victor Sudakov wrote: Colleagues, I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I'm seeing this too. It's always exactly one inode per file system. I thought this should _never_ happen when dumping a snapshot. What is it? I don't know. Perhaps it is the inode of the snapshot file itself? Thanks in advance for any input. I am ready to provide additional info if required to understand the problem. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
cpghost wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I'm seeing this too. It's always exactly one inode per file system. You are probably talking about expected next file 12345, got 23456. It seems harmless. But I am more worried about foo.txt (inode 12345) not found on tape. Indeed, some files fail to get into the dump. I thought this should _never_ happen when dumping a snapshot. What is it? I don't know. Perhaps it is the inode of the snapshot file itself? find -inum does not support this assumtion. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Victor Sudakov [EMAIL PROTECTED] writes: cpghost wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I'm seeing this too. It's always exactly one inode per file system. You are probably talking about expected next file 12345, got 23456. It seems harmless. But I am more worried about foo.txt (inode 12345) not found on tape. Indeed, some files fail to get into the dump. Are the files active at the time of the dump? I thought this should _never_ happen when dumping a snapshot. What is it? I don't know. Perhaps it is the inode of the snapshot file itself? find -inum does not support this assumtion. Do you mean that you can't find the file at all in the snapshot? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Lowell Gilbert wrote: I always use dump -L to dump a live filesystem. However, when I restore the dump, I sometimes get messages like foo.txt (inode 12345) not found on tape or expected next file 12345, got 23456 I'm seeing this too. It's always exactly one inode per file system. You are probably talking about expected next file 12345, got 23456. It seems harmless. But I am more worried about foo.txt (inode 12345) not found on tape. Indeed, some files fail to get into the dump. Are the files active at the time of the dump? Yes, they are. These are files edited by Samba users, mrtg files etc. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L
Lowell Gilbert wrote: What is it? I don't know. Perhaps it is the inode of the snapshot file itself? find -inum does not support this assumtion. Do you mean that you can't find the file at all in the snapshot? Here is an example for you: $ restore -rNf test.dmp ./var/db/entropy/saved-entropy.1: (inode 1887715) not found on tape expected next file 259101, got 11 $ restore -tvf test.dmp | grep 259101 Level 0 dump of / on test.sibptus.tomsk.ru:/dev/ad0s1a Label: none leaf259101 ./usr/share/tmac/m.tmac $ restore -tvf test.dmp | grep 11 Level 0 dump of / on test.sibptus.tomsk.ru:/dev/ad0s1a Label: none dir1130496 ./media $ This means that 1. /var/db/entropy/saved-entropy.1 was not dumped for some reason, though -L was given during the dump. 2. File with inode number 11 is not in the dump. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dump -L not working as expected?
Colleagues, I dump an active filesystem on a FreeBSD 5.4-RELEASE-p7 with the -L option. dump says: Dumping snapshot of /dev/mirror/gm1s1h (/home) to ... However when I later restore -r the filesystem, I keep getting messages like ./www/data/ASN/bay_3.log: (inode 805993) not found on tape expected next file 23553, got 6 expected next file 805964, got 805963 expected next file 806010, got 806009 Why is that? I am used to seeing such messages on FreeBSD 4.x and earlier systems, but I thought I would never see them again when dumping a snapshot. Thanks in advance for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
