miketomlin для обновления PATCH
PUT для создания с заранее известным link(id передаем вместе с данными)
POST - создание и возвращение link(id генерит сервер)
а еще не факт что будет этот самый DOCUMENT_ROOT
а вдруг из CLI будет вызов...или из другого порта(в терминах "архитектуры портов и адаптеров") (Добавление) Строитель __DIR__ норм (Добавление) Igoresos гугли абсолютные и относительные пути
ЧПУ(человеко понятный УРЛ)
гуглить по твоему веб-серверу
apache2 чпу
nginx чпу
материала масса
а самое лучшее это делать чпу на уровне роутинга приложения(фреймворка), но это тебе долго рассказывать
начни с чпу вебсервера, но знай что это плохо и надо изучать фреймворки
Мелкий спасибо
теперь сложилось понимание моего заблуждения
тогда уточняющий вопрос - зачем оракл заморочился? чтоб не зависеть от реализаций протоколов? шоб наверняка? (Добавление)
или тонкая оптимизация?
как нет если да? я про внутренний кэш самого дискового устройства
который набирает в себя пока головка читает например (Добавление)
никак ты не поймешь о чем я
мы о разных вещах говорим или я чегото не понимаю? (Добавление)
Мелкий пишет:
Потому и есть write, а есть fsync.
а да?))) (Добавление)
само физическое устройство имеет буфер
да? (Добавление)
хм...подозреваю что я не доконца понимаю работу синка
тоесть он работает синхронно до упора?
прям реализация драйвера диска ждет именно записи на болванку при синке несмотря на кэш самого диска? (Добавление)
тоесть прям заставляет выбросить кэш на болванку? прям внутри самого диска?
в том и дело
это грань логики и физики, и абсолютно корректно тут уже сложнее гарантировать
например диск взял в буфер запись - ответил ок - приложение побежало дальше - и перед фактической записью ошибся (по мильону причин)
тоесть можем пытаться снижать вероятность но это не факт что сработает
и точка самой записи пишушей головкой тут самое слабое место
Мелкий пишет:
Если диск некорректно реагирует на fsync
так он коректно отреагировал - честно ответил что записал, а по факту просто взял в кэш и иначе не может быть, не может он ждать каждой записи в общем случае
короче все всё поняли)) CAP-теорема и всетакое)) но вот когда включается физика тут уже fsync время прошло
это не приключения а суровые факты жизни)) но на практике надо очень многим совпадениям произойти(исключаем баги итд) чтобы крашнуло имено в ненужный момент и не сработала защита самого диска в виде буфера на маленьком ssd итп (Добавление)
я о том что диск отвечает на fsync в момент принятия в буфер
не после самой записи
по понятным причинам
а далее работаем с тем что имеем
ах ты об этом
я об "честном" положительном ответе fsync, но при этом незаписи фактически
разные вещи)) первое я даже рассматривать отказываюсь))
Мелкий пишет:
При полном ACID
никто не говорил об ACID
хранилища nosql тоже пишут wal и даже без транзакций имеют проблему незаписи фактически
Мелкий пишет:
и обязан отрабатывать корректно на всех уровнях кэширования io.
кроме самого последнего уровня - кэша диска, в котором есть свой durability в виде того о чем выше сказал, но это уже после fsync
значит таких примеров нет...ок (Добавление)
асинхронная запись это уже решение(выбор) уровня приложения и тоже не рассматривается само собой
Именно стандартные syscall системные все и дёргают.
спорить не стану - в исходниках не смотрел, а ты ближе к теме
кто-то "умный" как-то обмолвился, возможно только оракл, но сути не меняет для илюстрации "всей правды никто не знает"
Мелкий пишет:
И бывает очень больно
с практической точки зрения это конечно должны ооочень звезды сойтись чтобы "электричество кончилось" как раз ровно между ответом об успешной транзакции(читай сдвига версии) и физической записью wal и чтобы у диска был буфер и небыло своего аккумулятора и/или энергонезависимой памяти для буфера и хз что еще
но в теории знать о таком полезно для общей картины
или есть конкретные примеры?
Здесь вообще нет наглядного понимания, с чего бы циклу виснуть
ну почему же
наглядно понятно что не выполняется условие выхода из цикла
а не выполняется именно из-за кэширования filesize
и если ты потрудишься перейти по ссылке и почитать и там где надо(в примечании) еще раз перейти и почитать - ты все поймешь (Добавление)
хотя пожалуй на вопрос "а что делать?" ты можешь сам и не догадаться ответить даже после прочтения ввиду полнейшей неопытности
перед каждым вызовом filesize вызывай clearstatcache для сброса кэша
и поясняю сразу для чего нужен кэш - для того чтобы диск не дергать на каждый вызов filesize(это дорого по времени изза механической природы чтения с диска), спорное решение, но оно так есть (Добавление)
LIME пишет:
всей правды никто не знает
и вот сейчас понял что зря это написал и ввел в заблуждение
имелось ввиду что по дороге к записи есть еще всякие кэши, например элементарно дисковый кэш
то есть при записи пых вызывает команду ос, которая может сама накапливать буфер для записи, и которая передает данные диску, который тоже имеет свой буфер
и все это зависит от ос и производителя диска и его модели
сколько там всех этих кэшей по дороге хз, никто не знает в общем случае))
то есть если даже тебе пых скажет что запись произошла - не факт что она произошла физически(пишушая головка еще не записала)
например всякие топ хранилища типа мускула итд не используют команды ос, а пишут сами на диск на низком уровне, чтобы минимизировать шанс потери транзакции
грузанул изрядно наверное))
к данному случаю это не сильно относится и наверное ввело в заблуждение))
Если же в цикл поставить условие filesize, то сценарий вообще виснет
это смотря как поставить
то есть надо видеть
скорее всего получился цикл без выхода
Жена программиста больше часа ждет его из душа. Заходит, а он там стоит лысый с остекленевшими глазами и смотрит на пустой флакон шампуня. Она заглядывает чараз плечо, а там: "Нанести. Смыть. Процесс повторить."
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 10716
