Hi,
I need to get a handle on how long it should take to shutdown QNX
gracefully. The system would be a 586 class PC running at 100 MHz from a
DiskOnChip. I have been able to connect a power supply fail signal to an
interrupt and shutdown the system using Proc _PROC_SHUTDOWN messages. I set
the signal in the first message to SIGPWR and set the second message to -1.
In between the messages I do a sync() and then wait. It appears that I need
to wait almost 1 full second before sending the second message to Proc to
shutdown the system or else when I power up, I get chkfsys messages about
extents being too big, busy files and so on. I do not care if files that I
am writing are not closed before shutdown; I only need to ensure that the
important filesystem data is accurate. I have also tried sending everyone a
SIGPWR and then sending just Fsys a SIGTERM and waiting until Fsys is dead,
but that hasn’t helped.
My questions:
What is the file size and versions of the 4.25 Fsys (from sin ver)
that is supposed to handle SIGTERM signals gracefully?
Has anyone been able to gracefully shutdown QNX within 500 msec? If
so, what sort of hardware did you use? How did you do it?
Hi,
I need to get a handle on how long it should take to shutdown QNX
gracefully. The system would be a 586 class PC running at 100 MHz from a
DiskOnChip. I have been able to connect a power supply fail signal to an
interrupt and shutdown the system using Proc _PROC_SHUTDOWN messages. I set
the signal in the first message to SIGPWR and set the second message to -1.
In between the messages I do a sync() and then wait. It appears that I need
to wait almost 1 full second before sending the second message to Proc to
shutdown the system or else when I power up, I get chkfsys messages about
extents being too big, busy files and so on. I do not care if files that I
am writing are not closed before shutdown; I only need to ensure that the
important filesystem data is accurate. I have also tried sending everyone a
SIGPWR and then sending just Fsys a SIGTERM and waiting until Fsys is dead,
but that hasn’t helped.
My questions:
What is the file size and versions of the 4.25 Fsys (from sin ver)
that is supposed to handle SIGTERM signals gracefully?
Has anyone been able to gracefully shutdown QNX within 500 msec? If
so, what sort of hardware did you use? How did you do it?
Marc.
I have not tried this but it will be an issue for me too.
Have you tried running Fsys with 0 cache?
What is the file size and versions of the 4.25 Fsys (from sin ver)
that is supposed to handle SIGTERM signals gracefully?
Fsys 4.24N and later will handle SIGTERM by flushing out any dirty
blocks in cache, disabling further delayed writes, refusing any
subsequent open()s, and terminating the disk drivers cleanly, and
then finally exiting itself when this process is completed.
Has anyone been able to gracefully shutdown QNX within 500 msec? If
so, what sort of hardware did you use? How did you do it?
You may have difficulties with flash due to slow speed and erase issues.
You should contact M-Systems directly for such figures for your DOC.
I have Fsys 4.24S, so I should have a proper version. Instead of
terminating every process using the Proc shutdown message with a signal of
SIGPWR, and then sending a Proc shutdown that sends SIGTERMs, should I first
(or maybe just) send Fsys a SIGTERM, wait and exit?
Also, I am assuming that if chkfsys prints any messages about fixing the
disk (e.g. file busy (erroneously): FIXED, first extent too big for size:
FIXED) that this means that Fsys wasn’t able to properly shutdown in time.
Is this correct? Did Fsys have more information that it may have wanted to
update but was interrupted?
Marc Desjardine <> 2049526230@fido.ca> > wrote:
What is the file size and versions of the 4.25 Fsys (from sin ver)
that is supposed to handle SIGTERM signals gracefully?
Fsys 4.24N and later will handle SIGTERM by flushing out any dirty
blocks in cache, disabling further delayed writes, refusing any
subsequent open()s, and terminating the disk drivers cleanly, and
then finally exiting itself when this process is completed.
Has anyone been able to gracefully shutdown QNX within 500 msec? If
so, what sort of hardware did you use? How did you do it?
You may have difficulties with flash due to slow speed and erase issues.
You should contact M-Systems directly for such figures for your DOC.
I have Fsys 4.24S, so I should have a proper version. Instead of
terminating every process using the Proc shutdown message with a signal of
SIGPWR, and then sending a Proc shutdown that sends SIGTERMs, should I
first (or maybe just) send Fsys a SIGTERM, wait and exit?
Also, I am assuming that if chkfsys prints any messages about fixing the
disk (e.g. file busy (erroneously): FIXED, first extent too big for size:
FIXED) that this means that Fsys wasn’t able to properly shutdown in time.
Is this correct? Did Fsys have more information that it may have wanted to
update but was interrupted?
Hmm, just tried this out. Sadly QNX4 Fsys is nowhere near as nice
as QNX6 io-blk when it comes to termination The SIGTERM process
does not actually make inodes themselves logically consistent (only
forces them to disk in their current state), so you can still get the
“busy”-style errors from files which were open/growing. Sending a
SIGPWR/SIGTERM to all processes will make them close() their files,
which will make the inodes consistent prior to the Fsys SIGTERM
flushing them out, which should stop these chkfsys complaints at
reboot (although enough information was written to allow the repair
to be successful). It also gives applications a chance to flush out
any local data (although you say you don’t care about that). Only
giving the SIGTERM to Fsys is quicker but does involve chkfsys to
repair logical consistency. With regards to your limited time,
note that the full/clean shutdown may involve pruning back any
over-allocated blocks (the “busy” state) which may involve multiple
writes to the bitmap and inode and extent blocks. Have you tried
mounting the filesystem “-s” (synchronous) to avoid these issues
(throughput performance will be affected but the work at shutdown
will be much less, you’ll need to upgrade to Fsys 4.24W for fixes,
although again it is not as consistent as QNX6 for doing this).
Thanks John, I really appreciate the info. It also helps that finding a
solution is looking good. What I really need to be accomplished by this
auto shutdown is that I don’t interrupt a write to the DiskOnChip.
So as long as I give Fsys enough time to do it’s thing and terminate, then
there will be no further writes to the disk and thus, no chance for a disk
write to be interrupted. I will likely see messages regarding the
filesystem being fixed, but they are not being caused by Fsys being
interrupted while writing to the disk - it is simply caused by the fact that
filesystem was left in an ‘in use - but safe’ state and needed to be cleaned
up. Did I understand this all correctly?
Marc Desjardine <> 2049526230@fido.ca> > wrote:
I have Fsys 4.24S, so I should have a proper version. Instead of
terminating every process using the Proc shutdown message with a signal
of
SIGPWR, and then sending a Proc shutdown that sends SIGTERMs, should I
first (or maybe just) send Fsys a SIGTERM, wait and exit?
Also, I am assuming that if chkfsys prints any messages about fixing the
disk (e.g. file busy (erroneously): FIXED, first extent too big for
size:
FIXED) that this means that Fsys wasn’t able to properly shutdown in
time.
Is this correct? Did Fsys have more information that it may have wanted
to
update but was interrupted?
Hmm, just tried this out. Sadly QNX4 Fsys is nowhere near as nice
as QNX6 io-blk when it comes to termination > > The SIGTERM process
does not actually make inodes themselves logically consistent (only
forces them to disk in their current state), so you can still get the
“busy”-style errors from files which were open/growing. Sending a
SIGPWR/SIGTERM to all processes will make them close() their files,
which will make the inodes consistent prior to the Fsys SIGTERM
flushing them out, which should stop these chkfsys complaints at
reboot (although enough information was written to allow the repair
to be successful). It also gives applications a chance to flush out
any local data (although you say you don’t care about that). Only
giving the SIGTERM to Fsys is quicker but does involve chkfsys to
repair logical consistency. With regards to your limited time,
note that the full/clean shutdown may involve pruning back any
over-allocated blocks (the “busy” state) which may involve multiple
writes to the bitmap and inode and extent blocks. Have you tried
mounting the filesystem “-s” (synchronous) to avoid these issues
(throughput performance will be affected but the work at shutdown
will be much less, you’ll need to upgrade to Fsys 4.24W for fixes,
although again it is not as consistent as QNX6 for doing this).
Yes, I think so. Not SIGTERMing the apps will necessitate a chkfsys.
You could also investigate reducing the amount of data to write at
termination by using either “mount -s” or “Fsys -d1”. Note that after
flushing its caches, Fsys will send a _DRIVER_UNIT_CLOSE and a
_DRIVER_TERMINATE to any disk drivers; what exactly Fsys.diskonchip
does with that is something you’d need to confirm with M-Systems, but
the assumption would be that it leaves the flash in a consistent state.
Keep the power up until Fsys terminates (waitpid or qnx/fsys32 name).
The SIGTERM process