UFS

Eugene Grosbein написал(а) к All в May 20 07:46:43 по местному времени:

хыхы

Author: chs
Date: Mon May 25 23:47:31 2020
New Revision: 361491
URL: https://svnweb.freebsd.org/changeset/base/361491

Log:
This commit enables a UFS filesystem to do a forcible unmount when
the underlying media fails or becomes inaccessible. For example
when a USB flash memory card hosting a UFS filesystem is unplugged.

The strategy for handling disk I/O errors when soft updates are
enabled is to stop writing to the disk of the affected file system
but continue to accept I/O requests and report that all future
writes by the file system to that disk actually succeed. Then
initiate an asynchronous forced unmount of the affected file system.

There are two cases for disk I/O errors:

- ENXIO, which means that this disk is gone and the lower layers
of the storage stack already guarantee that no future I/O to
this disk will succeed.

- EIO (or most other errors), which means that this particular
I/O request has failed but subsequent I/O requests to this
disk might still succeed.

For ENXIO, we can just clear the error and continue, because we
know that the file system cannot affect the on-disk state after we
see this error. For EIO or other errors, we arrange for the geom_vfs
layer to reject all future I/O requests with ENXIO just like is
done when the geom_vfs is orphaned. In both cases, the file system
code can just clear the error and proceed with the forcible unmount.

This new treatment of I/O errors is needed for writes of any buffer
that is involved in a dependency. Most dependencies are described
by a structure attached to the buffer's b_dep field. But some are
created and processed as a result of the completion of the dependencies
attached to the buffer.

Clearing of some dependencies require a read. For example if there
is a dependency that requires an inode to be written, the disk block
containing that inode must be read, the updated inode copied into
place in that buffer, and the buffer then written back to disk.

Often the needed buffer is already in memory and can be used. But
if it needs to be read from the disk, the read will fail, so we
fabricate a buffer full of zeroes and pretend that the read succeeded.
This zero'ed buffer can be updated and written back to disk.

The only case where a buffer full of zeros causes the code to do
the wrong thing is when reading an inode buffer containing an inode
that still has an inode dependency in memory that will reinitialize
the effective link count (i_effnlink) based on the actual link count
(inlink) that we read. To handle this case we now store the inlink
value that we wrote in the inode dependency so that it can be
restored into the zero'ed buffer thus keeping the tracking of the
inode link count consistent.

Because applications depend on knowing when an attempt to write
their data to stable storage has failed, the fsync(2) and msync(2)
system calls need to return errors if data fails to be written to
stable storage. So these operations return ENXIO for every call
made on files in a file system where we have otherwise been ignoring
I/O errors.

Coauthered by: mckusick
Reviewed by: kib
Tested by: Peter Нolm
Approved by: mckusick (mentor)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24088

Eugene
--- slrn/1.0.3 (FreeBSD)

Eugene Subbotin написал(а) к Eugene Grosbein в May 20 13:44:03 по местному времени:

On 26.05.2020 8:46, Eugene Grosbein wrote:

EG> Sponsored by: Netflix

Красавцы!

--- Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Trustedbird/24.3.0

Alex Korchmar написал(а) к Eugene Grosbein в May 20 00:23:14 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
EG> хыхы
шо, не прошло и пятидесяти лет с изобретения дискеты, как выдирание флэшки
на ходу стало можно?

И даже в panic не падает, или только если повезет?

EG> Coauthered by: mckusick
какие люди на нашем болоте. А в 94м он не мог то же самое сделать?

> Alex
P.S. а точку монтирования точно-точно освобождает, или как всегда?

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Eugene Subbotin в May 20 00:25:15 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Subbotin <Eugene.Subbotin@f128.n5075.z2.fidonet.org> wrote:

EG>> Sponsored by: Netflix
ES> Красавцы!
видимо, их таки зае...ло превращение системы в невосстанавливаемую тыкву.

А про "тут так принято!" и "отцы г-но жрали, деды г-но жрали..." они,
как обычно, не слышали.

Эх, кто бы им zfs как-нибудь хитро подсунул...


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в May 20 15:07:47 по местному времени:

27 мая 2020, среда, в 00:23 NOVT, Alex Korchmar написал(а):

AK> P.S. а точку монтирования точно-точно освобождает, или как всегда?

Это всё пока только в head, я не пробовал за неимением head,
но если это полноценный umount, хоть и forced, то должно.

Eugene
--- slrn/1.0.3 (FreeBSD)