>
> Thanks for fixing my problem with NF and backups, Steve. After I got
> caught up with all of the Email, I updated to the 2.4.5 kernel and have
> returned to testing to see if I can get it to break. So far, it seems
> like everything is working great.
>
> I have a few questions and concerns, though.
>
> When I do a backup now, I get lots of warnings from xfsdump, that look
> like:
Someone who understands xfs dump better than I can probably give you a
more reasonable explaination, but basically, the first pass of the dump is
an inode scan of the whole filesystem. This is used to decide what to
dump. We then take the list of inodes and go open them in turn, if they
have gone missing in the meantime then you get warnings about not being
able to open them. Note that pathnames are not used in the dump process
to look up the inodes, or to open them.
On the restore end I suspect you are seeing more results of files changing
underneath you - these were inodes which could be opened by dump, but which
were in unlinked state at dump time.
Finally, the amount of space to be used is only an estimate, I do not know
how accurate it normally is on Irix, but a factor of 2 looks a bit large.
Steve
>
> /usr/sbin/xfsdump: version 3.0 - Running single-threaded
> /usr/sbin/xfsdump: level 0 dump of fpga:/ibm1
> /usr/sbin/xfsdump: dump date: Mon Jun 4 08:54:53 2001
> /usr/sbin/xfsdump: session id: a2de6a1b-bdff-4989-abf9-5da1b3d7654e
> /usr/sbin/xfsdump: session label: ""
> /usr/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified)
> /usr/sbin/xfsdump: ino map phase 2: constructing initial dump list
> /usr/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary)
> /usr/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2)
> /usr/sbin/xfsdump: ino map phase 5: skipping (only one dump stream)
> /usr/sbin/xfsdump: ino map construction complete
> /usr/sbin/xfsdump: estimated dump size: 1455549376 bytes
> /usr/sbin/xfsdump: creating dump session media file 0 (media 0, file 0)
> /usr/sbin/xfsdump: dumping ino map
> /usr/sbin/xfsdump: dumping directories
> /usr/sbin/xfsdump: dumping non-directory files
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 38931 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235279 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235286 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235334 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 8431240 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 37787402 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 67149350 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 79731656 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: WARNING: could not open regular file ino 79732162 mode
> 0x000081b4: No such file or directory: not dumped
> /usr/sbin/xfsdump: ending media file
> /usr/sbin/xfsdump: media file size 876457568 bytes
> /usr/sbin/xfsdump: dump size (non-dir files) : 770291976 bytes
> /usr/sbin/xfsdump: dump complete: 10565 seconds elapsed
>
> It says that it could not open a regular file and it was not dumped. I
> wonder if that is all the information that is available, or if I could
> find out what the name of the file is that corresponds to that inode. It
> could be that xfsdump sees inodes and then has to map those to names,
> which might make sense why it would not dump the inode -- since it did not
> correlate to an actual file. Is that what is going or is it something
> different.
>
> Also when I xfsrestore from the dump file, it says that it has many more
> inodes that were stored on the dump file that are not referenced and they
> end up into the orphanage directory:
>
> xfsrestore: version 3.0 - Running single-threaded
> xfsrestore: searching media for dump
> xfsrestore: examining media file 0
> xfsrestore: dump description:
> xfsrestore: hostname: fpga
> xfsrestore: mount point: /ibm1
> xfsrestore: volume: /dev/sda1
> xfsrestore: session time: Sun Jun 3 14:23:52 2001
> xfsrestore: level: 0
> xfsrestore: session label: ""
> xfsrestore: media label: ""
> xfsrestore: file system id: 11c2b403-b066-4d54-bc6b-2999de0b0192
> xfsrestore: session id: da423fc8-eae5-4ddb-8dc5-c8d03f4ae9d1
> xfsrestore: media id: 1fbb2b7e-68e8-4831-a3a5-c480e6db44e3
> xfsrestore: searching media for directory dump
> xfsrestore: reading directories
> xfsrestore: directory post-processing
> xfsrestore: restoring non-directory files
> xfsrestore: NOTE: ino 37978 gen 3 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 33592109 gen 3 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 33593217 gen 4 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 37785398 gen 4 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 41983155 gen 5 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 46176727 gen 3 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 50373364 gen 4 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 50373834 gen 1 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 50373863 gen 1 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 54565523 gen 3 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 54565749 gen 4 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 54565800 gen 2 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 54565813 gen 1 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 58757929 gen 7 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 58758899 gen 3 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 58758977 gen 2 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 58759034 gen 2 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 62952384 gen 1 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 62952430 gen 3 not referenced: placing in orphanage
> ... <snip>
>
> xfsrestore: NOTE: ino 184588623 gen 1 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 184588682 gen 2 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 184588691 gen 1 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 184588708 gen 3 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 184588709 gen 2 not referenced: placing in orphanage
> xfsrestore: NOTE: ino 184588718 gen 1 not referenced: placing in orphanage
> xfsrestore: WARNING: unable to rmdir /ibm3/test/orphanage: Directory not empt
> y
> xfsrestore: restore complete: 9559 seconds elapsed
>
> My backup consists of two actively updated news spools of the comp.*
> hierarchy. They are on the order of 500,000 files. The backup happens
> as the spools are being updated so that files can change during the course
> of the backup. It seems odd that although 8-10 inodes could not be
> backed up, the xfsrestore could not restore 305 inodes that ?probably?
> were okay at xfsdump time? 305 files out of 500,000 is not that much, but
> does not seem too tolerable. If these files are files that disappeared
> during the backup process, it might be okay. Can anyone comment on this?
>
> Also if you look at the above xfdump report, it says that the filesystem
> was about 1.4G and the resultant backup was 860M. When I did the restore,
> it was back to about the correct original 1.4G, can anyone comment on why
> xfsdump is able to get such good compression?
>
> Thanks for you help and thanks for the good filesystem.
>
> .justin.
>
>
> ------------------------------------------------------------------------
> Justin Leonard Tripp justin@xxxxxxxxxx
> Configurable Computing Laboratory Research Assistant CB 461 x8-7206
> Electrical and Computer Engineering Department Brigham Young University
|