Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: fopen режимы для использования цикла и filesize
Форумы портала PHP.SU » » Вопросы новичков » fopen режимы для использования цикла и filesize

Страниц (2): [1] 2 »
 

1. heilong - 29 Октября, 2020 - 01:40:17 - перейти к сообщению
Привет. Я очень новичковый новичок, поэтому вопрос наверняка лёгкий, но навыки гугла у меня недостаточные, поэтому без помощи никак не тяну.
Хочу создать функцию генератор файла, и она работает, но с определённого момента выдаёт некорректный ответ.
PHP:
скопировать код в буфер обмена
  1. $fillfile = fopen("test/genX.txt", "a");
  2. $x = 0;
  3. while ($x < 20) {
  4.   fwrite($fillfile, $x);
  5.   $x++;
  6.   // echo filesize("test/genX.txt")."<br>";
  7. }
  8. fclose($fillfile);

Ниже вывожу строкой файл и его длину. Но как только подключаю ту закомментированную строчку, файл выводится как 0, а длина 1. Если же в цикл поставить условие filesize, то сценарий вообще виснет. Не представляю, смогу ли разобраться в такой мистике, хотя думаю, что не до конца разобрался в разницах между rr+ww+aa+cc+ etc. Спасибо.
2. LIME - 30 Октября, 2020 - 00:53:29 - перейти к сообщению
всей правды никто не знает, но я слышал что filesize использует кэшированную информацию о файле
где то тут было https://www.php.net/manual/ru/fu...ion.filesize.php в примечаниях
heilong пишет:
Если же в цикл поставить условие filesize, то сценарий вообще виснет
это смотря как поставить
то есть надо видеть
скорее всего получился цикл без выхода

Жена программиста больше часа ждет его из душа. Заходит, а он там стоит лысый с остекленевшими глазами и смотрит на пустой флакон шампуня. Она заглядывает чараз плечо, а там: "Нанести. Смыть. Процесс повторить."

(Добавление)
http://phpfaq[dot]ru/debug
3. heilong - 30 Октября, 2020 - 10:18:53 - перейти к сообщению
LIME пишет:
то есть надо видеть
скорее всего получился цикл без выхода

Ну я этот filesize использовал именно для такой кустарной отладки, изначально оттуда проблема и возникла, из условия цикла. Мне хотелось заполнять файл, пока его размер не превысит, скажем, 4000 из тестовой задачи.
PHP:
скопировать код в буфер обмена
  1. $fillfile = fopen("test/genX.txt", "a");
  2. while ( (filesize("test/genX.txt")) < 4000) {
  3.   fwrite($fillfile, "абвгд");
  4. }
  5. fclose($fillfile);

И как я понял, эта функция не настолько очевидная, чтобы просто работать по запросу. Здесь вообще нет наглядного понимания, с чего бы циклу виснуть, но оно происходит.
4. Мелкий - 30 Октября, 2020 - 10:25:23 - перейти к сообщению
Цитата:
Note: The results of this function are cached. See clearstatcache() for more details.

https://www.php.net/manual/en/fu...ion.filesize.php
Всё как по рецепту
5. LIME - 30 Октября, 2020 - 10:37:48 - перейти к сообщению
LIME пишет:
я слышал что filesize использует кэшированную информацию о файле
где то тут было https://www.php.net/manual/ru/fu...ion.filesize.php в примечаниях
heilong пишет:
Здесь вообще нет наглядного понимания, с чего бы циклу виснуть
ну почему же
наглядно понятно что не выполняется условие выхода из цикла
а не выполняется именно из-за кэширования filesize
и если ты потрудишься перейти по ссылке и почитать и там где надо(в примечании) еще раз перейти и почитать - ты все поймешь
(Добавление)
хотя пожалуй на вопрос "а что делать?" ты можешь сам и не догадаться ответить даже после прочтения ввиду полнейшей неопытности
перед каждым вызовом filesize вызывай clearstatcache для сброса кэша
и поясняю сразу для чего нужен кэш - для того чтобы диск не дергать на каждый вызов filesize(это дорого по времени изза механической природы чтения с диска), спорное решение, но оно так есть
(Добавление)
LIME пишет:
всей правды никто не знает
и вот сейчас понял что зря это написал и ввел в заблуждение
имелось ввиду что по дороге к записи есть еще всякие кэши, например элементарно дисковый кэш
то есть при записи пых вызывает команду ос, которая может сама накапливать буфер для записи, и которая передает данные диску, который тоже имеет свой буфер
и все это зависит от ос и производителя диска и его модели
сколько там всех этих кэшей по дороге хз, никто не знает в общем случае))
то есть если даже тебе пых скажет что запись произошла - не факт что она произошла физически(пишушая головка еще не записала)
например всякие топ хранилища типа мускула итд не используют команды ос, а пишут сами на диск на низком уровне, чтобы минимизировать шанс потери транзакции
грузанул изрядно наверное))
к данному случаю это не сильно относится и наверное ввело в заблуждение))
6. Мелкий - 30 Октября, 2020 - 11:28:28 - перейти к сообщению
LIME пишет:
например всякие топ хранилища типа мускула итд не используют команды ос

