On 10/10/99 12:12:52 you wrote:
"sirbruce" == sirbruce sirbruce@ix.netcom.com writes:
sirbruce> The problem is that with a changing filesystem, such sirbruce> programs could easily report a problem when in fact sirbruce> there is none. There are some ways around this.
Huh? If the filesystem is made immutable, it isn't a changing filesystem. e.g, on a Unix host, this _should_ be safe:
unmount filesystem. mount filesystem read-only. run fsck on filesystem. remount filesystem read-write.
Sure, but for many environments, read-only is not an option. It may be for you, but for others it's still downtime.
Why should I expect downtime? A failed disk is a problem, but it doesn't cause downtime. A failed power-supply is a problem, but it also doesn't cause downtime. A failed head is a problem, but in a cluster, no downtime (well, 60 seconds downtime). NA has designed the filer to stay up in the face of these problems. So if NA has a check list of problems and it is working its way down the check list to keep filers up in the face of these problems, then "file-system health-check and fix" needs to be added to that list. Sure, it isn't a common occurance, but clearly it happens often enough for NA to have written wack and constantly improved it over the years. I'm arguing that the next improvement is to allow wack to be run on an on-line filer.
Upgrading your software/firmware/disk firmware is more common. So is adding new cards into the system. Yet you expect downtime on those. So if what was most common was the measure of importance, then these should be worked on before an on-line wack.
I agree online wack is a good thing to have, but I guess I'm satisfied in seeing Netapp concentrate on other bugs and features first. I wasn't arguing that it shouldn't be done.
Bruce
I hereby ask again NetApp to work on this online wack issue. firmware/hardware/software fixes and upgrades takes no more than 15min max. downtime. Try to compare that with the hours it takes to run wack on a 600+ GB volumes (while the other volumes are infact OK, and COULD have been working at the same time...).
The volume could be offline, that's for sure, but why the machine ?
It doesn't happen a lot, but consider this - software/hardware/firmware upgrade usually YOU can schedule out, but a downed volume happens at the most critical times, and you need it working NOW !
Yours, Eyal.
sirbruce@ix.netcom.com wrote:
On 10/10/99 12:12:52 you wrote:
"sirbruce" == sirbruce sirbruce@ix.netcom.com writes:
sirbruce> The problem is that with a changing filesystem, such sirbruce> programs could easily report a problem when in fact sirbruce> there is none. There are some ways around this.
Huh? If the filesystem is made immutable, it isn't a changing filesystem. e.g, on a Unix host, this _should_ be safe:
unmount filesystem. mount filesystem read-only. run fsck on filesystem. remount filesystem read-write.
Sure, but for many environments, read-only is not an option. It may be for you, but for others it's still downtime.
Why should I expect downtime? A failed disk is a problem, but it doesn't cause downtime. A failed power-supply is a problem, but it also doesn't cause downtime. A failed head is a problem, but in a cluster, no downtime (well, 60 seconds downtime). NA has designed the filer to stay up in the face of these problems. So if NA has a check list of problems and it is working its way down the check list to keep filers up in the face of these problems, then "file-system health-check and fix" needs to be added to that list. Sure, it isn't a common occurance, but clearly it happens often enough for NA to have written wack and constantly improved it over the years. I'm arguing that the next improvement is to allow wack to be run on an on-line filer.
Upgrading your software/firmware/disk firmware is more common. So is adding new cards into the system. Yet you expect downtime on those. So if what was most common was the measure of importance, then these should be worked on before an on-line wack.
I agree online wack is a good thing to have, but I guess I'm satisfied in seeing Netapp concentrate on other bugs and features first. I wasn't arguing that it shouldn't be done.
Bruce
"Eyal" == Eyal Traitel r55789@email.sps.mot.com writes:
Eyal> I hereby ask again NetApp to work on this online wack issue. Eyal> firmware/hardware/software fixes and upgrades takes no more Eyal> than 15min max. downtime. Try to compare that with the Eyal> hours it takes to run wack on a 600+ GB volumes (while the Eyal> other volumes are infact OK, and COULD have been working at Eyal> the same time...).
Eyal> The volume could be offline, that's for sure, but why the Eyal> machine ?
Eyal> It doesn't happen a lot, but consider this - Eyal> software/hardware/firmware upgrade usually YOU can schedule Eyal> out, but a downed volume happens at the most critical times, Eyal> and you need it working NOW !
I hate when people do this on lists, but, "ditto".
j.
On Sun, 10 Oct 1999 sirbruce@ix.netcom.com wrote:
Sure, but for many environments, read-only is not an option. It may be for you, but for others it's still downtime.
Snapshots are read only. Sure checking snapshots for consistency won't find all the problems, but it will find many of them.
I agree online wack is a good thing to have, but I guess I'm satisfied in seeing Netapp concentrate on other bugs and features first.
I agree with you that lack of online wack is a bug. ;)
Tom
-
Eyal Traitel -
Jay Soffian -
sirbruce＠ix.netcom.com -
tkaczma＠gryf.net