Re: new splitsize warning (Was: Amanda's future?)
On Monday 01 March 2010, Dustin J. Mitchell wrote: On Sun, Feb 28, 2010 at 3:04 PM, Gene Heskett gene.hesk...@verizon.net wrote: Is this a case where verbosity is a positive? WARNING: shop /home: fallback_splitsize of 10M is 0.1% of tape length. This may create 1000 parts, severely degrading backup/restore performance. To remedy, create/set a split_diskbuffer or increase fallback_splitsize See appropriate_URL for more information. jl Yes I think so Jon, but in my case I have over 800GB of /dumps available, so this particular item somewhat resembles a cry of wolf, when its just a I committed a change to make this warning look almost exactly as Jon described. I also wrote up a nice wiki article on the topic: http://wiki.zmanda.com/index.php/Splitsize_too_small Please edit it up if you see room for improvements. Dustin Looks good to me, Dustin. In my case, I had converted all local DLE's to using dt_amgtar, but didn't realize that this format also required all the stuff that was included in the global definition for completeness. Since the 'out on the network' DLE's are still using the global definitions, I corrected both, and now amcheck seems to be happy. -- 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) Option Paralysis: The tendency, when given unlimited choices, to make none. -- Douglas Coupland, Generation X: Tales for an Accelerated Culture
Re: new splitsize warning (Was: Amanda's future?)
On Sun, Feb 28, 2010 at 3:04 PM, Gene Heskett gene.hesk...@verizon.net wrote: Is this a case where verbosity is a positive? WARNING: shop /home: fallback_splitsize of 10M is 0.1% of tape length. This may create 1000 parts, severely degrading backup/restore performance. To remedy, create/set a split_diskbuffer or increase fallback_splitsize See appropriate_URL for more information. jl Yes I think so Jon, but in my case I have over 800GB of /dumps available, so this particular item somewhat resembles a cry of wolf, when its just a I committed a change to make this warning look almost exactly as Jon described. I also wrote up a nice wiki article on the topic: http://wiki.zmanda.com/index.php/Splitsize_too_small Please edit it up if you see room for improvements. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Amanda's future?
On Sunday 28 February 2010, Dustin J. Mitchell wrote: On Sat, Feb 27, 2010 at 7:34 PM, Gene Heskett gene.hesk...@verizon.net wrote: I am sorry Dustin, but the permissions problem alluded to earlier does not seem to be fixed yet so the old link still shows the 20100131 versions as the newest, and the 'download tarball' buttons on all the sourceforge pages at the link above, while bringing up a requester asking what should firefox do with this file, with the save button already checked, do nothing when clicking on the ok. No file is downloaded. If I understand, you're talking about the Download GNU Tarball link on the SourceForge ViewVC pages. The link works for me, but even so it's not a very effective way to download snapshots: the resulting tarballs will not be the usual distribution tarballs, as they have not had their ./autogen scripts run. If you'd like, I can help you modify your test scripts to build straight from subversion instead of from snapshots. Breakage that continues for over 3 weeks now, does lead to questions, and the replies seem to intend to placate, but have done nothing of substance to restore our ability to continue our near daily testing of the bleeding edge. I don't mean to placate - we screwed up. But to be fair, you only brought it up at 9pm on a Friday! I'm sure it'll be sorted out soon. I used to see more updates on the weekends, and figured you both had other, buys the bread, duties during the week. I don't know exactly how Jean-Louis makes the snapshot tarballs, but I've made a distribution tarball built from the latest subversion, which should be similar, available here: http://djmitche.s3.amazonaws.com/amanda-2.6.2alpha.tar.gz Let me know if you have any trouble making it work. Just one niggle. It was not named internally in the tarball with the snapshot date. My build install script depends on that, so now I have a 2.6.2alpha install that when it comes time to do a cleanup of old versions, something I do about monthly, it will need a careful check of its file dates else I might remove the wrong library or some such. My script also cleans out any srcs it finds, and without the snapshot date, doesn't leave an old version behind so I have a ready made, backup to the previous tree left in /home/amanda that to recover to it, is a simple cd into the older directory followed by a make install as root. I tried to rename the tarball but that resulted in the tar.gz's deletion so I had to go get it 3 times. It did install, and amcheck ran normally, so we'll see how tonight's run goes. Needless to say, if I do this again, I'll overwrite this one, which isn't a 'Good Thing(TM)' so I will now rename that tree with today's date to prevent that. And that of course makes me wonder if I am indeed the only person doing any test builds and actual use of that test build at all. I certainly hope not. I hope not, too! Certainly the more people who test Amanda, the more quickly and effectively we will catch and solve bugs. I'm a big believer in testing, both automated and manual. It *is* disconcerting that nobody (not even you?) noticed this for, as you say, three weeks. With luck, this thread will encourage some new folks to begin regularly testing Amanda, especially the upcoming release. Given enough eyeballs, all bugs are shallow [1] Dustin [1] http://en.wikipedia.org/wiki/Linus'_Law My test scripts are attached. Quite simple. Not even a kilobyte combined. Syntax is: ./newmanada amandatarball-snapshotdate (without the .tar.gz) (as root) -- 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) |Rain| with sane code, maybe I could figure out the renderer :) LordHavoc rain: I'd probably be the one writing the renderer |Rain| well, er, uh newmanda Description: application/shellscript gh.cf Description: application/shellscript
Re: Amanda's future?
On Sunday 28 February 2010, Jean-Louis Martineau wrote: Gene, Neither Dustin nor me had the privilege to fix the permission issue. Permission get fixed, I uploaded the latest snapshot. Jean-Louis I see. I had thought that Dustin was doing his own hosting. This one installed ok, but the amcheck got mouthier: WARNING: shop /home: fallback_splitsize of 10240k 0.1% of tape size and may be used for PORT_DUMP; check your configuration A line for every dle. Is this something I need to address before tonights real run? Also, where do I find the definition of a PORT_DUMP? That is a new one to me. Thanks. -- 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) Your packets were eaten by the terminator
Re: Amanda's future?
Gene, Neither Dustin nor me had the privilege to fix the permission issue. Permission get fixed, I uploaded the latest snapshot. Jean-Louis Gene Heskett wrote: On Sunday 28 February 2010, Dustin J. Mitchell wrote: On Sat, Feb 27, 2010 at 7:34 PM, Gene Heskett gene.hesk...@verizon.net wrote: I am sorry Dustin, but the permissions problem alluded to earlier does not seem to be fixed yet so the old link still shows the 20100131 versions as the newest, and the 'download tarball' buttons on all the sourceforge pages at the link above, while bringing up a requester asking what should firefox do with this file, with the save button already checked, do nothing when clicking on the ok. No file is downloaded. If I understand, you're talking about the Download GNU Tarball link on the SourceForge ViewVC pages. The link works for me, but even so it's not a very effective way to download snapshots: the resulting tarballs will not be the usual distribution tarballs, as they have not had their ./autogen scripts run. If you'd like, I can help you modify your test scripts to build straight from subversion instead of from snapshots. Breakage that continues for over 3 weeks now, does lead to questions, and the replies seem to intend to placate, but have done nothing of substance to restore our ability to continue our near daily testing of the bleeding edge. I don't mean to placate - we screwed up. But to be fair, you only brought it up at 9pm on a Friday! I'm sure it'll be sorted out soon. I used to see more updates on the weekends, and figured you both had other, buys the bread, duties during the week. I don't know exactly how Jean-Louis makes the snapshot tarballs, but I've made a distribution tarball built from the latest subversion, which should be similar, available here: http://djmitche.s3.amazonaws.com/amanda-2.6.2alpha.tar.gz Let me know if you have any trouble making it work. Just one niggle. It was not named internally in the tarball with the snapshot date. My build install script depends on that, so now I have a 2.6.2alpha install that when it comes time to do a cleanup of old versions, something I do about monthly, it will need a careful check of its file dates else I might remove the wrong library or some such. My script also cleans out any srcs it finds, and without the snapshot date, doesn't leave an old version behind so I have a ready made, backup to the previous tree left in /home/amanda that to recover to it, is a simple cd into the older directory followed by a make install as root. I tried to rename the tarball but that resulted in the tar.gz's deletion so I had to go get it 3 times. It did install, and amcheck ran normally, so we'll see how tonight's run goes. Needless to say, if I do this again, I'll overwrite this one, which isn't a 'Good Thing(TM)' so I will now rename that tree with today's date to prevent that. And that of course makes me wonder if I am indeed the only person doing any test builds and actual use of that test build at all. I certainly hope not. I hope not, too! Certainly the more people who test Amanda, the more quickly and effectively we will catch and solve bugs. I'm a big believer in testing, both automated and manual. It *is* disconcerting that nobody (not even you?) noticed this for, as you say, three weeks. With luck, this thread will encourage some new folks to begin regularly testing Amanda, especially the upcoming release. Given enough eyeballs, all bugs are shallow [1] Dustin [1] http://en.wikipedia.org/wiki/Linus'_Law My test scripts are attached. Quite simple. Not even a kilobyte combined. Syntax is: ./newmanada amandatarball-snapshotdate (without the .tar.gz) (as root)
new splitsize warning (Was: Amanda's future?)
I'm glad my tarball worked for you. I'll find out from Jean-Louis how to generate snapshots with the datestamp, in case I need to do so in the future. But you've brought up a new topic, so I've changed the subject line: On Sun, Feb 28, 2010 at 8:40 AM, Gene Heskett gene.hesk...@verizon.net wrote: WARNING: shop /home: fallback_splitsize of 10240k 0.1% of tape size and may be used for PORT_DUMP; check your configuration A line for every dle. Is this something I need to address before tonights real run? Yes, I just added this warning. Some refinement may be in order, so let me know what you think. The problem is that Amanda's fallback_splitsize defaults to 10M, and I've seen a number of users recently who are using this splitsize for multi-terabyte dumps, without knowing it. This generates *terrible* performance on backup, since the tape drive has to write tens or hundreds of thousands of filemarks, and also on recovery, since the recovery app must seek to and read from each of those many thousands of files. This is usually due not to a fallback in an error condition, but to misconfiguration. The splitsize parameters are *very* confusing! So the new warning is intended to alert folks such as yourself to the potential misconfiguration. It's just a warning, so Amanda will continue to run as before, but you really should fix it. To fix it, do one of: * set split_diskbuffer properly * raise your fallback_splitsize to something larger than 0.001 * tape-length * set fallback_splitsize to 0 Also, where do I find the definition of a PORT_DUMP? That is a new one to me. Oops, that should say PORT-WRITE. PORT-WRITE is a dump straight to the device, without going to holding first. Amanda does PORT-WRITE when the DLE is larger than the holding disk, or when no holding disk is configured. It is the opposite of FILE-WRITE, which is a write from holding disk to the tape device. Amanda always uses the tape_splitsize for FILE-WRITE dumps. It does the same for PORT-WRITE, but if split_diskbuffer is not set, which is the case on your system, then it uses fallback_splitsize instead (with its default of 10M), with no notice of the fallback. So what if I changed the warning to read WARNING: shop /home: fallback_splitsize of 10240k 0.1% of tape length and may create 1000 parts; set split_diskbuffer or increase fallback_splitsize I'll also add a wiki page to help explain the background for the error. Let me know what you think. Dustin P.S. There are plans afoot to change these configuration parameters to something less confusing, but not in the upcoming release. -- Open Source Storage Engineer http://www.zmanda.com
Re: new splitsize warning (Was: Amanda's future?)
On Sun, Feb 28, 2010 at 10:59:23AM -0600, Dustin J. Mitchell wrote: ... Yes, I just added this warning. Some refinement may be in order, so let me know what you think. The problem is that Amanda's fallback_splitsize defaults to 10M, and I've seen a number of users recently who are using this splitsize for multi-terabyte dumps, without knowing it. This generates *terrible* performance on backup, since the tape drive has to write tens or hundreds of thousands of filemarks, and also on recovery, since the recovery app must seek to and read from each of those many thousands of files. This is usually due not to a fallback in an error condition, but to misconfiguration. The splitsize parameters are *very* confusing! So the new warning is intended to alert folks such as yourself to the potential misconfiguration. It's just a warning, so Amanda will continue to run as before, but you really should fix it. To fix it, do one of: * set split_diskbuffer properly * raise your fallback_splitsize to something larger than 0.001 * tape-length * set fallback_splitsize to 0 ... Amanda always uses the tape_splitsize for FILE-WRITE dumps. It does the same for PORT-WRITE, but if split_diskbuffer is not set, which is the case on your system, then it uses fallback_splitsize instead (with its default of 10M), with no notice of the fallback. So what if I changed the warning to read WARNING: shop /home: fallback_splitsize of 10240k 0.1% of tape length and may create 1000 parts; set split_diskbuffer or increase fallback_splitsize Is this a case where verbosity is a positive? WARNING: shop /home: fallback_splitsize of 10M is 0.1% of tape length. This may create 1000 parts, severely degrading backup/restore performance. To remedy, create/set a split_diskbuffer or increase fallback_splitsize See appropriate_URL for more information. jl -- Jon H. LaBadie j...@jgcomp.com JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
Re: new splitsize warning (Was: Amanda's future?)
On Sun, Feb 28, 2010 at 12:17 PM, Jon LaBadie j...@jgcomp.com wrote: Is this a case where verbosity is a positive? WARNING: shop /home: fallback_splitsize of 10M is 0.1% of tape length. This may create 1000 parts, severely degrading backup/restore performance. To remedy, create/set a split_diskbuffer or increase fallback_splitsize See appropriate_URL for more information. Gene mentioned that the error occurs for every one of his DLEs, which I expect will be the common case. So maybe this verbosity should occur only once in the amcheck output: WARNING: shop /home: fallback_splitsize of 10M is 0.1% of tape length. This may create 1000 parts, severely degrading backup/restore performance. To remedy, create/set a split_diskbuffer or increase fallback_splitsize See appropriate_URL for more information. WARNING: shop /usr: fallback_splitsize of 10M is 0.1% of tape length. WARNING: shop /var: fallback_splitsize of 10M is 0.1% of tape length. ... Thanks! Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: new splitsize warning (Was: Amanda's future?)
On Sunday 28 February 2010, Dustin J. Mitchell wrote: I'm glad my tarball worked for you. I'll find out from Jean-Louis how to generate snapshots with the datestamp, in case I need to do so in the future. But you've brought up a new topic, so I've changed the subject line: On Sun, Feb 28, 2010 at 8:40 AM, Gene Heskett gene.hesk...@verizon.net wrote: WARNING: shop /home: fallback_splitsize of 10240k 0.1% of tape size and may be used for PORT_DUMP; check your configuration A line for every dle. Is this something I need to address before tonights real run? Yes, I just added this warning. Some refinement may be in order, so let me know what you think. The problem is that Amanda's fallback_splitsize defaults to 10M, and I've seen a number of users recently who are using this splitsize for multi-terabyte dumps, without knowing it. This generates *terrible* performance on backup, since the tape drive has to write tens or hundreds of thousands of filemarks, and also on recovery, since the recovery app must seek to and read from each of those many thousands of files. OhmyGawd. Plumb deadly for tape users. This is usually due not to a fallback in an error condition, but to misconfiguration. The splitsize parameters are *very* confusing! I almost understood them, so it can't be too bad, but then it doesn't seem to be a consideration here. ;-) So the new warning is intended to alert folks such as yourself to the potential misconfiguration. It's just a warning, so Amanda will continue to run as before, but you really should fix it. To fix it, do one of: * set split_diskbuffer properly * raise your fallback_splitsize to something larger than 0.001 * tape-length * set fallback_splitsize to 0 Also, where do I find the definition of a PORT_DUMP? That is a new one to me. Oops, that should say PORT-WRITE. PORT-WRITE is a dump straight to the device, without going to holding first. Amanda does PORT-WRITE when the DLE is larger than the holding disk, or when no holding disk is configured. It is the opposite of FILE-WRITE, which is a write from holding disk to the tape device. Ahh, clarified, for me at least. As I have holding disk out the yang, and am using v-tapes anyway, it hadn't stuck up its hand and waved at me before. Would this not also result in individual split sized files I could see in my /amanatapes/Dailys partition? In which case it has only happened once that I'm aware of. Amanda always uses the tape_splitsize for FILE-WRITE dumps. It does the same for PORT-WRITE, but if split_diskbuffer is not set, which is the case on your system, then it uses fallback_splitsize instead (with its default of 10M), with no notice of the fallback. So what if I changed the warning to read WARNING: shop /home: fallback_splitsize of 10240k 0.1% of tape length and may create 1000 parts; set split_diskbuffer or increase fallback_splitsize I'd make a note in the example/amanda.conf that this is related to the memory the machine has, and while it can use swap, this shouldn't normally be more than say 50% of the memory in the machine. I have 4GB of ram, and 4 to 8 GB of swap but I don't let it get too far into swap without doing a swapoff -a, swapon -a to clean up the mess. This wording makes it more verbose, but certainly worth it for the clarity, I'd go for it. However, on consideration it may be worthwhile to issue the warning only when a df /dump's free space is less than say 2x the tapesize. /dumps here is on /, which is a 1TB drive here. Here is mine: [r...@coyote dumps]# df /dumps Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3100790036 9563148 86106976 10% / Not a lot of use bothering the folks if the warning is just another cry of 'wolf'. There really _should_ be a wolf at the door... ;) I'll also add a wiki page to help explain the background for the error. Good idea, and I can find the link. Let me know what you think. See above. Thanks, Dustin P.S. There are plans afoot to change these configuration parameters to something less confusing, but not in the upcoming release. I suppose they will bite me when that occurs. ;) NBD, I've been forewarned. -- 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) Duty, n: What one expects from others. -- Oscar Wilde
Re: new splitsize warning (Was: Amanda's future?)
On Sunday 28 February 2010, Jon LaBadie wrote: On Sun, Feb 28, 2010 at 10:59:23AM -0600, Dustin J. Mitchell wrote: ... Yes, I just added this warning. Some refinement may be in order, so let me know what you think. The problem is that Amanda's fallback_splitsize defaults to 10M, and I've seen a number of users recently who are using this splitsize for multi-terabyte dumps, without knowing it. This generates *terrible* performance on backup, since the tape drive has to write tens or hundreds of thousands of filemarks, and also on recovery, since the recovery app must seek to and read from each of those many thousands of files. This is usually due not to a fallback in an error condition, but to misconfiguration. The splitsize parameters are *very* confusing! So the new warning is intended to alert folks such as yourself to the potential misconfiguration. It's just a warning, so Amanda will continue to run as before, but you really should fix it. To fix it, do one of: * set split_diskbuffer properly * raise your fallback_splitsize to something larger than 0.001 * tape-length * set fallback_splitsize to 0 ... Amanda always uses the tape_splitsize for FILE-WRITE dumps. It does the same for PORT-WRITE, but if split_diskbuffer is not set, which is the case on your system, then it uses fallback_splitsize instead (with its default of 10M), with no notice of the fallback. So what if I changed the warning to read WARNING: shop /home: fallback_splitsize of 10240k 0.1% of tape length and may create 1000 parts; set split_diskbuffer or increase fallback_splitsize Is this a case where verbosity is a positive? WARNING: shop /home: fallback_splitsize of 10M is 0.1% of tape length. This may create 1000 parts, severely degrading backup/restore performance. To remedy, create/set a split_diskbuffer or increase fallback_splitsize See appropriate_URL for more information. jl Yes I think so Jon, but in my case I have over 800GB of /dumps available, so this particular item somewhat resembles a cry of wolf, when its just a termite, which I have to call for tomorrow. Its been about 20 years since we've had it done, and we just discovered some tunnels on the music room wall, same place as 20 years ago. Persistent critters. -- 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) If you're constantly being mistreated, you're cooperating with the treatment.
Re: Amanda's future?
On Fri, Feb 26, 2010 at 9:53 PM, Gene Heskett gene.hesk...@verizon.net wrote: I have taken note that there have been no new snapshots made available in a bit over 3 weeks now, and other than the downloads page, all of the rest of the new web pages point to paid support. The snapshots seem to be a permissions problem in a script that wasn't noticed until you pointed it out, so thanks. Make noise earlier next time! We'll get them working again shortly. The demo pages that Tatjana uploaded were just a demo, and don't link anywhere useful. The regular links on amanda.org haven't changed at all (yet). When she uploads the new design, the links will remain essentially unchanged. What is the future direction of amanda? This is a much broader question, and I won't try to answer it here, but I will say that we are *very* close (like a day or two) to branching for a new release, after which we'll have the usual series of betas and release candidates. If you have more specific concerns, please do ask! Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Amanda's future?
On Saturday 27 February 2010, Dustin J. Mitchell wrote: On Fri, Feb 26, 2010 at 9:53 PM, Gene Heskett gene.hesk...@verizon.net wrote: I have taken note that there have been no new snapshots made available in a bit over 3 weeks now, and other than the downloads page, all of the rest of the new web pages point to paid support. The snapshots seem to be a permissions problem in a script that wasn't noticed until you pointed it out, so thanks. Make noise earlier next time! We'll get them working again shortly. Well, frankly I just thought the efforts were going into the web pages and didn't think too much about it till I saw what appears to be a transition from GPL to a per seat fee schedule taking shape, with the only link to the snapshots being the old page, which can be killed with one stroke of the enter key. Makes me a bit nervous about the continued availability of my fav backup utility, which I have now been using for a bit over a decade. Playing the canary in the coal mine bit with the snapshots is my way of contributing back and helping to make a great program even better. The demo pages that Tatjana uploaded were just a demo, and don't link anywhere useful. The regular links on amanda.org haven't changed at all (yet). When she uploads the new design, the links will remain essentially unchanged. What is the future direction of amanda? This is a much broader question, and I won't try to answer it here, but I will say that we are *very* close (like a day or two) to branching for a new release, after which we'll have the usual series of betas and release candidates. If you have more specific concerns, please do ask! 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) Recursion is the root of computation since it trades description for time.
Re: Amanda's future?
On Sat, Feb 27, 2010 at 11:11 AM, Gene Heskett gene.hesk...@verizon.net wrote: Well, frankly I just thought the efforts were going into the web pages and didn't think too much about it till I saw what appears to be a transition from GPL to a per seat fee schedule taking shape, with the only link to the snapshots being the old page, which can be killed with one stroke of the enter key. Makes me a bit nervous about the continued availability of my fav backup utility, which I have now been using for a bit over a decade. Playing the canary in the coal mine bit with the snapshots is my way of contributing back and helping to make a great program even better. First, let me be perfectly clear on a few factual issues: ** Amanda is open source software, and always will be. ** The nightly snapshots are provided as an aid to great folks like you who test the bleeding edge for the good of the project. However, the authoritative copy of the Amanda source is the SourceForge subversion repository[1], which has seen no slow-down in the commit rate. When we build Amanda for distribution to our customers, it is built from the SourceForge repository. As to the changes on amanda.org: the redesign process is nothing more than a visual/graphic design change to bring the site up to modern standards. Little, if any, text on the site will change, and absolutely no policy change is indicated. The demo was an incomplete example intended to garner feedback, that's all. It seems that the incompleteness has caused some confusion, for which I apologize. Gene, thank you for expressing your concerns. There are certainly questions that community members can and should ask about Amanda's development and about the work on amanda.org. I think we (Zmanda) generally do the right thing, but if anyone disagrees, I hope they feel welcome to challenge that assertion. Healthy discussions make healthy communities. Dustin [1] http://amanda.svn.sourceforge.net/ -- Open Source Storage Engineer http://www.zmanda.com
Re: Amanda's future?
On Saturday 27 February 2010, Dustin J. Mitchell wrote: On Sat, Feb 27, 2010 at 11:11 AM, Gene Heskett gene.hesk...@verizon.net wrote: Well, frankly I just thought the efforts were going into the web pages and didn't think too much about it till I saw what appears to be a transition from GPL to a per seat fee schedule taking shape, with the only link to the snapshots being the old page, which can be killed with one stroke of the enter key. Makes me a bit nervous about the continued availability of my fav backup utility, which I have now been using for a bit over a decade. Playing the canary in the coal mine bit with the snapshots is my way of contributing back and helping to make a great program even better. First, let me be perfectly clear on a few factual issues: ** Amanda is open source software, and always will be. ** The nightly snapshots are provided as an aid to great folks like you who test the bleeding edge for the good of the project. However, the authoritative copy of the Amanda source is the SourceForge subversion repository[1], which has seen no slow-down in the commit rate. When we build Amanda for distribution to our customers, it is built from the SourceForge repository. As to the changes on amanda.org: the redesign process is nothing more than a visual/graphic design change to bring the site up to modern standards. Little, if any, text on the site will change, and absolutely no policy change is indicated. The demo was an incomplete example intended to garner feedback, that's all. It seems that the incompleteness has caused some confusion, for which I apologize. Gene, thank you for expressing your concerns. There are certainly questions that community members can and should ask about Amanda's development and about the work on amanda.org. I think we (Zmanda) generally do the right thing, but if anyone disagrees, I hope they feel welcome to challenge that assertion. Healthy discussions make healthy communities. Dustin [1] http://amanda.svn.sourceforge.net/ I am sorry Dustin, but the permissions problem alluded to earlier does not seem to be fixed yet so the old link still shows the 20100131 versions as the newest, and the 'download tarball' buttons on all the sourceforge pages at the link above, while bringing up a requester asking what should firefox do with this file, with the save button already checked, do nothing when clicking on the ok. No file is downloaded. Breakage that continues for over 3 weeks now, does lead to questions, and the replies seem to intend to placate, but have done nothing of substance to restore our ability to continue our near daily testing of the bleeding edge. And that of course makes me wonder if I am indeed the only person doing any test builds and actual use of that test build at all. I certainly hope not. -- 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) Pull the trigger and you're garbage. -- Lady Blue
Re: Amanda's future?
On Sat, Feb 27, 2010 at 7:34 PM, Gene Heskett gene.hesk...@verizon.net wrote: I am sorry Dustin, but the permissions problem alluded to earlier does not seem to be fixed yet so the old link still shows the 20100131 versions as the newest, and the 'download tarball' buttons on all the sourceforge pages at the link above, while bringing up a requester asking what should firefox do with this file, with the save button already checked, do nothing when clicking on the ok. No file is downloaded. If I understand, you're talking about the Download GNU Tarball link on the SourceForge ViewVC pages. The link works for me, but even so it's not a very effective way to download snapshots: the resulting tarballs will not be the usual distribution tarballs, as they have not had their ./autogen scripts run. If you'd like, I can help you modify your test scripts to build straight from subversion instead of from snapshots. Breakage that continues for over 3 weeks now, does lead to questions, and the replies seem to intend to placate, but have done nothing of substance to restore our ability to continue our near daily testing of the bleeding edge. I don't mean to placate - we screwed up. But to be fair, you only brought it up at 9pm on a Friday! I'm sure it'll be sorted out soon. I don't know exactly how Jean-Louis makes the snapshot tarballs, but I've made a distribution tarball built from the latest subversion, which should be similar, available here: http://djmitche.s3.amazonaws.com/amanda-2.6.2alpha.tar.gz Let me know if you have any trouble making it work. And that of course makes me wonder if I am indeed the only person doing any test builds and actual use of that test build at all. I certainly hope not. I hope not, too! Certainly the more people who test Amanda, the more quickly and effectively we will catch and solve bugs. I'm a big believer in testing, both automated and manual. It *is* disconcerting that nobody (not even you?) noticed this for, as you say, three weeks. With luck, this thread will encourage some new folks to begin regularly testing Amanda, especially the upcoming release. Given enough eyeballs, all bugs are shallow [1] Dustin [1] http://en.wikipedia.org/wiki/Linus'_Law -- Open Source Storage Engineer http://www.zmanda.com
Amanda's future?
Greetings; I have taken note that there have been no new snapshots made available in a bit over 3 weeks now, and other than the downloads page, all of the rest of the new web pages point to paid support. What is the future direction of amanda? -- 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) World conquerors sometimes become fools, but fools never become world conquerors. -- The Outer Limits: The Invisibles