Именно стандартные syscall системные все и дёргают.
На raw device емнип вовсе только оракл умеет. Потому что там хватает денег и народу пилить _очень_ много сопутствующей обвязки. А всем остальным это слишком геморойно как по разработке, так и по дальнейшему сопровождению.
Но что как раз критично для всех СУБД и как раз позволяет обеспечивать durability - вызов fsync. И бывает очень больно, если на каком-то из уровней кэширования io fsync не выполняет свою задачу. Но это про СУБД

А история clearstatcache машинерии легко прослеживается до 1999 года PHP3, дальше немного теряется и мне не очень интересно продолжать археологию.
7. LIME - 30 Октября, 2020 - 11:58:01 - перейти к сообщению
Мелкий пишет:
Именно стандартные syscall системные все и дёргают.
спорить не стану - в исходниках не смотрел, а ты ближе к теме
кто-то "умный" как-то обмолвился, возможно только оракл, но сути не меняет для илюстрации "всей правды никто не знает"
Мелкий пишет:
И бывает очень больно
с практической точки зрения это конечно должны ооочень звезды сойтись чтобы "электричество кончилось" как раз ровно между ответом об успешной транзакции(читай сдвига версии) и физической записью wal и чтобы у диска был буфер и небыло своего аккумулятора и/или энергонезависимой памяти для буфера и хз что еще
но в теории знать о таком полезно для общей картины
или есть конкретные примеры?
8. Мелкий - 30 Октября, 2020 - 12:34:24 - перейти к сообщению
LIME пишет:
или есть конкретные примеры?

Есть конечно. Регулярно у всяких 1с выключен fsync, а потом плачутся на форумах "бекапов нет, электричество моргнуло, база не стартует, спасите бизнес (нет, платить за это мы конечно не будем)"

WAL-то как писать, если fsync свою задачу не выполняет? А чекпойнты как делать? И выходит что ни чекпойнтов ни WAL нет и соответственно при любом внеплановом reset'е (электричество? kernel panic? thermal sensor?) вся база с некоторым шансом становится большой кучей бесполезного бинарного мусора. До консистентного состояния невосстановимой в принципе. Потому что когда надо было гарантировать что данные записаны - кто-то ответил ОК, но не сделал этого.

Цитата:
между ответом об успешной транзакции(читай сдвига версии) и физической записью wal

При полном ACID порядок обратный: сначала ждём fsync wal до нужной позиции, только потом отвечаем "commit". Для весьма многих проектов потеря хвоста обычно не так страшна как существенное уменьшение io и резонно ставить асинхронный коммит, когда не ждём fsync wal. Но сам fsync всё равно обязан быть и обязан отрабатывать корректно на всех уровнях кэширования io.
9. LIME - 30 Октября, 2020 - 12:41:58 - перейти к сообщению
Мелкий пишет:
если fsync свою задачу не выполняет
ах ты об этом
я об "честном" положительном ответе fsync, но при этом незаписи фактически
разные вещи)) первое я даже рассматривать отказываюсь))
Мелкий пишет:
При полном ACID
никто не говорил об ACID
хранилища nosql тоже пишут wal и даже без транзакций имеют проблему незаписи фактически
Мелкий пишет:
и обязан отрабатывать корректно на всех уровнях кэширования io.
кроме самого последнего уровня - кэша диска, в котором есть свой durability в виде того о чем выше сказал, но это уже после fsync
значит таких примеров нет...ок
(Добавление)
асинхронная запись это уже решение(выбор) уровня приложения и тоже не рассматривается само собой
10. Мелкий - 30 Октября, 2020 - 13:07:00 - перейти к сообщению
LIME пишет:
кроме самого последнего уровня - кэша диска, в котором есть свой durability в виде того о чем выше сказал, но это уже после fsync

