Из документации ext4 :
When mounting an ext4 filesystem, the following option are accepted:
(*) == default
auto_da_alloc(*) Many broken applications don't use fsync() when
noauto_da_alloc replacing existing files via patterns such as
fd = open("foo.new")/write(fd,..)/close(fd)/
rename("foo.new", "foo"), or worse yet,
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
If auto_da_alloc is enabled, ext4 will detect
the replace-via-rename and replace-via-truncate
patterns and force that any delayed allocation
blocks are allocated such that at the next
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
blocks are forced to disk.
Судя по формулировке «испорченные приложения», разработчики ext4 определенно считают плохой практикой, но на практике это так широко используется. Подход, который был исправлен в самой ext4.
Так что, если ваше использование соответствует шаблону, вы должны быть в безопасности.
Если нет, я предлагаю вам продолжить расследование вместо того, чтобы вставлять fsync
здесь и там, чтобы быть в безопасности. Это может быть не очень хорошей идеей, поскольку fsync
может сильно повлиять на производительность в ext3 ( читать ).
С другой стороны, очистка перед переименованием является правильным способом замены файловых систем без журналирования. Может быть, поэтому ext4 сначала ожидала такого поведения от программ, опция auto_da_alloc
была добавлена позже как исправление. Также этот патч ext3 для режима обратной записи (без ведения журнала) пытается помочь неосторожным программам, асинхронно сбрасывая при переименовании, чтобы снизить вероятность потери данных.
Подробнее о проблеме ext4 можно прочитать здесь .
Проблема заключается в следующем:
SQLCLR не разрешает доступ к данным внутри TestFillRow
Несмотря на то, что "выглядит" так, как будто ваш TestFillRow не имеет доступа к данным, компилятор транслирует код с операторами yield фактически откладывают выполнение до первого вызова .MoveNext () итератора. Поэтому следующий оператор:
using (SqlConnection con = new SqlConnection ("context connection = true"))
выполняется внутри TestFillRow
... что недопустимо.
Не используйте yield return ; вместо этого загрузите весь результат в List <>
и верните список в конце функции UD.