Re: NFS mount tar incremental problem
On Tue, Apr 15, 2008 at 7:58 PM, Jordan Desroches <[EMAIL PROTECTED]> wrote: > I have not tested it yet myself, but version 1.2 of gnutar was released > yesterday (see http://www.gnu.org/software/tar/#TOCreleases ) and of > particular interest is this feature (quoted from the page): (version 1.20, actually) Those flags were added at least in part due to a bunch of amanda users heading over to bug-tar and speaking up. Thanks, all! Jean-Louis has added a property to the amgtar application to support this, but unfortunately, it was just a bit too late for 2.6.0. By the time 2.6.1 comes around, hopefully some systems will have Tar 1.20 installed and can utilize this feature. In the interim, the best ways to take advantage of this is to rebuild Amanda with a modified sendbackup-gnutar.c, or to write an GNU Tar wrapper that supplies --no-check-device. Those who have done this, please post your wrappers and/or add them to the wiki? Dustin -- Storage Software Engineer http://www.zmanda.com
Re: NFS mount tar incremental problem
I have not tested it yet myself, but version 1.2 of gnutar was released yesterday (see http://www.gnu.org/software/tar/#TOCreleases ) and of particular interest is this feature (quoted from the page): "New options --no-check-device, --check-device. The --no-check-device option disables comparing device numbers during preparatory stage of an incremental dump. This allows to avoid creating full dumps if the device numbers change (e.g. when using an LVM snapshot). The --check-device option enables comparing device numbers. This is the default. This option is provided to undo the effect of the previous --no-check-device option, e.g. if it was set in TAR_OPTIONS environment variable." Best, Jordan On Mar 26, 2008, at 11:28 AM, Gene Heskett wrote: On Tuesday 25 March 2008, Gene Heskett wrote: On Tuesday 25 March 2008, Dustin J. Mitchell wrote: On Tue, Mar 25, 2008 at 11:31 AM, Gene Heskett <[EMAIL PROTECTED] > wrote: And I, like an idiot, didn't notice we were discussing an NFS problem, which may be another manifestation of the same problem, but that patch does not address what happens when the linux device mapper decides to move an LVM2 volume from 253,0 ro 254,0. The patch JLM posted won't fix it, but his proposed command-line option will. Post please, I don't believe I've seen it. I had some email problems over the weekend due to my / partition being in bad need of an fsck. 2.6.24 running tickless was a friggin nightmare. Thats why I'm asking about Schiling Tar, aka S-Tar. Does that fix the problem?, and can amanda use it? Yes, but its semantics are very different from GNU Tar -- it's not a drop-in fix. I was afraid of that. The ultimate weapon of course in any philosophical war, which this is, is to fork tar and fix it if STar isn't usable. At this point, and while I'm not capable of doing it, I'm not a bit allergic to the fork idea. Its bitten me so often that I'll alpha test anybodies efforts in that regard. Gleefully. Sure, but threatening a fork is un-diplomatic, and not called for just yet. Let's start with a concerted public-relations effort :) I doubt if my messages on the subject were the only ones they got, and from the attitude displayed in the replies I got, a fork IS the next step. They are immovable on the subject. They consider that a change in the device mapping numbers are prima-faci evidence of a stolen tar file trying to be recovered to a disk that they don't belong to. A huge security problem in their view. Humm, didn't we have some scripts that could inspect and repair the index files when this happened? Probably lost when I woke up one morning and found my well developed FC6 install wasn't re-bootable, LSN0 on /dev/hda had one non-zero byte left in it. Yep -- it's called tar-snapshot-edit, and it's available in recent releases of GNU Tar. Just google for it. I'll do that, got it. Thanks, Dustin. To continue this thread I have now subscribed to the bug-tar list about 24 hours ago, but two messages I've sent have been bounced. So I tried to re-confirm since I still had the message, and that bounced with the 'confirmation string invalid'. I'm about up to my eyeballs in gnu BS, its not worth the effort to talk to those fence posts. I'd write a cron script to hit them every 10 minutes, but I don't need the bounces. If you can get in, tell them to fix their (*&^$ mail server to accept messages from somebody newly subscribed. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) YOU HAVE AN I/O ERROR -> Incompetent Operator error
Re: NFS mount tar incremental problem
On Tuesday 25 March 2008, Gene Heskett wrote: >On Tuesday 25 March 2008, Dustin J. Mitchell wrote: >>On Tue, Mar 25, 2008 at 11:31 AM, Gene Heskett <[EMAIL PROTECTED]> > >wrote: >>> And I, like an idiot, didn't notice we were discussing an NFS problem, >>> which may be another manifestation of the same problem, but that patch >>> does not address what happens when the linux device mapper decides to >>> move an LVM2 volume from 253,0 ro 254,0. >> >>The patch JLM posted won't fix it, but his proposed command-line option >> will. > >Post please, I don't believe I've seen it. I had some email problems over > the weekend due to my / partition being in bad need of an fsck. 2.6.24 > running tickless was a friggin nightmare. > >>> Thats why I'm asking about Schiling Tar, aka S-Tar. Does that fix the >>> problem?, and can amanda use it? >> >>Yes, but its semantics are very different from GNU Tar -- it's not a >>drop-in fix. > >I was afraid of that. > >>> The ultimate weapon of course in any philosophical war, which this is, >>> is to fork tar and fix it if STar isn't usable. At this point, and while >>> I'm not capable of doing it, I'm not a bit allergic to the fork idea. >>> Its bitten me so often that I'll alpha test anybodies efforts in that >>> regard. Gleefully. >> >>Sure, but threatening a fork is un-diplomatic, and not called for just >>yet. Let's start with a concerted public-relations effort :) > >I doubt if my messages on the subject were the only ones they got, and from >the attitude displayed in the replies I got, a fork IS the next step. They >are immovable on the subject. They consider that a change in the device >mapping numbers are prima-faci evidence of a stolen tar file trying to be >recovered to a disk that they don't belong to. A huge security problem in >their view. > >>> Humm, didn't we have some scripts that could inspect and repair the >>> index files when this happened? Probably lost when I woke up one morning >>> and found my well developed FC6 install wasn't re-bootable, LSN0 on >>> /dev/hda had one non-zero byte left in it. >> >>Yep -- it's called tar-snapshot-edit, and it's available in recent >>releases of GNU Tar. Just google for it. > >I'll do that, got it. > >Thanks, Dustin. To continue this thread I have now subscribed to the bug-tar list about 24 hours ago, but two messages I've sent have been bounced. So I tried to re-confirm since I still had the message, and that bounced with the 'confirmation string invalid'. I'm about up to my eyeballs in gnu BS, its not worth the effort to talk to those fence posts. I'd write a cron script to hit them every 10 minutes, but I don't need the bounces. If you can get in, tell them to fix their (*&^$ mail server to accept messages from somebody newly subscribed. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) YOU HAVE AN I/O ERROR -> Incompetent Operator error
Re: NFS mount tar incremental problem
On Tuesday 25 March 2008, Dustin J. Mitchell wrote: >On Tue, Mar 25, 2008 at 11:31 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> And I, like an idiot, didn't notice we were discussing an NFS problem, >> which may be another manifestation of the same problem, but that patch >> does not address what happens when the linux device mapper decides to move >> an LVM2 volume from 253,0 ro 254,0. > >The patch JLM posted won't fix it, but his proposed command-line option > will. Post please, I don't believe I've seen it. I had some email problems over the weekend due to my / partition being in bad need of an fsck. 2.6.24 running tickless was a friggin nightmare. >> Thats why I'm asking about Schiling Tar, aka S-Tar. Does that fix the >> problem?, and can amanda use it? > >Yes, but its semantics are very different from GNU Tar -- it's not a >drop-in fix. I was afraid of that. >> The ultimate weapon of course in any philosophical war, which this is, is >> to fork tar and fix it if STar isn't usable. At this point, and while I'm >> not capable of doing it, I'm not a bit allergic to the fork idea. Its >> bitten me so often that I'll alpha test anybodies efforts in that regard. >> Gleefully. > >Sure, but threatening a fork is un-diplomatic, and not called for just >yet. Let's start with a concerted public-relations effort :) I doubt if my messages on the subject were the only ones they got, and from the attitude displayed in the replies I got, a fork IS the next step. They are immovable on the subject. They consider that a change in the device mapping numbers are prima-faci evidence of a stolen tar file trying to be recovered to a disk that they don't belong to. A huge security problem in their view. >> Humm, didn't we have some scripts that could inspect and repair the index >> files when this happened? Probably lost when I woke up one morning and >> found my well developed FC6 install wasn't re-bootable, LSN0 on /dev/hda >> had one non-zero byte left in it. > >Yep -- it's called tar-snapshot-edit, and it's available in recent >releases of GNU Tar. Just google for it. I'll do that, got it. Thanks, Dustin. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The end of labor is to gain leisure.
Re: NFS mount tar incremental problem
On Tue, Mar 25, 2008 at 11:31 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: > And I, like an idiot, didn't notice we were discussing an NFS problem, which > may be another manifestation of the same problem, but that patch does not > address what happens when the linux device mapper decides to move an LVM2 > volume from 253,0 ro 254,0. The patch JLM posted won't fix it, but his proposed command-line option will. > Thats why I'm asking about Schiling Tar, aka S-Tar. Does that fix the > problem?, and can amanda use it? Yes, but its semantics are very different from GNU Tar -- it's not a drop-in fix. > The ultimate weapon of course in any philosophical war, which this is, is to > fork tar and fix it if STar isn't usable. At this point, and while I'm not > capable of doing it, I'm not a bit allergic to the fork idea. Its bitten me > so often that I'll alpha test anybodies efforts in that regard. Gleefully. Sure, but threatening a fork is un-diplomatic, and not called for just yet. Let's start with a concerted public-relations effort :) > Humm, didn't we have some scripts that could inspect and repair the index > files when this happened? Probably lost when I woke up one morning and found > my well developed FC6 install wasn't re-bootable, LSN0 on /dev/hda had one > non-zero byte left in it. Yep -- it's called tar-snapshot-edit, and it's available in recent releases of GNU Tar. Just google for it. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: NFS mount tar incremental problem
On Tuesday 25 March 2008, Dustin J. Mitchell wrote: >> But the tar people don't want to hear it, their attitude is to fix the os >> instead, I've exchanged emails with them in 2 flurries now. They are >> congentially incapable of understanding the problem I believe. > >Jean-Louis posted a patch there recently to fix the NFS detection, >which goes halfway to fixing the problem, and proposed a complete fix. > >I think we should start a letter-writing campaign in support of his >patch: everyone who's been following this issue, please head over to >bug-tar and make some noise. > >http://mail.gnu.org/mailman/listinfo/bug-tar -- subscribe >http://lists.gnu.org/archive/html/bug-tar/2008-03/msg00023.html -- >Jean-Louis' patch post >http://www.mail-archive.com/[EMAIL PROTECTED]/msg01767.html -- Jordan >Desroche's post > >google can help you find some more posts. > >Dustin And I, like an idiot, didn't notice we were discussing an NFS problem, which may be another manifestation of the same problem, but that patch does not address what happens when the linux device mapper decides to move an LVM2 volume from 253,0 ro 254,0. Thats why I'm asking about Schiling Tar, aka S-Tar. Does that fix the problem?, and can amanda use it? The ultimate weapon of course in any philosophical war, which this is, is to fork tar and fix it if STar isn't usable. At this point, and while I'm not capable of doing it, I'm not a bit allergic to the fork idea. Its bitten me so often that I'll alpha test anybodies efforts in that regard. Gleefully. In the meantime I have a script I think I'l fire up and let run till amanda catches up with yet another device-mapper screwup. Humm, didn't we have some scripts that could inspect and repair the index files when this happened? Probably lost when I woke up one morning and found my well developed FC6 install wasn't re-bootable, LSN0 on /dev/hda had one non-zero byte left in it. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) We are all in the gutter, but some of us are looking at the stars. -- Oscar Wilde
Re: NFS mount tar incremental problem
> But the tar people don't want to hear it, their attitude is to fix the os > instead, I've exchanged emails with them in 2 flurries now. They are > congentially incapable of understanding the problem I believe. Jean-Louis posted a patch there recently to fix the NFS detection, which goes halfway to fixing the problem, and proposed a complete fix. I think we should start a letter-writing campaign in support of his patch: everyone who's been following this issue, please head over to bug-tar and make some noise. http://mail.gnu.org/mailman/listinfo/bug-tar -- subscribe http://lists.gnu.org/archive/html/bug-tar/2008-03/msg00023.html -- Jean-Louis' patch post http://www.mail-archive.com/[EMAIL PROTECTED]/msg01767.html -- Jordan Desroche's post google can help you find some more posts. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: NFS mount tar incremental problem
On Friday 25 January 2008, Paul Bijnens wrote: >On 2008-01-25 02:08, Jordan Desroches wrote: >> To answer a portion of my own question, the linux command (for the NFS >> mount point /mnt/thayer/home): >> >> $stat --format=%d /mnt/thayerfs/home >> >> will give the decimal device number necessary to run the >> tar-snapshot-edit script. It still doesn't answer the more puzzling >> question of why tar is not picking up mount as NFS as the documentation >> says it should. > >The idea to use the device number to identify the device is wrong. >Quoting Linus himself: > "The device number is a random cookie, not a unique identifier." > > http://lwn.net/Articles/65195/ > >It used to be that the "device number" was a static number >(e.g. something like "device number = major*256+minor", in the days >when major and minor numbers where hardcoded in the kernel). > >The right way currently is to not consider the "device number" >to unique identify a system. It is only unique among the currently >other device numbers present on the system, but the same device >when unmounted/remounted is not guaranteed to get the same >device number again. That is why udev was invented, and there >you can use some other property of the device to get a static >name: > > http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs > >Gnutar still relies on the fact that the device number is >static and does never change, not even after a reconfiguration >of the devices (e.g. a reboot, or remove/reattach of a device). > >> Best, >> >> Jordan >> >> On Jan 23, 2008, at 9:29 PM, Jordan Desroches wrote: >>> I've dug further into the gnutar-lists directory, and I think I know >>> what is causing the problem, but I don't quite know what to do about >>> it. I have a NFS mounted directory /mnt/thayerfs/home >>> >>> Here is a section of the incremental file from 1/19/08: >>> >>> [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/chen.. >>> >>> here from 1/20/08: >>> >>> [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/gre. >>> >>> here from 1/21/08: >>> >>> [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/sp >>> >>> here from the 1/22/08: >>> >>> [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/oli >>> >>> and here, from 1/23/08: >>> >>> [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/st. >>> >>> The first thing that raises my concern is the leading 0. I believe, >>> according the tar docs, that indicates that tar is NOT detecting the >>> mount as a NFS mounted partition. If it had detected it as an NFS >>> partition (which is would do because apparently tar takes different >>> action with NFS paritions), there would be a leading 1. >>> >>> The second thing is that that the device number changes between the >>> 22nd and the 23rd from 23 to 22. There was a reboot between those days. >>> >>> Is there a way of preventing the device number from changing? If not, >>> then is the knowledge of the device number enough to run the script >>> Paul suggested? If running the script is the solution (and to ask a >>> potentially, and I hope simple question), how do I determine the >>> device number of a NFS mounted partition to tell the script to change it? >>> >>> Thanks for your help :-) >>> >>> Jordan >>> >>> On Jan 23, 2008, at 11:19 AM, Paul Bijnens wrote: Jordan Desroches wrote: > Hello all, > I've been having a problem with incremental dumps on a NFS mounted > Netapp. AMANDA runs great until I reboot the client (or remount the > NFS shares on the client). At that point, while calcsize predicts > what I believe is the correct incremental dump size, tar proceeds to > do a full dump of all the NFS mounted files. I believe this has to > due with something changing between mounts that tar is translating > as a change to all files. Upon reading some of the documentation for > tar, it indicated that in the incremental dump gnutar-lists, there > should be a "1" preceding every entry to indicate that the file is > NFS mounted because (Quoting > http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html"; >): > > "Metadata stored in snapshot files include device numbers, which, > obviously is supposed to be a non-volatile value. However, it turns > out that NFS devices have undependable values when an automounter > gets in the picture. This can lead to a great deal of spurious > redumping in incremental dumps, so it is somewhat useless to compare > two NFS devices numbers over time. The solution implemented > currently is to considers all NFS devices as being equal when it > comes to comparing directories; this is fairly gross, but there does > not seem to be a better way to go." > Here is an example from one of my gnutar-lists, showing what I > believe are preceding zeroes, indicating that tar thinks that the > files are not on NFS: > [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTE
Re: NFS mount tar incremental problem
On 2008-01-25 02:08, Jordan Desroches wrote: To answer a portion of my own question, the linux command (for the NFS mount point /mnt/thayer/home): $stat --format=%d /mnt/thayerfs/home will give the decimal device number necessary to run the tar-snapshot-edit script. It still doesn't answer the more puzzling question of why tar is not picking up mount as NFS as the documentation says it should. The idea to use the device number to identify the device is wrong. Quoting Linus himself: "The device number is a random cookie, not a unique identifier." http://lwn.net/Articles/65195/ It used to be that the "device number" was a static number (e.g. something like "device number = major*256+minor", in the days when major and minor numbers where hardcoded in the kernel). The right way currently is to not consider the "device number" to unique identify a system. It is only unique among the currently other device numbers present on the system, but the same device when unmounted/remounted is not guaranteed to get the same device number again. That is why udev was invented, and there you can use some other property of the device to get a static name: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs Gnutar still relies on the fact that the device number is static and does never change, not even after a reconfiguration of the devices (e.g. a reboot, or remove/reattach of a device). Best, Jordan On Jan 23, 2008, at 9:29 PM, Jordan Desroches wrote: I've dug further into the gnutar-lists directory, and I think I know what is causing the problem, but I don't quite know what to do about it. I have a NFS mounted directory /mnt/thayerfs/home Here is a section of the incremental file from 1/19/08: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/chen.. here from 1/20/08: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/gre. here from 1/21/08: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/sp here from the 1/22/08: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/oli and here, from 1/23/08: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/st. The first thing that raises my concern is the leading 0. I believe, according the tar docs, that indicates that tar is NOT detecting the mount as a NFS mounted partition. If it had detected it as an NFS partition (which is would do because apparently tar takes different action with NFS paritions), there would be a leading 1. The second thing is that that the device number changes between the 22nd and the 23rd from 23 to 22. There was a reboot between those days. Is there a way of preventing the device number from changing? If not, then is the knowledge of the device number enough to run the script Paul suggested? If running the script is the solution (and to ask a potentially, and I hope simple question), how do I determine the device number of a NFS mounted partition to tell the script to change it? Thanks for your help :-) Jordan On Jan 23, 2008, at 11:19 AM, Paul Bijnens wrote: Jordan Desroches wrote: Hello all, I've been having a problem with incremental dumps on a NFS mounted Netapp. AMANDA runs great until I reboot the client (or remount the NFS shares on the client). At that point, while calcsize predicts what I believe is the correct incremental dump size, tar proceeds to do a full dump of all the NFS mounted files. I believe this has to due with something changing between mounts that tar is translating as a change to all files. Upon reading some of the documentation for tar, it indicated that in the incremental dump gnutar-lists, there should be a "1" preceding every entry to indicate that the file is NFS mounted because (Quoting http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html";): "Metadata stored in snapshot files include device numbers, which, obviously is supposed to be a non-volatile value. However, it turns out that NFS devices have undependable values when an automounter gets in the picture. This can lead to a great deal of spurious redumping in incremental dumps, so it is somewhat useless to compare two NFS devices numbers over time. The solution implemented currently is to considers all NFS devices as being equal when it comes to comparing directories; this is fairly gross, but there does not seem to be a better way to go." Here is an example from one of my gnutar-lists, showing what I believe are preceding zeroes, indicating that tar thinks that the files are not on NFS: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/unclaimed_afs/nmlhome/mcbride/.desktop-nauset.dartmouth.edu/[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@./spacescience/web/wl/per/[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
Re: NFS mount tar incremental problem
To answer a portion of my own question, the linux command (for the NFS
mount point /mnt/thayer/home):
$stat --format=%d /mnt/thayerfs/home
will give the decimal device number necessary to run the tar-snapshot-
edit script. It still doesn't answer the more puzzling question of why
tar is not picking up mount as NFS as the documentation says it should.
Best,
Jordan
On Jan 23, 2008, at 9:29 PM, Jordan Desroches wrote:
I've dug further into the gnutar-lists directory, and I think I know
what is causing the problem, but I don't quite know what to do about
it. I have a NFS mounted directory /mnt/thayerfs/home
Here is a section of the incremental file from 1/19/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/chen..
here from 1/20/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/gre.
here from 1/21/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/sp
here from the 1/22/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/oli
and here, from 1/23/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/st.
The first thing that raises my concern is the leading 0. I believe,
according the tar docs, that indicates that tar is NOT detecting the
mount as a NFS mounted partition. If it had detected it as an NFS
partition (which is would do because apparently tar takes different
action with NFS paritions), there would be a leading 1.
The second thing is that that the device number changes between the
22nd and the 23rd from 23 to 22. There was a reboot between those
days.
Is there a way of preventing the device number from changing? If
not, then is the knowledge of the device number enough to run the
script Paul suggested? If running the script is the solution (and to
ask a potentially, and I hope simple question), how do I determine
the device number of a NFS mounted partition to tell the script to
change it?
Thanks for your help :-)
Jordan
On Jan 23, 2008, at 11:19 AM, Paul Bijnens wrote:
Jordan Desroches wrote:
Hello all,
I've been having a problem with incremental dumps on a NFS mounted
Netapp. AMANDA runs great until I reboot the client (or remount
the NFS shares on the client). At that point, while calcsize
predicts what I believe is the correct incremental dump size, tar
proceeds to do a full dump of all the NFS mounted files. I believe
this has to due with something changing between mounts that tar is
translating as a change to all files. Upon reading some of the
documentation for tar, it indicated that in the incremental dump
gnutar-lists, there should be a "1" preceding every entry to
indicate that the file is NFS mounted because (Quoting http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html
"):
"Metadata stored in snapshot files include device numbers, which,
obviously is supposed to be a non-volatile value. However, it
turns out that NFS devices have undependable values when an
automounter gets in the picture. This can lead to a great deal of
spurious redumping in incremental dumps, so it is somewhat useless
to compare two NFS devices numbers over time. The solution
implemented currently is to considers all NFS devices as being
equal when it comes to comparing directories; this is fairly
gross, but there does not seem to be a better way to go."
Here is an example from one of my gnutar-lists, showing what I
believe are preceding zeroes, indicating that tar thinks that the
files are not on NFS:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/
unclaimed_afs/nmlhome/mcbride/.desktop-nauset.dartmouth.edu/
0.0
^
@Y4Dwmdeskname
^
@Y4Dwmdesks
^
@Y4Dwmdesks
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/spacescience/web/wl/per/[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
^
@YIMG_0119
.jpg
^
@YIMG_0120
.jpg
^
@YIMG_0121
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/paulsen/
MAC_Keith/Mac_NIH/Proposals/Breast PPG/Original Proposal '98/
Letters^@
Here's how the FS is mounted in /etc/fstab:
192.168.0.2:/vol/research /mnt/thayerfs/research nfs
hard,rsize=32768,wsize=327680 0
And here is an example disk list entry:
tardis /mnt/thayerfs/research_p-z /mnt/thayerfs/research {
nocomp-test
include "./[p-zP-Z]*"
}
Has anyone run into this problem, or know how to fix it?
Very related to this:
http://wiki.zmanda.com/index.php/Tar_dumps_every_file_in_a_level-1_backup_after_a_hardware_change
and fixing (each time you have the change!!) it with this script:
http://www.gnu.org/software/tar/utils/tar-snapshot-edit.html
This is actually a gnutar problem...
--
Paul Bijnens, xplanation Technology ServicesTel +32 16
397.511
Technologielaan 21 bus 2, B-3001 Leuv
Re: NFS mount tar incremental problem
I've dug further into the gnutar-lists directory, and I think I know
what is causing the problem, but I don't quite know what to do about
it. I have a NFS mounted directory /mnt/thayerfs/home
Here is a section of the incremental file from 1/19/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/chen..
here from 1/20/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/gre.
here from 1/21/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/sp
here from the 1/22/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/oli
and here, from 1/23/08:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/st.
The first thing that raises my concern is the leading 0. I believe,
according the tar docs, that indicates that tar is NOT detecting the
mount as a NFS mounted partition. If it had detected it as an NFS
partition (which is would do because apparently tar takes different
action with NFS paritions), there would be a leading 1.
The second thing is that that the device number changes between the
22nd and the 23rd from 23 to 22. There was a reboot between those days.
Is there a way of preventing the device number from changing? If not,
then is the knowledge of the device number enough to run the script
Paul suggested? If running the script is the solution (and to ask a
potentially, and I hope simple question), how do I determine the
device number of a NFS mounted partition to tell the script to change
it?
Thanks for your help :-)
Jordan
On Jan 23, 2008, at 11:19 AM, Paul Bijnens wrote:
Jordan Desroches wrote:
Hello all,
I've been having a problem with incremental dumps on a NFS mounted
Netapp. AMANDA runs great until I reboot the client (or remount the
NFS shares on the client). At that point, while calcsize predicts
what I believe is the correct incremental dump size, tar proceeds
to do a full dump of all the NFS mounted files. I believe this has
to due with something changing between mounts that tar is
translating as a change to all files. Upon reading some of the
documentation for tar, it indicated that in the incremental dump
gnutar-lists, there should be a "1" preceding every entry to
indicate that the file is NFS mounted because (Quoting http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html
"):
"Metadata stored in snapshot files include device numbers, which,
obviously is supposed to be a non-volatile value. However, it turns
out that NFS devices have undependable values when an automounter
gets in the picture. This can lead to a great deal of spurious
redumping in incremental dumps, so it is somewhat useless to
compare two NFS devices numbers over time. The solution implemented
currently is to considers all NFS devices as being equal when it
comes to comparing directories; this is fairly gross, but there
does not seem to be a better way to go."
Here is an example from one of my gnutar-lists, showing what I
believe are preceding zeroes, indicating that tar thinks that the
files are not on NFS:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/unclaimed_afs/
nmlhome/mcbride/.desktop-nauset.dartmouth.edu/[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/spacescience/web/wl/per/[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
^
@YIMG_0119
.jpg
^
@YIMG_0120
.jpg
^
@YIMG_0121
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/paulsen/
MAC_Keith/Mac_NIH/Proposals/Breast PPG/Original Proposal '98/
Letters^@
Here's how the FS is mounted in /etc/fstab:
192.168.0.2:/vol/research /mnt/thayerfs/research nfs
hard,rsize=32768,wsize=327680 0
And here is an example disk list entry:
tardis /mnt/thayerfs/research_p-z /mnt/thayerfs/research {
nocomp-test
include "./[p-zP-Z]*"
}
Has anyone run into this problem, or know how to fix it?
Very related to this:
http://wiki.zmanda.com/index.php/Tar_dumps_every_file_in_a_level-1_backup_after_a_hardware_change
and fixing (each time you have the change!!) it with this script:
http://www.gnu.org/software/tar/utils/tar-snapshot-edit.html
This is actually a gnutar problem...
--
Paul Bijnens, xplanation Technology ServicesTel +32 16
397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16
397.512
http://www.xplanation.com/ email:
[EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q,
^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /
bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort,
hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$
Re: NFS mount tar incremental problem
I agree the problem is with gnutar, and also agree that the root cause
of my problem, and the cause of the problem that Paul described and
linked to, are the same: some attribute (either major/minor with a
file system, or with NFS, FSID) is changing that is fooling gnutar
into thinking every file has changed when it hasn't. However, the
problems are different in that I can't figure out what in the world is
changing between reboots fool gnutar in my case. No hardware changes
are occurring that would change the major/minor number on my disk. How
can I find what the FSID is for a mount to see if that is somehow
changing? What else would cause tar to act like this? I do not believe
the script that Paul linked is not useful in this case, as I can't
figure out what has changed to tell the script to correct it :-)
Thanks,
Jordan
On Jan 23, 2008, at 11:19 AM, Paul Bijnens wrote:
Jordan Desroches wrote:
Hello all,
I've been having a problem with incremental dumps on a NFS mounted
Netapp. AMANDA runs great until I reboot the client (or remount the
NFS shares on the client). At that point, while calcsize predicts
what I believe is the correct incremental dump size, tar proceeds
to do a full dump of all the NFS mounted files. I believe this has
to due with something changing between mounts that tar is
translating as a change to all files. Upon reading some of the
documentation for tar, it indicated that in the incremental dump
gnutar-lists, there should be a "1" preceding every entry to
indicate that the file is NFS mounted because (Quoting http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html
"):
"Metadata stored in snapshot files include device numbers, which,
obviously is supposed to be a non-volatile value. However, it turns
out that NFS devices have undependable values when an automounter
gets in the picture. This can lead to a great deal of spurious
redumping in incremental dumps, so it is somewhat useless to
compare two NFS devices numbers over time. The solution implemented
currently is to considers all NFS devices as being equal when it
comes to comparing directories; this is fairly gross, but there
does not seem to be a better way to go."
Here is an example from one of my gnutar-lists, showing what I
believe are preceding zeroes, indicating that tar thinks that the
files are not on NFS:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/unclaimed_afs/
nmlhome/mcbride/.desktop-nauset.dartmouth.edu/[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/spacescience/web/wl/per/[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]
^
@YIMG_0119
.jpg
^
@YIMG_0120
.jpg
^
@YIMG_0121
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/paulsen/
MAC_Keith/Mac_NIH/Proposals/Breast PPG/Original Proposal '98/
Letters^@
Here's how the FS is mounted in /etc/fstab:
192.168.0.2:/vol/research /mnt/thayerfs/research nfs
hard,rsize=32768,wsize=327680 0
And here is an example disk list entry:
tardis /mnt/thayerfs/research_p-z /mnt/thayerfs/research {
nocomp-test
include "./[p-zP-Z]*"
}
Has anyone run into this problem, or know how to fix it?
Very related to this:
http://wiki.zmanda.com/index.php/Tar_dumps_every_file_in_a_level-1_backup_after_a_hardware_change
and fixing (each time you have the change!!) it with this script:
http://www.gnu.org/software/tar/utils/tar-snapshot-edit.html
This is actually a gnutar problem...
--
Paul Bijnens, xplanation Technology ServicesTel +32 16
397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16
397.512
http://www.xplanation.com/ email:
[EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q,
^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /
bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort,
hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$,
shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-
A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm
out *
***
Re: NFS mount tar incremental problem
Jordan Desroches wrote:
Hello all,
I've been having a problem with incremental dumps on a NFS mounted
Netapp. AMANDA runs great until I reboot the client (or remount the NFS
shares on the client). At that point, while calcsize predicts what I
believe is the correct incremental dump size, tar proceeds to do a full
dump of all the NFS mounted files. I believe this has to due with
something changing between mounts that tar is translating as a change to
all files. Upon reading some of the documentation for tar, it indicated
that in the incremental dump gnutar-lists, there should be a "1"
preceding every entry to indicate that the file is NFS mounted because
(Quoting
http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html";):
"Metadata stored in snapshot files include device numbers, which,
obviously is supposed to be a non-volatile value. However, it turns out
that NFS devices have undependable values when an automounter gets in
the picture. This can lead to a great deal of spurious redumping in
incremental dumps, so it is somewhat useless to compare two NFS devices
numbers over time. The solution implemented currently is to considers
all NFS devices as being equal when it comes to comparing directories;
this is fairly gross, but there does not seem to be a better way to go."
Here is an example from one of my gnutar-lists, showing what I believe
are preceding zeroes, indicating that tar thinks that the files are not
on NFS:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/unclaimed_afs/nmlhome/mcbride/.desktop-nauset.dartmouth.edu/[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@./spacescience/web/wl/per/[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@./paulsen/MAC_Keith/Mac_NIH/Proposals/Breast
PPG/Original Proposal '98/Letters^@
Here's how the FS is mounted in /etc/fstab:
192.168.0.2:/vol/research /mnt/thayerfs/research nfs
hard,rsize=32768,wsize=327680 0
And here is an example disk list entry:
tardis /mnt/thayerfs/research_p-z /mnt/thayerfs/research {
nocomp-test
include "./[p-zP-Z]*"
}
Has anyone run into this problem, or know how to fix it?
Very related to this:
http://wiki.zmanda.com/index.php/Tar_dumps_every_file_in_a_level-1_backup_after_a_hardware_change
and fixing (each time you have the change!!) it with this script:
http://www.gnu.org/software/tar/utils/tar-snapshot-edit.html
This is actually a gnutar problem...
--
Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***