"на всех" - это включая сам диск. Если диск некорректно реагирует на fsync - отвечает ОК когда не может этого гарантировать - это тоже к приключениям.
11. LIME - 30 Октября, 2020 - 13:31:24 - перейти к сообщению
Мелкий пишет:
отвечает ОК когда не может этого гарантировать
в том и дело
это грань логики и физики, и абсолютно корректно тут уже сложнее гарантировать
например диск взял в буфер запись - ответил ок - приложение побежало дальше - и перед фактической записью ошибся (по мильону причин)
тоесть можем пытаться снижать вероятность но это не факт что сработает
и точка самой записи пишушей головкой тут самое слабое место
Мелкий пишет:
Если диск некорректно реагирует на fsync
так он коректно отреагировал - честно ответил что записал, а по факту просто взял в кэш и иначе не может быть, не может он ждать каждой записи в общем случае
короче все всё поняли)) CAP-теорема и всетакое)) но вот когда включается физика тут уже fsync время прошло
это не приключения а суровые факты жизни)) но на практике надо очень многим совпадениям произойти(исключаем баги итд) чтобы крашнуло имено в ненужный момент и не сработала защита самого диска в виде буфера на маленьком ssd итп
(Добавление)
я о том что диск отвечает на fsync в момент принятия в буфер
не после самой записи
по понятным причинам
а далее работаем с тем что имеем
12. Мелкий - 30 Октября, 2020 - 13:53:50 - перейти к сообщению
LIME пишет:
я о том что диск отвечает на fsync в момент принятия в буфер

Нет. Потому и есть write, а есть fsync.
13. LIME - 30 Октября, 2020 - 14:05:25 - перейти к сообщению
как нет если да? я про внутренний кэш самого дискового устройства
который набирает в себя пока головка читает например
(Добавление)
никак ты не поймешь о чем я
мы о разных вещах говорим или я чегото не понимаю?
(Добавление)
Мелкий пишет:
Потому и есть write, а есть fsync.
а да?)))
(Добавление)
само физическое устройство имеет буфер
да?
(Добавление)
хм...подозреваю что я не доконца понимаю работу синка
тоесть он работает синхронно до упора?
прям реализация драйвера диска ждет именно записи на болванку при синке несмотря на кэш самого диска?
(Добавление)
тоесть прям заставляет выбросить кэш на болванку? прям внутри самого диска?
14. Мелкий - 30 Октября, 2020 - 14:51:53 - перейти к сообщению
То есть сначала идут write и их имеют право кэшировать и откладывать во времени все кому не лень.
А когда приложение требует fsync то файловая система проверяет и делает write всех грязных страниц ассоциированных с этим дескриптором из своего page cache, затем спускает инструкцию "а теперь отчитайтесь, что данные сохранены". Что в частностях протоколов ATA/SATA превращается в команду FLUSH CACHE (E7h) или FLUSH CACHE EXT (EAh):
ACS-2 draft пишет:
The FLUSH CACHE command requests the device to flush the volatile write cache. If there is data in the volatile write cache, that data shall be written to the non-volatile media. This command shall not indicate completion until the data is flushed to the non-volatile media or an error occurs.

Только после этого всего нормально работающий fsync возвращает ОК приложению.
15. LIME - 30 Октября, 2020 - 15:12:30 - перейти к сообщению
Мелкий спасибо
теперь сложилось понимание моего заблуждения
тогда уточняющий вопрос - зачем оракл заморочился? чтоб не зависеть от реализаций протоколов? шоб наверняка?
(Добавление)
или тонкая оптимизация?

 

Powered by ExBB FM 1.0 RC1