АртемЪ: ADATA Premier Pro SP610 256ГБ. Общий размер 6*256. 2 машины, каждая в разделе в 100 гигов. Win2008R2. На 2 раздела по 100гиг, остальное пока свободно. Общий объем 200 гигов.
АртемЪ: на англиском, это фо документация, а на русском, вольный и куций перевод. В переводе почти ничего не сказано про линейное размещение.
Теперь по поводу множества действий.
Зачем менять физические разделы? Они у меня не изменены - отдан весь диск.
При добавление дисков, карта не меняется, она расширяется, т.е. то что и где было ,там и остается.
Логическая структура разделов, никак не влияет на экстенты.
По сути, условие только одно, не добавлять и не убирать диски, что происходит только в крайних случая и не является типовой операцией.
Для справки. Уже на данный момент, мой эксперементальный диск исчерпал все свободное место и деградировал. Теперь на со 100% уверенностью и достоверностью говорю - с lvm поверх рейда при соблюдение необходимых условий метод не работает. Буду пробовать на днях, сжать рейд и lvm.
АртемЪ: АртемЪ: это тот же ман, только перевод. Я привык работать с первоисточниками на родном их языке.
Вы не читаете то, на что сами ссылаетесь. Абстрагироваться, это да. Но не так как вы тут обрисовываете. LVM раздел имеет четкие границы, он знает, какое адресное пространство он может занять, а какое нет.
По вашей же ссылке все написано, только сжато. lvm создается поверх физического диска, в логике lvm происходит сопоставление физических блоков с lvm экстентами. И это соответствие не двигается и всегда одно и тоже, пока не происходит добавление устройства в lvm или подобные действия с физикой.
Для примера. Есть 100 физ блоков, делаем lvm получаем к примеру 50 экстентов по 2 физ блока, т.е. после того, как отдали диск или раздел под lvm мы работает с экстентами, но сам lvm с физикой.
И если у нас первый экстент занимает 1 и 2 физ блоки, а 2 экстент 3 и 4, то 2 экстента занимают с 1 по 4 физ блоки и это только так.
Если на этих экстентах мы делаем логический раздел, по факту физическим мы все так же занимаем с 1 по 4 блоги.
Поэтому убирать ничего никуда не надо, ваши требования к свободному месту выполняются и так, оно должно работать. Но не работает.
К тому же, я сделал замеры, как и обещал. На 100 гигабайтах (раздел на 256 гигабайтном ssd), за сутки при физической занятости в 30 гигов (т.е. информации с которой происходит активная работа), забивается 59323383808 bytes were trimmed
Т.е. почти весь диск. Без трима, линейный запрос через dd последовательно всех блоков (естественно на отмонтированом диске), показывает, что все реально так, и пустых блоков набегает коло 7 гигабайт. Предположительно, в конце этого дня, на диски не останется физически пустых ячеек и без трима начнутся тормоза. Об этом я тоже отпишусь. Хотя уже и так все очевидно.
Артем: и еще момент. Я могу сделать логический раздел на ту же половину диска, т.е. на этот объем, как бы по вашему мнению там не размазывались бы блоки, этот объем все равно не замажет. Сегодня попробую, сделаю раздел и поставлю на машине кристалмарк на максимум на ноч.
Артем: логические разделы не пишутся на весь диск, они имеют четкие границы в секторах. Особенно когда у меня один диск, который же рейд. Это вообще режим linear mapping, т.е. прямое, линейное соответствие физике диска.
Вы откуда вообще взяли про размазывание LVMом данных по диску? Я вот взял свою току зрения тут tldp.org/HOWTO/LVM-HOWTO, а вы свою где?
Артем: диск отдан под LVМ, это pvcreate /dev/sda например, т.е. создали физ том. Но тут нет файловой системы и ничего не пишется никуда. А дальше нарезано на кусочки по 100 гигов lvcreate -n vm -L 100G vm1 границы кусочков четкие по секторам, за границами ничего никуда не пишется. Получается диск свободен больше чем на половину, точнее массив.
mdadm и lvm работают прозрачно, они не натягивают ничего своего на диск, т. е. по сути, что рейд, что lvm это всего лишь метки в начале диска и не более.
Внимание вопрос, почему ваша схема не работает, если должна работать по вашей логике.
Артем: вы меня запутали уже. По порядку. LVM предоставляет разделы, и разделы эти имеют четкие секторыне границы, за пределами границ разделов, ничего писать не может, а значит по вашей схеме должно работать.
LVM никогда не имел и не имеет доступа ко всему диску, он занимает при выделение определенные сектора.
Жесткий диск не знает и не может знать, пустая у него ячейка или нет. Физически, он видит запись, но логически, есть там что то ценное, или это остаток от удаленного, он знать не может. Для этого и нужен трим, что бы передать диску, информацию от файловой системы.
Пустые ячейки на флешке и ссд, кончаются очень быстро, просто моментально, и без трим, единственный вариант очистки места сборщиком, это получение от файловой системы команды записать что то в те ячейки, которые по мнению диска заняты. Именно в этот момент, контроллер жесткого диска пишет в запасную область,а ту последовательность, которую получил от ФС очищает на будущее.
На плекстарах, это идет дальше, там контроллер не только очищает последовательность полученную от ФС, но он еще знает целостность актов записи, т.е. если в прошлый раз запись была с 1 по 100 ячейку, а в этот раз ФС хочет что то записать в 55 ячейку, контроллер стирает с 1 по 55 и с 55 по 100. Звучит страшно, но это вроде работает. Похожее есть и у других, у интела в частности.
Артем: отскок в запасною область, не выделенную самостоятельно, а заводскую (хотя и выделенную тоже), происходит в момент, когда при попытке записи диск попадает на грязную ячейку. Что бы не тупить, он пишет в чистую область, или в кэш, или еще куда то. Но к примеру плексторы, они при подобном пришествие, не пользуют область. Диск помнит в какие ячейки он писал недавно, и в них уже не попадая пробует еще раз. Со сборщиком мусора это дает эффект. Если подобных механизмов нет, все чистые области, даже если это половина диска, исчерпаются.
По вашей логике, у меня должно все работать отлично, если у меня половина массива свободна. Но оно не работает, оно деградирует.
То что постоянно пишется, просто обязано мешать механизму. Одно дело когда очистка проходит сразу после удаления, другое дело, когда даже через 15 минут.
Дайте мне хоть какую то ссылку, хотелось бы ту ссылку, которая дает уверенность вам, в отличности механизма, а то я нахожу только подтверждение своих слов, о неминуемой, хоть и отсроченной деградации.
Артем: у меня не плекстор и не интел, у меня нет алгоритмов на повторную запись, у меня самые банальные деревянные диски. Если не использовать трим, это все безбожно тормозит, ибо как выше я уже отвечал, интенсивность большая. Уповать на механизм подмены при попадание нельзя.
Прочитал я про вашу схему. Она должна работать независимо от того, есть ли рейд, нет ли его, и прочее. Но опять же - смотрим первый абзац.
Оно не может работать на сервер, ибо он сервер, и там постоянно что то пишется, и на обычных дешевых дисках, ибо там нет анализатора записи.
Артем: какой сборщик мусора то? Если его на винте нет? Как раз убираться и должен трим, и именно из за того, что на диске нет аппаратного сборщика я и парю всей этой затеей.
Артем: отрезанный косочеггг, работает только на чистом-одиночном диске, с поддержкой аппаратной очистки. В рейде, с lvm это работать не будет. Я вам же тут не теорию рассказываю, я вам по факту говорю. За неделю, скорость записи с 1700 мегабайт в сек, падает до 20 мегабайт в сек. Это тест, мой личный тест, на моей железяке.
mureevms: если бы я диск подключал как устройство, я бы не задавал тут вопросов, ибо было бы все очевидно. Моя хотелка, совершенно типичная, и мало того, она работает на других системах, о чем я вам уже выше не однократно написал. Не работает только на винде, хотя должна.
mureevms: это очень логично. Когда диск внутри машины это lvm кусок, гипервизор совершенно не в курсе, что там происходит, куда что пишется, какая там файловая система и прочее. Без трим, при таком раскладе вообще нечего, скорость деградирует очень быстро.
Схема настройки описана, но для сетевых блочных устройств и гостей на линуксе. Должно работать на винде, но не работает и даже вопросов, тем и обсуждений как то мало. Как будто я один с такой схемой и проблемой.