|
Home > Archive > Unix administration > March 2007 > Bypassing a mount point w/'df'
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bypassing a mount point w/'df'
|
|
| chlebsco@rcn.com 2007-03-12, 1:23 pm |
| This particular installation is running HP-UX Release 11i: November
2000
Some batch jobs involve looking out to a fille system, one job in
particular tries to assure that enough free space (60 MB) exists prior
to exporting some rather large tables. Associated with this file
system is a mouint point (another physical Unix box) that has been
temporarily decommissioned (due to a failure). It won't be back for at
least a few days, though the particular job runs daily. The effect is
that the jobs hangs for some unspecified and inconsistent amount of
time. To boot, the process defies any 'kill' command.
Performing an unmount of the decommissioned mount point and reboot of
the box running the job is not possible. Short of commenting out the
space check, is there some way to bypass that mount point when the
'df' is executed?
I've already tried "-l" option, (Report on local file systems only),
which hung the process...I guess it considers this mount point as
something local. (hey, I'm a developer...NOT a Unix Admin.!!!)
script's command looks like this...
df -b /filearea | read a b c d e f g
It further evaluates the "e" (number of KB), if <60000000 it passes
back a FAIL code, otherwise it is successful.
| |
| Doug Freyburger 2007-03-12, 1:23 pm |
| chleb...@rcn.com wrote:
>
> Some batch jobs involve looking out to a fille system, one job in
> particular tries to assure that enough free space (60 MB) exists prior
> to exporting some rather large tables. Associated with this file
> system is a mouint point (another physical Unix box) that has been
> temporarily decommissioned (due to a failure). It won't be back for at
> least a few days, though the particular job runs daily. The effect is
> that the jobs hangs for some unspecified and inconsistent amount of
> time. To boot, the process defies any 'kill' command.
The bad news - If you need to rebuild that filesystem on the server,
it will have different handles and will require a umount and re-mount.
I hope your hardware problem is memory or something ...
> Performing an unmount of the decommissioned mount point and reboot of
> the box running the job is not possible. Short of commenting out the
> space check, is there some way to bypass that mount point when the
> 'df' is executed?
For a couple of days better to comment out the check. Else switch
it to a specific list of directories other than the hung one.
> I've already tried "-l" option, (Report on local file systems only),
> which hung the process...I guess it considers this mount point as
> something local. (hey, I'm a developer...NOT a Unix Admin.!!!)
I always hated that. Descend into a directory *then* check if you
are still local. Hang if descending into it does not work ....
| |
|
| Begin <1173717997.904983.219250@8g2000cwh.googlegroups.com>
On 2007-03-12, Doug Freyburger <dfreybur@yahoo.com> wrote:
> I always hated that. Descend into a directory *then* check if you
> are still local. Hang if descending into it does not work ....
To be fair, the hang is probably caused by filesystem blocking until nfs
comes back up. It might be that there's just about nothing that df alone
can do to prevent this. Options to the nfs mount might help, though.
Oh and an ObNitPick to the OP: df -b does not give you a kB count.
In fact, it specifically instructs df not to. See man df.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
| |
| Doug Freyburger 2007-03-13, 1:29 pm |
| jpd <read_the_...@do.not.spam.it.invalid> wrote:
> On 2007-03-12, Doug Freyburger <dfrey...@yahoo.com> wrote:
>
>
> To be fair, the hang is probably caused by filesystem blocking until nfs
> comes back up. It might be that there's just about nothing that df alone
> can do to prevent this. Options to the nfs mount might help, though.
>
> Oh and an ObNitPick to the OP: df -b does not give you a kB count.
> In fact, it specifically instructs df not to. See man df.
While your point applies to the earlier parts of the thread - The OP's
hang is definitely because the NFS dserver is down - it does not
address my complaint. "find" should not be written in terms of
descending into a directory and detecting a hang-forever state by
hanging forever. If -xdev or -mount or -local or -fstype is set it
should
check the directory against the mount point list first, then descend
into it and use an fstat() call to figure out if it should ascend back
out.
| |
| chlebsco@rcn.com 2007-03-15, 7:24 pm |
| On Mar 12, 1:09 pm, jpd <read_the_...@do.not.spam.it.invalid> wrote:
> Begin <1173717997.904983.219...@8g2000cwh.googlegroups.com>
> On 2007-03-12, Doug Freyburger <dfrey...@yahoo.com> wrote:
>
>
> Oh and an ObNitPick to the OP: df -b does not give you a kB count.
> In fact, it specifically instructs df not to. See man df.
>
My man page for 'df' says, in part...
DESCRIPTION
The df command displays the number of free 512-byte blocks and
free
inodes available for file systems by examining the counts kept
in the
superblock or superblocks. If a special or a directory is not
specified, the free space on all mounted file systems is
displayed.
If the arguments to df are path names, df reports on the file
systems
containing the named files. If the argument to df is a special
of an
unmounted file system, the free space in the unmounted file
system is
displayed.
Options
df recognizes the following options:
-b Report only the number of kilobytes (KB)
free.
(Hewlett-Packard Company HP-UX Release 11i: November
2000)
....so it appears to say that is what it gives ...what am I missing???
Oh, btw, the server is back and 'df' doen't hang anymore...we'll see
how we perform tonight.
| |
|
| Begin <1173996194.058466.13600@y66g2000hsf.googlegroups.com>
On 2007-03-15, chlebsco@rcn.com <chlebsco@rcn.com> wrote:
> On Mar 12, 1:09 pm, jpd <read_the_...@do.not.spam.it.invalid> wrote:
>
> My man page for 'df' says, in part...
[snip!]
> df recognizes the following options:
>
> -b Report only the number of kilobytes (KB)
> free.
I knew I should've double-checked, altough now I see that the HTML
rendering of the HP-UX df(1) as found on FreeBSD.org loses the `-b' bit.
Anyway, on the FreeBSD system I use (surprise!) it means using 512 byte
blocks. On a handy linux system it doesn't have any -b at all. Oops.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
| |
| chlebsco@rcn.com 2007-03-17, 1:22 pm |
| On Mar 16, 1:10 am, jpd <read_the_...@do.not.spam.it.invalid> wrote:
> Begin <1173996194.058466.13...@y66g2000hsf.googlegroups.com>
> On 2007-03-15, chleb...@rcn.com <chleb...@rcn.com> wrote:
>
>
> [snip!]
>
>
> I knew I should've double-checked, altough now I see that the HTML
> rendering of the HP-UX df(1) as found on FreeBSD.org loses the `-b' bit.
> Anyway, on the FreeBSD system I use (surprise!) it means using 512 byte
> blocks. On a handy linux system it doesn't have any -b at all. Oops.
>
> --
> j p d (at) d s b (dot) t u d e l f t (dot) n l .
> This message was originally posted on Usenet in plain text.
> Any other representation, additions, or changes do not have my
> consent and may be a violation of international copyright law.
THANKS!!!
|
|
|
|
|