Re: amanda to blame for NT crashes?
On Thu, 7 Dec 2000, Chris Karakas wrote: > Harri Haataja wrote: > > Have you tried fiddling with the tcp flags in /etc/smb.conf? > > > > Perhaps some settings cause odd behaviour more than some. > > Yes, in fact, I have set > > socket options = TCP_NODELAY > > due to degraded performance I noticed without it. I can't imagine how > this could interfere with the estimation of incrementals. As the Subject: says, I meant in general (no quotes) smb causing NT crashes. Perhaps setting some option there causes/removes it. Just a passing thought.
Re: amanda to blame for NT crashes?
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Any more ideas now? How can this "ATTR_ARCH" flag be reasonably used > > here? > > The ATTR_ARCH flag doesn't get mapped to any standard Unix flag. Mapping it > to the executable flag would be very strange. > I don't think so: this is exactly the approach taken from the SAMBA people. There you have files on ext2 (usually) which have to behave like Windows files (to put it very simply). They decided to map the archive, hidden and system bits to the user, group and world execute bits respectively (see the SAMBA directives map archive, map hidden, map system). If this is possible to do when we have ext2 files and we want them to "behave" like vfat, then it should be possible also when we have vfat files (i.e. with "real" archive, hidden and system bits) and want them to be mounted under some Linux directory (which SAMBA could then use, read the mapped bits, find out the "real" bits and use the archive bit to do correct incrementals on vfat). I think the mount command and SAMBA should be consistent on this topic. The executable flags are unused when you mount a vfat partition. They currently just get filled according to the umask, but they are meaningless. Using the above method they at least can be used for something (very) useful. In one sentence: I miss the "map archive/hidden/system" options in the vfat driver of the mount command in Linux. -- Regards Chris Karakas Don´t waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
Harri Haataja wrote: > > Have you tried fiddling with the tcp flags in /etc/smb.conf? > > Perhaps some settings cause odd behaviour more than some. Yes, in fact, I have set socket options = TCP_NODELAY due to degraded performance I noticed without it. I can't imagine how this could interfere with the estimation of incrementals. -- Regards Chris Karakas Don´t waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
On Dec 5, 2000, Chris Karakas <[EMAIL PROTECTED]> wrote:
> according to David Woodhouse <[EMAIL PROTECTED]> in the
> linux-kernel mailing list:
Hi, David! :-)
> ---snip
> We do, however, correctly set the archive bit whenever we modify or
> create a file on a FAT filesystem, so it should be usable for its
> intended purpose.
> You just need to make sure your backup program uses the ATTR_ARCH
> flags to decide whether to back up each file, and resets the flag
> after/before doing the backup.
> ---snip
> Any more ideas now? How can this "ATTR_ARCH" flag be reasonably used
> here?
Hmm... You'd have to try to get GNU tar and/or Samba to reasonably
use these flags. Maybe their maintainers would be willing to help you
out?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: amanda to blame for NT crashes?
Chris Karakas <[EMAIL PROTECTED]> writes: > Any more ideas now? How can this "ATTR_ARCH" flag be reasonably used > here? What about msdos and umsdos file systems? The former is plain 8.3 chars file length. Vfat is based on that, so I'd not expect a change. The later simulates unix permissions via a special file in every directory. After using Windows you have to "umssync" the updates to the special file. The file system looks like a unix file system to amanda, so tar might be happy with it. I don't know what happens to long file names, but if you just backup user data it might be sufficient to have the data with abcdef~1.ext file names. I'd like to see a summary of your experiments. HTH, Johannes Nieß
Re: amanda to blame for NT crashes?
Have you tried fiddling with the tcp flags in /etc/smb.conf? Perhaps some settings cause odd behaviour more than some.
Re: amanda to blame for NT crashes?
(Joi and David, please just read on) Alexandre Oliva wrote: > > On Dec 4, 2000, Chris Karakas <[EMAIL PROTECTED]> wrote: > > > when you use SAMBA for the vfat partitions of your dual boot system, > > it does not work. > > What do you mean? It works for me. Or are you talking about backing > up vfat partitions while running GNU/Linux, in which case Samba isn't > used at all; all you need is GNU tar? > I mean, I have tried both, without success. Here's what I tried: Common part in both situations: The vfat partitions are mounted under /dos as /dos/c, /dos/d etc. This is done in boot time from fstab: /dev/hda3 /dos/cvfat defaults,uid=500,gid=101,umask=002 0 0 /dev/hda5 /dos/dvfat defaults,uid=500,gid=101,umask=002 0 0 etc. uid is user chris, gid is group windows. AMANDA is member of the group. This way *all* files get the permissions -rwxrwxr-x, i.e. they become executables, even if they are not (probably due to the umask I use). (That's the first thing that annoys me in mount: I can't map the archive bit to the fictitious executable bits, as SAMBA is able to do when the files are on ext2 partitions). Now, for the two cases I have tested: 1. The Linux/AMANDA server becomes a SAMBA server too. The /dos/c, /dos/d directories are exported as C and D respectively. In disklist I would have //bacchus/c and //bacchus/d as the directories to be backed up with tar, where bacchus is the Linux/AMANDA/SAMBA server. 2. No SAMBA in this case. I just tell AMANDA to use tar to backup the directories /dos/c, /dos/d etc. In both cases, incrementals are almost as large as full backups. It was not always so: I had to boot Windows a few times (which I do not do very often) to get this behaviour, so it is seems to be the problem of inodes on vfat not being constant between mounts (after some kernel, I think 2.2.5). But, this is also curious: Even if I do not boot between two successive AMANDA runs (i.e. the vfat filesystems stay mounted with the same inode numbers), even then, a level 1 incremental which is done the day after a level 0 was done, is almost as big as level 0. I can't figure what's going on. From now on, I have set "dumpcycle 0" for the vfat filesystems. > Which has just given me yet another idea for you to try: set up your > GNU/Linux box as a Samba server, and run your backups pretending the > GNU/Linux box is actually running MS-Windows, i.e., arrange for it to > be backed up through Samba. This will use Samba's mechanism of > creating incrementals, which are quite different from those of GNU > tar, and might get you around the problems you're facing with vfat, > GNU tar, the Linux kernel or whatever :-) > This is exactly my case 1. Joi Ellis may remember that I contacted him offline for this problem 6 months ago. I came to the coclusion that I could not map the archive bit on some (even fictitious) execute bit, which would then be used by SAMBA as an archive bit to compute incrementals and that this was the reason incrementals were so big. So the problem seems to be the vfat driver in mount, which cannot map the archive bit at anything meaningful, although it sets it correctly, according to David Woodhouse <[EMAIL PROTECTED]> in the linux-kernel mailing list: ---snip We do, however, correctly set the archive bit whenever we modify or create a file on a FAT filesystem, so it should be usable for its intended purpose. You just need to make sure your backup program uses the ATTR_ARCH flags to decide whether to back up each file, and resets the flag after/before doing the backup. ---snip Any more ideas now? How can this "ATTR_ARCH" flag be reasonably used here? -- Regards Chris Karakas Don´t waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
[EMAIL PROTECTED] said: > Any more ideas now? How can this "ATTR_ARCH" flag be reasonably used > here? The ATTR_ARCH flag doesn't get mapped to any standard Unix flag. Mapping it to the executable flag would be very strange. ext2 provides an ioctl() call which lsattr uses to get/set extended ext2-specific flags. You could implement a similar call for the fat-based filesystems, and add support in Amanda for using it to query (and later reset) the state of the ATTR_ARCH bit. -- dwmw2
Re: amanda to blame for NT crashes?
On Dec 4, 2000, Chris Karakas <[EMAIL PROTECTED]> wrote:
> So the idea is to give us the chance to write our own "estimator
> function": a script that gets a filename, a date and/or a backup level
> (and perhaps also other parameters) as input and gives a boolean as
> output ("yes, it should be backed up" or "no, it shouldn't").
That's exactly what the `sendsize' program is. You'll even find hooks
for a `calcsize' program in there. Of course, you can modify it so as
to call whatever other program you want, but using the wrapper script
suggested by JJ is far easier, at least before the DUMPER API is
implemented.
Note that you don't have to replace GNU tar with the script: just
configure Amanda so that it uses your replacement script as if it were
GNU tar and you're done.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: amanda to blame for NT crashes?
On Dec 4, 2000, Chris Karakas <[EMAIL PROTECTED]> wrote:
> when you use SAMBA for the vfat partitions of your dual boot system,
> it does not work.
What do you mean? It works for me. Or are you talking about backing
up vfat partitions while running GNU/Linux, in which case Samba isn't
used at all; all you need is GNU tar?
Which has just given me yet another idea for you to try: set up your
GNU/Linux box as a Samba server, and run your backups pretending the
GNU/Linux box is actually running MS-Windows, i.e., arrange for it to
be backed up through Samba. This will use Samba's mechanism of
creating incrementals, which are quite different from those of GNU
tar, and might get you around the problems you're facing with vfat,
GNU tar, the Linux kernel or whatever :-)
> incrementals and has more to do with tar, vfat, the kernel, or whatever,
> than AMANDA itself but I insist on refining the above statement by
> pointing out this - admittedly very special - case, where it is just not
> true. Believe me, I will be very happy to find out that this refinement
> is not necessary and that I was wrong after all ;-)
So will I :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: amanda to blame for NT crashes?
>> So explain to me exactly what you think Amanda should do to solve this. >> And keep in mind that the design philosophy is that it uses other tools >> and that it does **not** do the work itself. > >Separate "estimator programs" from "backup programs". ... If you find an estimator program that works, you can get Amanda to call it by faking the GNU tar that is used. See: ftp://gandalf.cc.purdue.edu/pub/amanda/gtar-wrapper.* >... Why shouldn't I be able to use dump for the estimations and >tar for the backups ... Because they may (and in fact do) have different ideas of how big the image will be. Backing up **exactly** the same files with both will give you different sized images because the format is wildly different. So it's pointless to use one for the other. Why not syntax check your code with Fortran and then actually compile it with C? However, if you want to do something like this, feel free to implement the Amanda DUMPER-API, which should allow for such strange things. >Chris Karakas John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda to blame for NT crashes?
On Mon, 4 Dec 2000, Chris Karakas wrote: >I've been trying for 6 months now to get the Windows partitions on the >backup server to be backed up correctly while running Linux and AMANDA. >I first tried it as follows: I told AMANDA to backup the SAMBA shares >that a SAMBA server made available on the backup server. The SAMBA >server got those shares from as mounted vfat partitions. This is where >SAMBA came into play. It did not work - incrementals were almost as big >as full backups. Then I said myself "why have this SAMBA stuff at all? >Just mount the vfat partitions and tell AMANDA to use tar and backup the >mount point directory". This did not work either for the same reason. I >am still looking for a solution. My amamda server is an Intel box which dual-boots NT and Linux Red hat 6.2. /dev/hda1 is the NT C: boot partition /dev/hda5 is the NT D: extended partition However, I have the mounted RO on the linux side because I often use them with VMWare from Linux, effectively multi-booting my box. ;) Mounted RO, Gnu tar sees them as /mnt/doscb and /mnt/dosdb. I could have accessed them via samba instead, since my VMWare appears to my Linux personality as a completely separate system with its own Hostname and IP Address. I played with this and it does work, but I don't use it because I rarely leave VMWare running for long periods of time. (It consumes half my ram and degrades my native Linux JBuilder application, which also consumes half my ram. Running them both causes my machine to start swapping heavily, and since I spend most of my time doing Java development, I launch VMWare only when I need to do excel stuff.) You could try a VMWare-hosted smbtar backup. -- Joi Ellis [EMAIL PROTECTED], http://www.visi.com/~gyles19/
Re: amanda to blame for NT crashes?
Jon LaBadie wrote: > > On Sat, Dec 02, 2000 at 03:28:49AM +0100, Chris Karakas wrote: > > > > If you say that AMANDA can backup SAMBA shares, people will believe it > > and be happy. People like me (a mathematician...) will believe it so > > much, that they will eventually construct a case that does not work - > > and will get a problem. The case that does not work is when you have a > > dual boot system (Win/Linux) and the SAMBA shares you are trying to > > backup with AMANDA (when running Linux) are the vfat partitions of > > Windows. Just because exceptions confirm the rules, does not mean that > > we should not point them out. > > I'm missing something here. If I have it correct you have some > client systems that run windows (maybe some linux clients too). > Your amanda backup host runs linux, but is also bootable into > windows. Further, it is the windows partitions on the backup > host you are having difficulties with. Am I correct? > Yes. > If so, I don't understand where samba comes into play. Window's > is not running to share the vfat partitions so you must be > simply mounting them as vfat file systems under linux. In that > case I would think normal tar would work. It does for me on my > dual-boot Solaris box with windows partitions mounted under that os. > No need for samba or smbtar or ... > I've been trying for 6 months now to get the Windows partitions on the backup server to be backed up correctly while running Linux and AMANDA. I first tried it as follows: I told AMANDA to backup the SAMBA shares that a SAMBA server made available on the backup server. The SAMBA server got those shares from as mounted vfat partitions. This is where SAMBA came into play. It did not work - incrementals were almost as big as full backups. Then I said myself "why have this SAMBA stuff at all? Just mount the vfat partitions and tell AMANDA to use tar and backup the mount point directory". This did not work either for the same reason. I am still looking for a solution. > > > > You understand a chance as a curse: AMANDA _has_ the qualities to become > > a real, integrative, superlative backup tool. > > Some would say it already is :)) > Well, maybe for many people, but still not for me, because it cannot handle the above situation sufficiently. And, now that all this discussion is going on, I know I am not alone - another participant said he gave up on backing up Windows partitions just because of this. > > Be aware that amanda is NOT a backup program. It is a backup manager. > There are no backup programs nor recovery programs supplied with it. > Only interfaces to other, non-supplied programs. > > It was also created as a unix backup manager, not for windows, samba, > oracle, mvs, or anything else. That it can and has been used for > these purposes is a compliment to its design. > > To suggest that the people who maintain amanda should be responsible > for the programs that it schedules and manages is analogous to saying > the people who wrote the cron deamon on unix are responsible for > debugging the programs cron kicks off. > O.K, I have understood that. Now I want you to understand that I have a problem (the above one) and I cannot find a solution with AMANDA. When I read the "AMANDA chapter" on backupcentral.com, stating that "Recent versions can also use SAMBA to back up Microsoft Windows (95/98/NT/2000)-based hosts", I thought "Fine! That's the _ultimate_ solution!". It turned out that the above statement may be technically correct, but somewhat misleading to the unaware: when you use SAMBA for the vfat partitions of your dual boot system, it does not work. It seems that either you have to run Windows on those partitions the same time that you run Linux and AMANDA to back them up (which is impossible on a dual boot system...eh, OK, maybe VMware could solve this "detail") or run the SMB shares that you want to backup on ext2, not vfat, filesystems (also impossible for a dual boot system, as long as Windows does not run on ext2 ;-)). It does not work even if you abandon SAMBA and just try to backup a vfat directory. The problem is estimating the incrementals and has more to do with tar, vfat, the kernel, or whatever, than AMANDA itself but I insist on refining the above statement by pointing out this - admittedly very special - case, where it is just not true. Believe me, I will be very happy to find out that this refinement is not necessary and that I was wrong after all ;-) -- Regards Chris Karakas Don´t waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
"John R. Jackson" wrote:
>
> >You understand a chance as a curse: AMANDA _has_ the qualities to become
> >a real, integrative, superlative backup tool. ...
>
> So explain to me exactly what you think Amanda should do to solve this.
> And keep in mind that the design philosophy is that it uses other tools
> and that it does **not** do the work itself.
Separate "estimator programs" from "backup programs". As it is now, if I
decide to use tar for my backups, it will also be used for the
estimation phase (which is where my problem is: estimation of
incrementals). But tar may not be estimating correctly in my case,
although it may be perfect in backing up.
So the idea is to give us the chance to write our own "estimator
function": a script that gets a filename, a date and/or a backup level
(and perhaps also other parameters) as input and gives a boolean as
output ("yes, it should be backed up" or "no, it shouldn't"). This
script will have a "default" code in it: if tar is used, then tar is
invoked to determine if the file should be backed up, if dump is used,
then dump is invoked for the estimation, otherwise...a custom code
should go here. If the user decides to put custom code in there, he
should comment the default coding. He can then check the file's inodes,
ctimes, the phase of the moon or whatever else he deems aproppriate to
decide whether it should be backed up or not, in the given incremental
level and/or date.
The way it is now, I have to change tar itself, writing a wrapper around
it, taking into account who started it, whether it was for estimation,
backup, or restore etc. This makes the task more formiddable than it
already is (for unskilled programmers like me).
By the way: Why shouldn't I be able to use dump for the estimations and
tar for the backups (and vice-versa)? This solution (assuming it is one,
i.e. assuming that dump estimates correctly where tar does not), is less
general than the above, but should take you only another parameter in
amanda.conf and some case checking to implement with the existing code.
--
Regards
Chris Karakas
Don´t waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
Alexandre Oliva wrote: > > > I don't care if the mechanisms are out of AMANDA's influence - this > > is a design issue. > > Indeed. Amanda is designed to be a backup manager, that knows how to > use a couple of existing backup tools. If none of them fit your > needs, well, then you just have to go find some backup program capable > of backing up stuff you need and plug it into Amanda. See? It's not > Amanda's fault. > I see. I will have to devise something myself to help me out of this. I admit I had not expect this. > > If you say that AMANDA can backup SAMBA shares, people will believe it > > and be happy. > > And they can believe it. I do it every day. Many others do it. Just > because it fails for some unlucky souls, it doesn't mean it doesn't > work at all. Most likely, it's some detail in these souls' setups > that can be easily fixed. > That "detail" might be writing a wrapper script, computing datestamps, redesigning the wheel...:-) > > The case that does not work is when you have a dual boot system > > (Win/Linux) and the SAMBA shares you are trying to backup with > > AMANDA (when running Linux) are the vfat partitions of Windows. > > Ok, so how about this idea: get Plex86 or VMWare, boot Windows atop > GNU/Linux, share the disks you want to back up and tell Amanda to back > them up using Samba. Then, wait for the blue screens :-) :-) > I am glad I had the same idea before I read your answer (see my other posting) ;-) Believe me, I would try it, but for the moment it is out of the question because of the computing power needed by VMware (the backup server is a 486DX-133...). > Except for this > minor detail people keep forgetting, which is that Amanda just > *manages* backups, it doesn't *create* them. > I will have to make this statement my daily mantra, until I get it. Thanks for all the input. -- Regards Chris Karakas Don´t waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
It happened this one time. I spent about an hour looking for more info, but was unable to find any. If it crashes again, I'll dig deeper into the issue. --- Eric On Fri, 1 Dec 2000, Joi Ellis wrote: > On Fri, 1 Dec 2000, John R. Jackson wrote: > > >Date: Fri, 01 Dec 2000 18:31:07 -0500 > >From: John R. Jackson <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: Eric Wadsworth <[EMAIL PROTECTED]> > >Cc: [EMAIL PROTECTED] > >Subject: Re: amanda to blame for NT crashes? > > > >[ My apologies in advance for the following. I normally brag about how > >little heat there is on this mailing list, but I'm sure going to break > >that mold below. If it helps, pretend I'm trying to be funny. --JJ ] > > > >>... My co-workers are saying that it is amanda's fault ... > > > > I just searched through samba.org's mail archive, and there are reports > there of NT blue-screening during a smbtar pull from Unix hosts. > > I haven't come across a response to that, someone who has more time may > want to search harder through the archives for an answer. > > > -- > Joi Ellis > [EMAIL PROTECTED], http://www.visi.com/~gyles19/ > >
Re: amanda to blame for NT crashes?
On Mon, 4 Dec 2000, Harri Haataja wrote: >Date: Mon, 4 Dec 2000 09:28:57 +0200 (EET) >From: Harri Haataja <[EMAIL PROTECTED]> >Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> >Subject: Re: amanda to blame for NT crashes? > >On 2 Dec 2000, Marc SCHAEFER wrote: > >Fynnily enough I have some first hand information (that I can't cite >=) that says opposite. M$ has a very fine-grained, big-budget, efficient >(?) testing scheme but somehow that doesn't seem to do the job. Not all >bugs are discovered by testing. With the mess M$ has made of the smb protocols, it's a wonder it still works at all. Every release of windows has come with a changed protocol. There's all sorts of oddness in each version to allow it to talk smb-like with all previous versions. It's a horrible mess. (An ex-Microserf told me this.) I'm surprised Samba works at all! >I presume you mean windos clients are used to test smb shares? > >This is quite likely to be a culprit. But then again m$ has a history of >breaking standards and protocols on purpose and always blaming the other >end. This thread (the start) seems to have proven that the idea has gone >through very well -- their users have absolute faith in them and always >blame someone (-thing) else. Boy, can I tell you some stories about Microsoft re-writing email internet standards! And F77 language standards, too... >Nevertheless, I agree that if windows crashes, windows has a >bug/flaw/lacking (depending on wheather what made it crash was >use/unexpected_use/downright_cruel_use) there. Yes. But then, M$ has never felt that a GPF was anything to avoid. :p -- Joi Ellis [EMAIL PROTECTED], http://www.visi.com/~gyles19/
Re: amanda to blame for NT crashes?
On 2 Dec 2000, Marc SCHAEFER wrote: > Now, if you ask me, the main problem is that so far Microsoft servers > were used with Microsoft clients, and so the incorrect code paths > were never exercized. Microsoft could have done white box > testing on their own code, but they obviously haven't. They Fynnily enough I have some first hand information (that I can't cite =) that says opposite. M$ has a very fine-grained, big-budget, efficient (?) testing scheme but somehow that doesn't seem to do the job. Not all bugs are discovered by testing. > it's what it looks like. This, added to the fact that they > usually develop/test only for one architecture will let bugs > pass through. I presume you mean windos clients are used to test smb shares? This is quite likely to be a culprit. But then again m$ has a history of breaking standards and protocols on purpose and always blaming the other end. This thread (the start) seems to have proven that the idea has gone through very well -- their users have absolute faith in them and always blame someone (-thing) else. Nevertheless, I agree that if windows crashes, windows has a bug/flaw/lacking (depending on wheather what made it crash was use/unexpected_use/downright_cruel_use) there.
Re: amanda to blame for NT crashes?
On Sat, Dec 02, 2000 at 07:14:16PM -0500, Paul Tomblin wrote: > Quoting Bernhard R. Erdmann ([EMAIL PROTECTED]): > > documenting it publicly available. Go and tell your co-worker to blame > > M$ for it. I'm sure M$'s support will help you quickly and for no > > charge. > > What colour is the sky in your world? :-) Sorry, I forgot a smiley... > If my boss didn't require me to update Microsoft Project files, I'd > definitely upgrade to Service Pack 6.2. You know, the one from RedHat. Did you already try StarOffice from Sun? Or http://www.openoffice.org/ ?
Re: amanda to blame for NT crashes?
Quoting Bernhard R. Erdmann ([EMAIL PROTECTED]): > documenting it publicly available. Go and tell your co-worker to blame > M$ for it. I'm sure M$'s support will help you quickly and for no > charge. What colour is the sky in your world? :-) AS far as I know, NT doesn't need any extra provocation to crash - the one I use at work (NT 4.0 SP6) BSODs about twice a week while I'm doing exactly the same stuff as I'm doing when it *doesn't* crash. If my boss didn't require me to update Microsoft Project files, I'd definitely upgrade to Service Pack 6.2. You know, the one from RedHat. -- Paul Tomblin <[EMAIL PROTECTED]>, not speaking for anybody "I'm fairly sure Linux exists principally because writing an operating system probably seems like a good way to pass the months of darkness in Finland" - Rodger Donaldson
Re: amanda to blame for NT crashes?
On Fri, Dec 01, 2000 at 03:18:02PM -0700, Eric Wadsworth wrote: > I'm just getting everything going with amanda, and I'm suddenly in trouble. > > One of the NT boxes, being backed up via samba, got a blue-screen crash while it > was going. My co-workers are saying that it is amanda's fault (that computer > wasn't even being used at the time, it was idle). I'm fscked up with those we-believe-in-Windoze guys ignoring their causes of problems. Amanda drives smbtar. smbtar is a wrapper for smbclient. If smbclient issues SMB commands and NT crashs one more time, it's M$'s fault for poorly implementing the SMB protocol and not documenting it publicly available. Go and tell your co-worker to blame M$ for it. I'm sure M$'s support will help you quickly and for no charge.
Re: amanda to blame for NT crashes?
>I wanted a moment of truth and I am getting it... To put it mildly :-). I'm glad you didn't take my ranting too much to heart. >Pointing out a deficiency is here perceived as blaming. ... Only partially true. The real problem is that you're saying it's a deficiency in Amanda when it is not. As has been pointed out, Amanda does not do backups itself, it only manages other programs that do them. That is it's sole job. That's all it's designed to do. That part of the basic design is not going to, and should not, change. You might as well start writing letters to the people who maintain your shell (csh, ksh, whatever) and telling them the vfat (or NT blue screen) is a deficiency in their code. >... Because AMANDA cannot solve my problem. And I continue to disagree. It's Windows and Samba (or vfat and GNU tar, I'm starting to forget which is which :-) that cannot solve your problem. Go gripe to them. >... in order to compute incrementals, AMANDA >relies on mechanisms which in my special case do not work. ... It also relies on your motherboard working. If it breaks are you going to claim that's another deficiency in Amanda? >You understand a chance as a curse: AMANDA _has_ the qualities to become >a real, integrative, superlative backup tool. ... So explain to me exactly what you think Amanda should do to solve this. And keep in mind that the design philosophy is that it uses other tools and that it does **not** do the work itself. And if you say that basic design concept is a flaw, you're opening up a major can of worms that Amanda will never crawl out of and should not even begin to try. Writing the programs that actually do backups is a **major** undertaking, especially across all the platforms that Amanda supports. For one thing, many of the file system types are proprietary and can only be backed up with proprietary tools, which Amanda is happy to manage for you, but not replace. >Chris Karakas John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda to blame for NT crashes?
Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > Bug according to which spec? According to the default assumption that no protocol flaw shall make an OS hang or crash. What happens with some SMB servers such as the one developped by Microsoft is that the SMB server code is deeply buried in the OS kernel (arguably for performance reasons --- doesn't explain why Samba, a completely user-space implementation, has outperformed those implementations in some cases), and thus a failure of the software will crash the OS. Now, if you ask me, the main problem is that so far Microsoft servers were used with Microsoft clients, and so the incorrect code paths were never exercized. Microsoft could have done white box testing on their own code, but they obviously haven't. They basically write buggy code (like everyone does, sadly), and only test it in a very limited set of circumstances --- or at least it's what it looks like. This, added to the fact that they usually develop/test only for one architecture will let bugs pass through. NB: there is a specification of SMB available (infact, well, there are plenty `protocol levels' to choose from). I haven't kept up on the latest CIFS/SMB news, however.
Re: amanda to blame for NT crashes?
[EMAIL PROTECTED] (Marc SCHAEFER) writes: >This is *definitely* a bug in the Windows implementation of SMB. Or >one of. One of the things which gets unnoticed if you use the Bug according to which spec? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20
Re: amanda to blame for NT crashes?
On Fri, 1 Dec 2000, Eric Wadsworth wrote: > I'm just getting everything going with amanda, and I'm suddenly in trouble. > > One of the NT boxes, being backed up via samba, got a blue-screen crash while it > was going. My co-workers are saying that it is amanda's fault (that computer > wasn't even being used at the time, it was idle). Um. Nope. If Windows blue screens then the only people to blame are Microsoft. Nothing you can do to the system via a shared drive should crash the system. It doesn't matter if you throw invalid packets at it, the system still shouldn't crash. I take it that the system is up to date on it's service packs and patches. [snip] regards, Colin.
Re: amanda to blame for NT crashes?
Joi Ellis <[EMAIL PROTECTED]> wrote: > I just searched through samba.org's mail archive, and there are reports > there of NT blue-screening during a smbtar pull from Unix hosts. I can at least confirm this with Windows 95, seems to not happen that quickly with Windows 98 (ie: it's impossible to differenciate from `normal', `usual' crashes). This is *definitely* a bug in the Windows implementation of SMB. Or one of. One of the things which gets unnoticed if you use the `proper' (read: Microsoft-only) clients. In other worlds, Windows doesn't interoperate, and is full of assumptions that will make your system break. Especially the kind of weakness that Internet crackers love. Read the smbfs documentation and you will see the quite big amount of work-around that are required in order to not crash Microsoft SMB servers ... often at the price of speed. What is good in the UNIX world is that it is indeed usually quite possible to isolate a failure cause: in the Windows world you just need to modify your setup back and forth, install various service packs, until everything *seems* to stabilize. Thinking might sometimes be easier, but Microsoft doesn't encourage thinking. Installing one mouse driver might make your database crash because of an incompatibility (read: bug) in a previously installed, and seemingly working, printer driver. Dependancies and unstability. ... and all of this has absolutely no link to Amanda.
Re: amanda to blame for NT crashes?
On Dec 2, 2000, Chris Karakas <[EMAIL PROTECTED]> wrote:
> "But it is the interplay of tar, vfat and the Linux kernel, all of which
> are out of AMANDA's influence", you will say. This is correct, but it is
> exactly the problem here: in order to compute incrementals, AMANDA
> relies on mechanisms which in my special case do not work.
Not true. I agree it doesn't work out of the box, given how unusual
your configuration is. It's just like introducing support for a new
kind of backup program: it may take a little bit of effort, but it can
be done, because Amanda is not a backup program, it's a backup manager
that tells backup programs when to do their job and manages to get the
output they create (the so-called backups) out to tape in a very
efficient manner.
You might as well decide to use zip as the backup program, and
convince Amanda to use it. Now, if the kernel of the OS you run fails
to handle files whose pathnames are longer than 2 MB, would you blame
Amanda? Or zip? Or the kernel?
If Windows NT crashes while serving files to a client (which is what
smbtar is), how can you claim it might possibly be Amanda's fault?
I'm unfortunate enough to have a couple of NT boxes around that are in
the backup system I help to run, and NT has never crashed on that.
Maybe it's just a matter of installing a service pack? Maybe the
crashes elsewhere are caused by some other service installed on the NT
box that gets Windows NT confused (not unusual :-) to the point that
it crashes? It just can't be said that it's Amanda's fault: any other
tool that relied upon the SMB protocol to backup the files in the
Windows NT server would likely fall victim of the same bug in Windows
NT. OSs aren't supposed to go crashing just because someone asks them
to do something they claim to be able to do.
> I don't care if the mechanisms are out of AMANDA's influence - this
> is a design issue.
Indeed. Amanda is designed to be a backup manager, that knows how to
use a couple of existing backup tools. If none of them fit your
needs, well, then you just have to go find some backup program capable
of backing up stuff you need and plug it into Amanda. See? It's not
Amanda's fault.
> If you say that AMANDA can backup SAMBA shares, people will believe it
> and be happy.
And they can believe it. I do it every day. Many others do it. Just
because it fails for some unlucky souls, it doesn't mean it doesn't
work at all. Most likely, it's some detail in these souls' setups
that can be easily fixed.
> The case that does not work is when you have a dual boot system
> (Win/Linux) and the SAMBA shares you are trying to backup with
> AMANDA (when running Linux) are the vfat partitions of Windows.
Ok, so how about this idea: get Plex86 or VMWare, boot Windows atop
GNU/Linux, share the disks you want to back up and tell Amanda to back
them up using Samba. Then, wait for the blue screens :-) :-)
> You understand a chance as a curse: AMANDA _has_ the qualities to become
> a real, integrative, superlative backup tool.
According to last COMDEX, it has already become one. Except for this
minor detail people keep forgetting, which is that Amanda just
*manages* backups, it doesn't *create* them.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: amanda to blame for NT crashes?
"John R. Jackson" wrote: > > [ My apologies in advance for the following. I normally brag about how > little heat there is on this mailing list, but I'm sure going to break > that mold below. If it helps, pretend I'm trying to be funny. --JJ ] > No problem - go ahead and let truth shine ;-) > > This and the vfat discussion are getting me really, really, pissed off. > I wanted a moment of truth and I am getting it... > If Amanda is running an absolutely normal Samba command and that command > is triggering a Windows crash, then obviously it's either a Samba or > Windows problem (and I know which one I'd bet on). It is **not** an > Amanda problem. If you type the same Samba command Amanda did under > the exact same circumstances, it would have done the same thing. > Correct. But covers only part of the story (by design). > And for anyone paying the slightest bit of attention, substitute GNU tar > for Samba and Linux kernel for Windows in the above and you'll know how > I feel about blaming Amanda for the vfat problem between that pair. > Pointing out a deficiency is here perceived as blaming. If I were to blame something, then this would be the very design of AMANDA (yes!). It is designed to do its job as independently as possible. This is a real strength - but as it happens in real life, it is a strength for only 90% of all cases. I happened to have the honour of choosing the other 10% for my configuration (I do this often in other areas too, whith similar results...). And I had the strength to point out that, in my case, AMANDA's strength is a weakness. Why? Because AMANDA cannot solve my problem. "But it is the interplay of tar, vfat and the Linux kernel, all of which are out of AMANDA's influence", you will say. This is correct, but it is exactly the problem here: in order to compute incrementals, AMANDA relies on mechanisms which in my special case do not work. I don't care if the mechanisms are out of AMANDA's influence - this is a design issue. To put it more blatantly: if AMANDA relies on something and this something does not work in my case, then it is not only a fault of this something (as you implicitly suggest) but also of AMANDA for relying on it in _all_ cases. > I'm clearly torqued off these days by people blaming > Amanda for things it has no control over. And throwing Windows into > the mix just winds me up tighter. > If you say that AMANDA can backup SAMBA shares, people will believe it and be happy. People like me (a mathematician...) will believe it so much, that they will eventually construct a case that does not work - and will get a problem. The case that does not work is when you have a dual boot system (Win/Linux) and the SAMBA shares you are trying to backup with AMANDA (when running Linux) are the vfat partitions of Windows. Just because exceptions confirm the rules, does not mean that we should not point them out. > Better yet, how about asking Microsoft for help? I'm sure they'll put > every effort into getting you quality assistance right away. > You understand a chance as a curse: AMANDA _has_ the qualities to become a real, integrative, superlative backup tool. But if we say "this is M$'s problem, this is tar's problem, etc.", perceiving the challenge as a curse, then it will miss this chance. And anyone who has ever tried to figure out full and incremental backups on only 5 computers running both Linux and Windows on the same machine at different times, will understand what I mean by saying that the chance should not be lost - even at the price of some more pressure pills... :-) -- Regards Chris Karakas Don´t waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
On Fri, 1 Dec 2000, John R. Jackson wrote: >Date: Fri, 01 Dec 2000 18:31:07 -0500 >From: John R. Jackson <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Eric Wadsworth <[EMAIL PROTECTED]> >Cc: [EMAIL PROTECTED] >Subject: Re: amanda to blame for NT crashes? > >[ My apologies in advance for the following. I normally brag about how >little heat there is on this mailing list, but I'm sure going to break >that mold below. If it helps, pretend I'm trying to be funny. --JJ ] > >>... My co-workers are saying that it is amanda's fault ... > I just searched through samba.org's mail archive, and there are reports there of NT blue-screening during a smbtar pull from Unix hosts. I haven't come across a response to that, someone who has more time may want to search harder through the archives for an answer. -- Joi Ellis [EMAIL PROTECTED], http://www.visi.com/~gyles19/
Re: amanda to blame for NT crashes?
[ My apologies in advance for the following. I normally brag about how little heat there is on this mailing list, but I'm sure going to break that mold below. If it helps, pretend I'm trying to be funny. --JJ ] >... My co-workers are saying that it is amanda's fault ... Absolutely not. Since all the blame for the crap Windows dumps on the world must apparently now go upstream, it's entirely your fault because you ran Amanda. Actually, I guess all Windows problems are really the fault of James da Silva since he wrote much of Amanda. And let's see, he worked for University of Maryland, and I'll bet the UofMd is an NCAA member, so we can surely blame them and all collegiate athletic departments, too. But wait. There's more. Since you probably ran the command from cron, and cron runs commands with sh, this must all be Steven Bourne's fault (and /bin/sh, of course). Or if you ran it by hand with ksh, that would make it Dave Korn. And both of them worked for AT&T. So I guess we'd better get a letter off right away telling them they are directly responsible for an NT crash. This and the vfat discussion are getting me really, really, pissed off. If Amanda is running an absolutely normal Samba command and that command is triggering a Windows crash, then obviously it's either a Samba or Windows problem (and I know which one I'd bet on). It is **not** an Amanda problem. If you type the same Samba command Amanda did under the exact same circumstances, it would have done the same thing. And for anyone paying the slightest bit of attention, substitute GNU tar for Samba and Linux kernel for Windows in the above and you'll know how I feel about blaming Amanda for the vfat problem between that pair. My apologies for all this ranting, Eric (and everyone else). It has nothing to do with you, and in fact, it sounds like you already told your "blame anyone but Windows" co-worker the same thing (and my apologies to that person, too). I'm clearly torqued off these days by people blaming Amanda for things it has no control over. And throwing Windows into the mix just winds me up tighter. OK, where did I put that blood pressure medicine ... :-). >Has anyone else heard of this kind of problem? ... Have you posted this problem to the Samba group? While some Amanda users use Samba and you might get expertise hits here, it seems like going directly to those folks would improve your coverage. Better yet, how about asking Microsoft for help? I'm sure they'll put every effort into getting you quality assistance right away. Damn. I'm sure I left those pills around here someplace ... :-). >Eric Wadsworth John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
amanda to blame for NT crashes?
I'm just getting everything going with amanda, and I'm suddenly in trouble. One of the NT boxes, being backed up via samba, got a blue-screen crash while it was going. My co-workers are saying that it is amanda's fault (that computer wasn't even being used at the time, it was idle). I explained that the UNIX system was just using samba to copy files from the hard drive for the backup, and a co-worker said that a 'pull' from an NT hard drive, using samba, has been known to cause blue-screen crashes on pentium-pro systems in the past. The system that crashed is a Pentium II 300. Has anyone else heard of this kind of problem? (samba 2.0.6 on FreeBsd 4.2-beta) === Eric Wadsworthemail: [EMAIL PROTECTED] Conceptual Systems and Software http://www.consys.com ===
