On Sunday 22 July 2012 09:02:29 Erik Christiansen did opine:
> On 21.07.12 12:51, Gene Heskett wrote:
> > On Saturday 21 July 2012 12:14:51 Erik Christiansen did opine:
> > > To make sure we only have to debug nfs, what about trying in
> > > /etc/exports:
> > >
> > > /my/shared/filesystem 192.168.71.0/24(rw)
> >
> > I just changed it to this style on lathe, and it works, but shouldn't
> > I have a ,sync after the rw?
>
> OK, then that's not only a fix, but is more robust, since it doesn't
> rely on DNS being and staying good.
>
> You can put the "sync" in, and it is probably good form. However:
>
> "In releases of nfs-utils up to and including 1.0.0, this option was
> the default. In all releases after 1.0.0, sync is the default, and
> async must be explicitly requested if needed. To help make
> system administrators aware of this change, 'exportfs' will issue a
> warning if neither sync nor async is specified."
>
> So if a "sudo exportfs -r" does issue the warning, then "sync" ought to
> be optional, due to the default behaviour.
> (Yeah, I know, it's cheap insurance to just chuck it in.)
That returns the same info as a restart:exportfs: (on all currently online
machines)
/etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified
for export "192.168.71.3/24:/home/gene/".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
That ,no_subtre_check was in the default file before I elided it AIR.
> > That seems to be working on lathe. So I changed the shop machines
> > export file to hard address, and left the ,sync option in, restarted
> > its nfs- kernel-server, and now its working from a cli at least. and
> > so is mc although I haven't tried to copy anything yet.
>
> Now that's good to hear. While fixing up DNS could be an interesting
> exercise, that doesn't make any swarf, or empty out the aircon drip
> tray, I figure.
The aircon drip tray is 100% optional if the window unit is tipped down to
the outside end. In fact, at the expense of some corrosion of the
condenser coils, not a huge problem in the real world, if you dam it up so
the condenser is running ankle deep in the drip water, you will raise the
units efficiency a bit because the heat transfer to the evaporating water
will reduce the high side pressures a bit and the compressor doesn't have
to work as hard. I worked for a tv service shop in the '50's where they
were damed up enough that the fan blade ticked the surface of the standing
water distributing it over the rear of the condenser. Worked great.
Your trivia factoid for the day. :)
> Erik
True, but a small loophole, without it I can't make my .hal available so
the knowledgeable folks here can tell me I'm an idiot. :)
Which FWIW no one has, yet. I just put fresh copies as of now in the
Genes-os9-stf/GCode link of my web page. Critique's welcomed.
Which brings up a question since I have an error component to the filtered
pid.0.error output that doesn't scale with requested speed. So I think I
have a scale factor off in the encoders setp someplace. I say this because
I an under the impression that if all the pid.0.(P,I,D)gains are zeroed,
should it not take a pid.0.FF0 setp of 100 (%?) to make the pid
transparent? I don't have that condition now and I believe that to be part
of my problem, since this error signal wanders around, it makes my
electronic fuse stuff a bit touchy. It does work, I haven't blown a fuse
recently, but I think I've also had a nuisance trip or 17. Nothing damaged
either.
And I still haven't fired up that new rework station. :(
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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Don't hit a man when he's down -- kick him; it's easier.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
