*** Oleksandr Gavenko [2017-07-07 18:51]:
>Интересно, восстановление в случае упавшего диска в ZFS также затронет только
>используемые блоки? Ведь эта оптимизация на уровне FS, где присутствует
>необходимая информация. Это должно сэкономить время восстановления в 2-3 и
>более раз в зависимости кол
On 2017-07-07, Oleksandr Gavenko wrote:
> В случае ZFS, Btrfs скрабинг будет выполняться по используемым блокам, что
> эффективней чем в случае md сканировать весь массив. И с md нет контрольных
> сумм что бы выяснить какой диск обманывает.
Интересно, восстановление в случае упавшего диска в ZFS
On 2017-06-23, Oleksandr Gavenko wrote:
> Тут писали про CD/DVD, флешки, диски.
https://en.wikipedia.org/wiki/M-DISC
Millenniata testing found that M-Disc DVDs are more durable than
conventional DVDs. "The discs were subject to the following test conditions
in the environmental chamber: 85
On 06/07/17 05:33 PM, Vasiliy P. Melnik wrote:
> Такое впечатление, что у всех отсутствует возможность поставить себе
> виртуальную машину и протестировать.
>
Ты прав, возможность есть, даже время запланировано. Приблизительно на
следующей неделе.
До той поры пытаюсь ответить на вопросы, которые бу
Такое впечатление, что у всех отсутствует возможность поставить себе
виртуальную машину и протестировать.
7 июля 2017 г., 0:19 пользователь Tim Sattarov написал:
> On 06/07/17 04:43 PM, Sergey Matveev wrote:
> > *** Tim Sattarov [2017-07-06 23:04]:
> >> сейчас я вижу требование о равных размера
*** Tim Sattarov [2017-07-07 00:20]:
>А если там был RAIDZ ? и я в группу из 1ТБ дисков добавляю ещё один 2ТБ
>Будет ли весь объём использован ?
Будет использован 1TB из него. Когда все диски будут заменены на 2TB, то
тогда станет доступно по 2TB со всех сразу.
>Или, будет ли у меня возможность
On 06/07/17 04:43 PM, Sergey Matveev wrote:
> *** Tim Sattarov [2017-07-06 23:04]:
>> сейчас я вижу требование о равных размерах томов и пересборке vdev.
> Не равных, а не меньших. И статья о том чтобы увеличить размер VDEV-а,
> сделать expand. Если в VDEV-е два терабайтных диска, то один можно
>
*** Tim Sattarov [2017-07-06 23:04]:
>это может быть я выдаю желаемое за действительное, но моё понимание
>было, что ZFS работает с JBOD на бэкенде и собирает массивы дисков, так
>же как LVM.
Что-то типа того.
>сейчас я вижу требование о равных размерах томов и пересборке vdev.
Не равных, а не
On 06/07/17 03:18 PM, Sergey Matveev wrote:
> *** Tim Sattarov [2017-07-06 21:21]:
>>> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
>>> опасности, вставьте диск чтобы на него произошёл resilvering и не было
>>> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то в
*** Tim Sattarov [2017-07-06 21:21]:
>> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
>> опасности, вставьте диск чтобы на него произошёл resilvering и не было
>> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает,
>> то в системе, с точки зрения user-spa
On 24/06/17 05:28 AM, Sergey Matveev wrote:
>
> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
> опасности, вставьте диск чтобы на него произошёл resilvering и не было
> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает,
> то в системе, с точки зрения user
On 2017-06-23, Oleksandr Gavenko wrote:
> Флешки тоже дохнут. Стандартные заявления - 10 лет заряд стекает с
> транзистора.
Полезное видео про SSD носители, MLC, TLC и over provisioning:
https://www.youtube.com/watch?v=-XZNr7mS0iw
Вывод - нужно держать минимум 10% места свободным на носителе.
On 2017-06-29, Fedor Zuev wrote:
> badblocks -n ?
Интересно, но не развернутой FS:
-n
Use non-destructive read-write mode. By default only a non-destructive
read-only test is done. This option must not be combined with the -w option,
as they are mutually exclusive.
В случае отклю
On Mon, 26 Jun 2017, Oleksandr Gavenko wrote:
OG>Или поступать как с лентами - попеременно между лентами гонять данные, что бы
OG>освежать намагниченность?
badblocks -n ?
А может есть смысл воспользоваться чем-то тапа par2?
Да это в среднем на 10% увеличит размер архива, но будет возможность не только
удостовериться,
что данные в архиве повреждены (проверив crc/md5), но и восстановить утраченное
в архиве?
On Fri, Jun 23, 2017 at 11:11:14PM +0300, Oleksandr Gave
Sergey B Kirpichev писал(а) в своём письме Mon, 26 Jun
2017 19:33:58 +0300:
On Mon, Jun 26, 2017 at 06:07:21PM +0300, Victor Wagner wrote:
On Mon, 26 Jun 2017 17:50:01 +0300
Sergey B Kirpichev wrote:
> > Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти
> > буковки и чита
On Mon, Jun 26, 2017 at 06:07:21PM +0300, Victor Wagner wrote:
> On Mon, 26 Jun 2017 17:50:01 +0300
> Sergey B Kirpichev wrote:
>
> > > Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти
> > > буковки и читает. А человеку выдает только "все в порядке" или
> > > "кошечка сдохла".
Sergey Matveev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017 17:23:36
+0300:
>>Хотя идея, что для хранения данных _на диске_
>>нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что
>>для хранения кошечек это, пожалуй, overkill.
> На гиге ZFS работать будет. Чисто д
On Mon, 26 Jun 2017 17:50:01 +0300
Sergey B Kirpichev wrote:
> > Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти
> > буковки и читает. А человеку выдает только "все в порядке" или
> > "кошечка сдохла".
>
> Замечательно. Т.е. в итоге, после "чтений" md5sum - вы таки призна
On Mon, Jun 26, 2017 at 05:28:11PM +0300, Artem Chuprina wrote:
> Что у меня странное? Попробовать ZFS на логическом томе, наверное,
> можно, но судя по тому, что говорят в соседних тредах, выглядеть это
> будет неадекватно.
Ну, если с целью использования фич вроде чексумминга данных,
то почему-б
On Mon, Jun 26, 2017 at 05:19:58PM +0300, Artem Chuprina wrote:
> Sergey B Kirpichev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017
> 16:01:52 +0300:
>
> >> > Я повторю в чем разница, если вы не поняли до сих пор. В современной
> >> > файловой системе - достаточно просто прочитать фа
*** Artem Chuprina [2017-06-26 17:21]:
>Хотя идея, что для хранения данных _на диске_
>нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что
>для хранения кошечек это, пожалуй, overkill.
На гиге ZFS работать будет. Чисто для хранения/чтения подойдёт. У нас
тут упоминалось по пят
Sergey B Kirpichev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017
16:06:27 +0300:
>> Но вообще - чтобы оставить себе пространство для маневра, например. Весь
>> диск под LVM - это уже ограничение выбора. Захочется, например,
>> поэкспериментировать с ZFS или воткнуть второй винт и сдел
Sergey B Kirpichev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017
16:01:52 +0300:
>> > Я повторю в чем разница, если вы не поняли до сих пор. В современной
>> > файловой системе - достаточно просто прочитать файл, чтобы узнать о
>> > проблемах в нем. Чем вы это делаете - без разни
Sergey B Kirpichev писал(а) в своём письме Mon, 26 Jun
2017 16:26:32 +0300:
On Mon, Jun 26, 2017 at 03:17:06PM +0300, Михаил Касаджиков wrote:
Но не нужно высокомерных заявлений о «трёхколёсных велосипедах».
Это констатация факта, а не заявление.
Заметно.
Ну а чтобы оценить "трехколесно
On Mon, Jun 26, 2017 at 03:17:06PM +0300, Михаил Касаджиков wrote:
> Но не нужно высокомерных заявлений о «трёхколёсных велосипедах».
Это констатация факта, а не заявление.
Ну а чтобы оценить "трехколесность" - можно взглянуть на
ваше решение по автоматизации проверки md5?
On Mon, Jun 26, 2017 at 04:01:52PM +0300, Sergey B Kirpichev wrote:
> Я вас удивлю, но большинство людей совершенно не интересует то,
> что там начитал md5sum. Картинка любимой кошечки нужна, понимаете,
а не непонятные буковки, которые там md5sum насчитает.
Ну вы, типа, отстали от жизни, раз не
On Mon, Jun 26, 2017 at 03:41:36PM +0300, Artem Chuprina wrote:
> Но вообще - чтобы оставить себе пространство для маневра, например. Весь
> диск под LVM - это уже ограничение выбора. Захочется, например,
> поэкспериментировать с ZFS или воткнуть второй винт и сделать RAID1 - ан
> в лучшем случае п
On Mon, Jun 26, 2017 at 03:32:34PM +0300, Artem Chuprina wrote:
> > Я повторю в чем разница, если вы не поняли до сих пор. В современной
> > файловой системе - достаточно просто прочитать файл, чтобы узнать о
> > проблемах в нем. Чем вы это делаете - без разницы, хоть cat,
> > хоть LibreOffic
Sergey B Kirpichev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017
12:57:13 +0300:
>> Это понятно. Важно, что его не требуется выделять заранее, на этапе
>> разбиения на диска разделы, как в случае с LVM.
> А зачем с LVM вы вообще заморачиваетесь на тему "разделов"? В 99%
> случаев (
Sergey B Kirpichev -> Михаил Касаджиков @ Mon, 26 Jun 2017 14:58:42 +0300:
>> >>Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
>> >>сильно большая разница между чтением с проверкой целостности средствами
>> >>самой ФС и «md5sum -c».
>> >
>> >Действительно, какая разниц
Sergey B Kirpichev писал(а) в своём письме Mon, 26 Jun
2017 14:58:42 +0300:
On Mon, Jun 26, 2017 at 01:33:46PM +0300, Михаил Касаджиков wrote:
Sergey B Kirpichev писал(а) в своём письме Mon, 26 Jun
2017 13:13:47 +0300:
>On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:
>>Чт
Sergey Matveev писал(а) в своём письме Mon, 26 Jun
2017 14:43:23 +0300:
*** Oleksandr Gavenko [2017-06-26 14:11]:
Или поступать как с лентами - попеременно между лентами гонять данные, что бы
освежать намагниченность?
Мне кажется что этот вариант хорош. Чисто чтобы поддерживать намагниченн
On Mon, Jun 26, 2017 at 01:33:46PM +0300, Михаил Касаджиков wrote:
> Sergey B Kirpichev писал(а) в своём письме Mon, 26 Jun
> 2017 13:13:47 +0300:
> >On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:
> >>Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
> >>си
*** Oleksandr Gavenko [2017-06-26 14:11]:
>Или поступать как с лентами - попеременно между лентами гонять данные, что бы
>освежать намагниченность?
Мне кажется что этот вариант хорош. Чисто чтобы поддерживать намагниченность.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923
On 2017-06-26, Михаил Касаджиков wrote:
> Это уже другая тема. И remap происходит при записи. При невозможности чтения
> мы просто получим ошибку чтения, какая-то там ATA_ERROR.
Вроде ж коды на диске с избыточностью. При такой плотности записи - ошибки
допустимы, будут обранужены и на лету исправ
Sergey B Kirpichev писал(а) в своём письме Mon, 26 Jun
2017 13:13:47 +0300:
On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:
Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
сильно большая разница между чтением с проверкой целостности средствами
самой ФС
Oleksandr Gavenko писал(а) в своём письме Sun, 25 Jun 2017
23:22:16 +0300:
On 2017-06-25, Михаил Касаджиков wrote:
Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не сильно
большая разница между чтением с проверкой целостности средствами самой ФС и
«md5sum -c».
Повторюсь
On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:
> Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
> сильно большая разница между чтением с проверкой целостности средствами
> самой ФС и «md5sum -c».
Действительно, какая разница - возвращает тебе система ошиб
On Sun, Jun 25, 2017 at 04:03:54PM +0300, Artem Chuprina wrote:
> Это понятно. Важно, что его не требуется выделять заранее, на этапе
> разбиения на диска разделы, как в случае с LVM.
А зачем с LVM вы вообще заморачиваетесь на тему "разделов"? В 99%
случаев (разве что если диск загрузочный и grub
В письме от воскресенье, 25 июня 2017 г. 16:57:47 +07 пользователь Sergey
Matveev
написал:
> *** alexander barakin [2017-06-25 16:50]:
> >а оно простым смертным разве продаётся? гуглояндекс ничего мне не
> >рассказал по этому поводу.
>
> Я покупал две такие железки в компании ETegro Technologie
Oleksandr Gavenko -> debian-russian@lists.debian.org @ Sun, 25 Jun 2017
23:22:16 +0300:
>> Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не сильно
>> большая разница между чтением с проверкой целостности средствами самой ФС и
>> «md5sum -c».
> Повторюсь с вопросом, а то
On 2017-06-25, Михаил Касаджиков wrote:
> Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не сильно
> большая разница между чтением с проверкой целостности средствами самой ФС и
> «md5sum -c».
Повторюсь с вопросом, а то фокус сдвинулся. Только прочитать достаточно?
Вроде в дис
*** alexander barakin [2017-06-25 16:50]:
>а оно простым смертным разве продаётся? гуглояндекс ничего мне не
>рассказал по этому поводу.
Я покупал две такие железки в компании ETegro Technologies много лет
назад, но такой компании уже не нет. Физическим лицами они продавали
без проблем. Я к тому,
On Sat, Jun 24, 2017 at 10:53:13PM +0300, Sergey Matveev wrote:
> *** Oleksandr Gavenko [2017-06-24 22:49]:
> >Что можно себе дома поставить?
>
> Лично у меня две вот таких железки дома:
> http://netberg.ru/products/netberg-demos-p200-m3/
а оно простым смертным разве продаётся? гуглояндекс ничег
Sergey B Kirpichev писал(а) в своём письме Sat, 24 Jun
2017 08:41:12 +0300:
On Fri, Jun 23, 2017 at 12:57:38PM +0300, Михаил Касаджиков wrote:
Sergey B Kirpichev писал(а) в своём письме Fri, 23 Jun
2017 11:20:45 +0300:
> On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > С
*** Artem Chuprina [2017-06-25 16:05]:
>Это понятно. Важно, что его не требуется выделять заранее, на этапе
>разбиения на диска разделы, как в случае с LVM.
Не, не, не, боже упаси эти snapshot сравнивать с LVM-ными :-)! Эти
снапшоты идентичны по сути созданию тэга в Git-е. Вы находитесь на
каком-
Sergey Matveev -> debian-russian@lists.debian.org @ Sat, 24 Jun 2017 22:56:35
+0300:
> *** Artem Chuprina [2017-06-24 22:49]:
>>Я правильно понимаю, что для создания снапшота ей не нужно отдельного
>>незадействованного места на диске, как LVM?
> Просто так создать snapshot, грубо говоря, б
>
> Я правильно понимаю, что для создания снапшота ей не нужно отдельного
> незадействованного места на диске, как LVM?
>
да
А оно умеет показывать, желательно быстро, сколько места занимает
> снапшот? В смысле, сколько места освободится, если я вот этот вот
> снапшот удалю?
>
и да и нет - это с
*** Tim Sattarov [2017-06-25 07:21]:
>Параллельный вопрос - умеет ли оно кэшировать на более быстрые
>устройства (типа основные данные на HDD, а кэш на SSD) ?
>как те же bcache или dm-cache ?
Да, умеет. Называется это L2ARC (layer 2 adaptive replacement cache).
Абсолютно (ну с точки зрения пользо
On 2017-06-24, Sergey Matveev wrote:
> Лично у меня две вот таких железки дома:
> http://netberg.ru/products/netberg-demos-p200-m3/
Посмотрел на современное железо, не понятно что с поддержкой на "серверных
материнках" интерфейсов M.2 NVMe:
https://en.wikipedia.org/wiki/M.2
https://en.wikipedia.
On 06/24/17 05:22, Sergey Matveev wrote:
> *** Tim Sattarov [2017-06-24 01:18]:
>> У меня сейчас одна задача с большим количеством (несколько терабайт)
>> мелких и уже сжатых файлов: это ElasticSearch
>> причём в AWS. где диски можно подобрать разные, но они все "сетевые"
>> (EBS), то есть есть не
*** Artem Chuprina [2017-06-24 22:49]:
>Я правильно понимаю, что для создания снапшота ей не нужно отдельного
>незадействованного места на диске, как LVM?
Просто так создать snapshot, грубо говоря, бесплатно. Но для хранения
накапливающейся дельты (данные которые были перезаписаны) конечно же
нуж
*** Oleksandr Gavenko [2017-06-24 22:49]:
>Какие физические интерфейсы поддерживают - вынять/вставить?
Обычный SATA. Только backplane (в который диск вставляется) должен это
поддерживать. Ну и салазки для диска соответствующие. Как во всех
серверах.
>Что можно себе дома поставить?
Лично у меня
Sergey Matveev -> debian-russian@lists.debian.org @ Sat, 24 Jun 2017 12:22:04
+0300:
> * snapshot-ы. Если нужно быстренько что-то проверить/сделать, и при этом
> откатить назад файлы, то можно сделать snapshot (за секунду
> выполняется) а потом его откатить (снова секунда). Знаю что многи
Oleksandr Gavenko -> debian-russian@lists.debian.org @ Sat, 24 Jun 2017
15:38:16 +0300:
>> Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с
>> целостностью всё ok и прозрачно продолжил работу.
> Какие физические интерфейсы поддерживают - вынять/вставить?
> Что м
On 2017-06-24, Sergey Matveev wrote:
> Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с
> целостностью всё ok и прозрачно продолжил работу.
Какие физические интерфейсы поддерживают - вынять/вставить?
Что можно себе дома поставить?
Я работал по старинке - ATX размера
On 2017-06-24, Sergey Matveev wrote:
> пользователь CVS или Subversion скажет что ему бранчи не нужны, но
> когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.
В современном SVN бранчи удобные если извращенные воркфловы не делать.
И даже "продвинутые", т.к. информация о мержа
*** Sergey Matveev [2017-06-24 12:22]:
>Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
>если есть возможность :-)? Как-минимум:
Кроме того, масса мелочей из серии:
* включить/отключить atime -- zfs set atime=... mypool/fs, включить
отключить sync или перевести в режим
>
> Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
> если есть возможность :-)? Как-минимум:
>
Пробовал бтрфс - дико тормозная штука, там где зфс без проблем справляется,
бтрфс просто убивает сторедж.
З.Ы. Никто не задумывается, сколько времени занимает чекдиск на обычно
*** Артём Н. [2017-06-24 11:39]:
>Я так понимаю, ZFS может быть установлен на связке дисков (у него всякие там
>RAIDZ есть, но дальше я не интересовался)?
>И что будет, если один диск из связки вылетит?
>Данные по остальным дискам будут восстановлены (вообще, что произоидёт, и
>остановится ли си
*** Tim Sattarov [2017-06-24 01:18]:
>У меня сейчас одна задача с большим количеством (несколько терабайт)
>мелких и уже сжатых файлов: это ElasticSearch
>причём в AWS. где диски можно подобрать разные, но они все "сетевые"
>(EBS), то есть есть некоторая задержка в доступе.
>Там же важна скорость
On 24.06.2017 01:17, Tim Sattarov wrote:
On 06/23/17 17:41, Sergey Matveev wrote:
*** Tim Sattarov [2017-06-24 00:21]:
не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
в RAIDz ?
Так просто не скажешь.
Короче нужно смотреть на
задачи, на режимы использования, на настр
On 2017-06-24, Sergey B Kirpichev wrote:
> ext2 не может защитить даже от порчи метаданных, не говоря уж о данных.
Для архивов это ж неважно? Если чек-сума не сошлась, восстанавливаем с
предыдущего носителя, а текущий выкидываем. Ну и делает еще одну копию...
--
http://defun.work/
On Fri, Jun 23, 2017 at 02:26:55PM +0300, Artem Chuprina wrote:
> Если я правильно понимаю, btrfs из-за своей сложности - больший риск
> потери данных, чем банальный ext2 (для архивного носителя, не путать с
> бэкапным, даже возможности ext4 не требуются).
Мда, летайте на "Фарманах", друзья... Фа
On Fri, Jun 23, 2017 at 12:57:38PM +0300, Михаил Касаджиков wrote:
> Sergey B Kirpichev писал(а) в своём письме Fri, 23 Jun
> 2017 11:20:45 +0300:
>
> > On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > > Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
On 06/23/17 17:41, Sergey Matveev wrote:
> *** Tim Sattarov [2017-06-24 00:21]:
>> не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
>> в RAIDz ?
> Так просто не скажешь.
> Короче нужно смотреть на
> задачи, на режимы использования, на настройки. ZFS дорогая: на паршивом
> ж
*** Tim Sattarov [2017-06-24 00:21]:
>не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
>в RAIDz ?
Так просто не скажешь. ZFS очень любит память -- с ней ей очень хорошо.
То бишь, при нормальном её размере всё должно упираться в диск. Про
скорость, опять же, всё сложно. Напр
On 06/23/17 16:22, Sergey Matveev wrote:
>
> Прошу прощения что снова про ZFS,
Продолжай в том же духе, интересно :)
> но в его "мире" есть практика такой
> перезаписи путём инициирования подобия RAID rebuild-а. Добавляете диск,
> говоря что он будет частью зеркала, начинается процесс resilvering
*** Oleksandr Gavenko [2017-06-23 23:12]:
>Современные роботизированые type library просто переодически перезаписывают
>данные на новую бобину. Производитель обеспокоился, пользователи не
>замарачиваються.
>
>Выходит что проще с архивами поступать как с бекапами - переписывать на новый
>носитель с
On 2017-06-23, Sergey Matveev wrote:
> Передёргивать нужно не только на чтение, но, в идеале, ещё и на запись.
Это потому что нету гарантий производителя?
Современные роботизированые type library просто переодически перезаписывают
данные на новую бобину. Производитель обеспокоился, пользователи
On Fri, Jun 23, 2017 at 09:47:22PM +0300, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
> 18:06:00 +0300:
> > Владельцы (в виде числовых uid:gid) и права (mask) сохраняются на копии
> > по "rsync -a --numeric-ids".
>
> ... и ты получаешь нежел
*** Oleksandr Gavenko [2017-06-23 22:11]:
>Мои познания в ZFS ограничены "чексумами".
>
>Во вторых не ясно перечитывает ли в офлайне ZFS чексумы файлов и как она
>сообщит о проблеме?
Контрольные суммы всегда читаются вместе с данными и это будет ошибка
ввода/вывода (типа битый блок) если не сойдё
On 2017-06-23, Tim Sattarov wrote:
> Я, честно говоря, скептичен, но описание файловой системы и то как она
> борется с такими "тихими" проблемам достаточно, чтобы посмотреть в её
> сторону...
Мои познания в ZFS ограничены "чексумами".
Во первых не ясно как ошибка в чексуме вернется через систем
Eugene Berdnikov -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
18:06:00 +0300:
>> тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по
>> возможности бэкапы делаются rsync'ом. Инкрементальный - rsync после cp -al.
>>
>> С другой стороны, если надо сохранить систему
On Fri, Jun 23, 2017 at 05:13:37PM +0300, Artem Chuprina wrote:
> тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по
> возможности бэкапы делаются rsync'ом. Инкрементальный - rsync после cp -al.
>
> С другой стороны, если надо сохранить систему владельцев и прав при
> бэкапе на
On 23/06/17 10:20 AM, Artem Chuprina wrote:
> А, ее уже довели до состояния "нормально есть в дистрибутиве"... Хотя
> пока пугает наличие пакета zfs-dkms, т.е. отсутствие поддержки
> мейнстрим-ядром.
>
Те ребята пользуются Ubuntu, где ZFS "из коробки"
я честно говоря не вижу смысла в установке её
Oleksandr Gavenko -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
14:51:58 +0300:
>> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
>> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
>> считывалось ровно то, что ты хотел бы считать. md5 -c впо
Tim Sattarov -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 09:29:41
-0400:
>> Интересен другой момент. Информацию мы же не гравируем на платиновой
>> пластинке. Деградация носителей - обычный процес.
>>
> Мне надысь ребята из одной софтверной конторы все уши прожужжали, как
> они ве
Михаил Касаджиков -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
16:56:05 +0300:
>> Еще вопрос - архивы этож не tar на магритную ленту? Индивидуальными файлами,
>> правда?
> Как раз tar. Используя LVM очень удобно делать snapshot и спокойно паковать
> каждый раздел в свой архив. В од
Oleksandr Gavenko писал(а) в своём письме Fri, 23 Jun 2017
15:58:46 +0300:
On 2017-06-23, Михаил Касаджиков wrote:
Потому что я говорю о «резервных копиях надолго». А для оперативных копий у
меня давно настроен backup-manager с сохранением архивов на домашний NAS и с
периодической чисткой эт
On 23/06/17 03:41 AM, Oleksandr Gavenko wrote:
> Интересен другой момент. Информацию мы же не гравируем на платиновой
> пластинке. Деградация носителей - обычный процес.
>
Мне надысь ребята из одной софтверной конторы все уши прожужжали, как
они везде используют ZFS, даже на коротко живущих сервер
On 2017-06-23, Artem Chuprina wrote:
> Если я правильно понимаю, btrfs из-за своей сложности - больший риск
> потери данных, чем банальный ext2 (для архивного носителя, не путать с
> бэкапным, даже возможности ext4 не требуются).
Даже журнал не нужен.
Только вот вопрос как чистить каталог при сб
On 2017-06-23, Михаил Касаджиков wrote:
> Потому что я говорю о «резервных копиях надолго». А для оперативных копий у
> меня давно настроен backup-manager с сохранением архивов на домашний NAS и с
> периодической чисткой этого дела.
Т.е. речь про лазерные диски не идет? Если бы была - по мне край
Oleksandr Gavenko писал(а) в своём письме Fri, 23 Jun 2017
14:38:26 +0300:
On 2017-06-23, Михаил Касаджиков wrote:
Даже не в сырости дело. Просто я не вижу смысла использовать такую
навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь
если это архив для долговременн
On Fri, Jun 23, 2017 at 02:51:58PM +0300, Oleksandr Gavenko wrote:
> А то с хардлинками и rsync замарачиваешся, а с md5 нет?
...
> Еще не ясно где считать md5. Я полагаю на оригинале. Стает резонный вопрос
> проверить совпадение хешей с предыдущими бекапами по известным файлам...
Почитайте описан
On 2017-06-23, Artem Chuprina wrote:
> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
Да, я такого не делал, но к этому прихожу.
On 2017-06-23, Михаил Касаджиков wrote:
> Даже не в сырости дело. Просто я не вижу смысла использовать такую
> навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь
> если это архив для долговременного хранения — его не будут многократно
> перезаписывать. Скорее всего этот
Sergey B Kirpichev -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
11:20:45 +0300:
>> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
>> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
>> считывалось ровно то, что ты хотел бы считать. md5 -c вп
Igor Savlook писал(а) в своём письме Fri, 23 Jun 2017 12:59:09
+0300:
On Fri, 2017-06-23 at 12:57 +0300, Михаил Касаджиков wrote:
Sergey B Kirpichev писал(а) в своём письме
Fri, 23 Jun 2017 11:20:45 +0300:
> On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > Собственно, я а
On Fri, 2017-06-23 at 12:57 +0300, Михаил Касаджиков wrote:
> Sergey B Kirpichev писал(а) в своём письме
> Fri, 23 Jun 2017 11:20:45 +0300:
>
> > On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > > Собственно, я абсолютно уверен, что надо проверять криптосуммы.
> > > Ну, если
>
Sergey B Kirpichev писал(а) в своём письме Fri, 23 Jun
2017 11:20:45 +0300:
On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
считывалось ро
On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
> если ты не опас
Oleksandr Gavenko -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
10:41:32 +0300:
> Вопрос 4. Какой практический период перечитывания стоит выбрать?
> Вопрос 5. Выходит что
> cp -al /backup/old /backup/new
> rsync -r /orig/ /backup/new/
> не достаточно. Возможно потребуеться
Тут писали про CD/DVD, флешки, диски.
Понятно что устареванием старых ридеров нужно обеспокоиться переносом данных
на новые типы носителей (перфокарты => бобины, CD => DVD => BlueRay, IDE =>
SATA).
Интересен другой момент. Информацию мы же не гравируем на платиновой
пластинке. Деградация носителе
95 matches
Mail list logo
