dangerous situation with shutdown process

[Matthias Buelow]

Bill Vermillion wrote:

>Copying very large files and then shutting down I hope is not a
>normal procecure for you.   softupdates sometimes do take a long
>time when you are removing/copying very large files.
>
>Others have suggested different time-outs but you'd have to figure
>out the largest size you may every encounter and set things for
>that, which is not going to help for everyday operation.
>
>I've watched the amount of disk space increase slowly by performing
>'df' and it can take a long time - up to a minute on some extremely
>large partitions I was cleaning.
>
>One way to force everything to be written I've found [by
>observation only] is to perform an fsck on that file system.
>
>If you only do huge copies and immediate shutdowns rarely, then
>maybe it's just a good idea to remember how softupdates work, and
>then fsck, then shutdown.
>
>I'm always against changing default operations from typical 
>operations to extremes.

Sorry folks, have I somehow dropped into a parallel universe,
or is there some serious misunderstanding going on?

To the OP: There is no "sync" process that is being killed by
shutdown. The kernel writes out all dirty buffers as part of its
shutdown procedure.

Bill, as I get it from what you wrote, correct me if I'm wrong,
you assume that:

 1. unmount doesn't wait for all dirty data being committed
    to disk before somehow removing the filesystem,
 2. fsck on a live filesystem will somehow speed things up.

For 1., this is surely not the case, the same as with shutdown,
the kernel of course writes (drive errors notwithstanding)
all modified buffers and updates all on-disk structures before
marking the fs clean, and
for 2., you should never fsck a mounted filesystem. Besides,
it is completely unnecessary.

If the OP has encountered any data corruption, this is due to
an unclean shutdown because of disk errors or a kernel bug,
and not because of "timeouts" that are too short or something
like that.

mkb.