Re: ФС на сторадж
On Sat, Feb 27, 2010 at 10:24:21AM +0300, Ed wrote: напомню с чего началось: А вот если будет битый кусок в середине файла - остается только контрольные суммы считать. так вот - xfs в случае сомнений забивает _весь_ файл нулями, а не молча приводит его к виду вроде бы должно быть так. Это проверялось? Судя по цитате | whose data was not. Typically you'll find that the inode is not taking | any space since all it has is a size but no extents allocated (try | examining the file with the xfs_bmap(8) command). xfs не должна забивать нулями весь файл. Вообще, трудно представить, чтобы кто-то запрограммировал столь нелепое поведение... Предлагаю проверить утверждение, скажем, на виртуальной машине. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100227155532.gd16...@protva.ru
Re: ФС на сторадж
Dmitri Samsonov wrote: Maxim Tyurin пишет: А вот если будет битый кусок в середине файла - остается только контрольные суммы считать. Именно это и делает xfs, не? afaik нет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b87856f.6070...@yandex.ru
Re: ФС на сторадж
Ed пишет: Именно это и делает xfs, не? afaik нет. Пришли к выводу, что это не так начиная с ядра 2.6.22. Если я правильно понял английский текст: http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1. XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash. Since XFS does not write data out immediately unless you tell it to with fsync, an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are looking at an inode which was flushed out, but whose data was not. Typically you'll find that the inode is not taking any space since all it has is a size but no extents allocated (try examining the file with the xfs_bmap(8) command). -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b880ecc.5070...@gmail.com
Re: ФС на сторадж
Dmitri Samsonov wrote: Ed пишет: Именно это и делает xfs, не? afaik нет. Пришли к выводу, что это не так начиная с ядра 2.6.22. Если я правильно понял английский текст: http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? напомню с чего началось: А вот если будет битый кусок в середине файла - остается только контрольные суммы считать. так вот - xfs в случае сомнений забивает _весь_ файл нулями, а не молча приводит его к виду вроде бы должно быть так. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b88c8a5.3060...@yandex.ru
Re: ФС на сторадж
Dmitri Samsonov writes: Stanislav Vlasov пишет: Для хранения (надёжного) xfs не подходит категорически. Можно немного больше аргументировать? При разрешении проблем проблемные куски тупо забиваются нулями. То есть чтобы убедиться, что всё в порядке и ничего не утрачено -- нужно чексуммы сравнивать периодически. Если FS не может гарантировать корректность содержимого файла она его зануляет. Такой файл найти как раз без проблем. А вот если будет битый кусок в середине файла - остается только контрольные суммы считать. Так что это еще большой вопрос что для ответственного хранения файлов больше подходит. Отсутствие возможности уменьшения размера FS является дополнительным вкусным пряником на десерт. Мне пока не приходилось ни разу уменьшать FS. А вот то что ее можно увеличить не прерывая работы это плюс ощутимый. -- With Best Regards, Maxim Tyurin JID:mrko...@jabber.pibhe.com
Re: ФС на сторадж
Maxim Tyurin пишет: А вот если будет битый кусок в середине файла - остается только контрольные суммы считать. Именно это и делает xfs, не? -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b866a32.90...@gmail.com
Re: ФС на сторадж
ext4 рулит и бибикает. Правда пришлось ядро из testing поставить, работает на софт-рейде в 3.5Тб уже пол-года, работает и чекается гораздо быстрее ext3. Stanislav Vlasov пишет: Стало заканчиваться место на бекапном сервере - прикупили внешнее хранилище. 7.5Тб Вопрос: что нынче больше подходит для хранения смеси из больших и мелких файлов? Большие файлы - образы снапшотов LVM, мелкие - пофайловое копирование серверов (в смысле, всего содержимого, включая /) -- Maxim -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8737d6.3010...@ukr.net
Re: ФС на сторадж
On Fri, Feb 26, 2010 at 04:54:14AM +0200, Max wrote: ext4 рулит и бибикает. Только вот её драйвер постоянно чинят. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(6): [...] чрезмерно разросшимися нитями обсуждений. Может кто знает, как это победить? кого победить? : -- gns in smoke-room@ signature.asc Description: Digital signature
Re: ФС на сторадж
26 февраля 2010 г. 7:54 пользователь Max cryptosonb...@ukr.net написал: ext4 рулит и бибикает. Правда пришлось ядро из testing поставить, работает на софт-рейде в 3.5Тб уже пол-года, работает и чекается гораздо быстрее ext3. ext4 буду использовать только после следующего stable и то маловероятно. Недостаточно широко используется и полгода на единственной машине - не срок. Пока остановился на нескольких разделах и ext3. Надо будет подумать, надо ли там data=journal, но это уже другой вопрос, который проще решить экспериментально. -- Stanislav
Re: ФС на сторадж
On Fri, Feb 26, 2010 at 04:54:14AM +0200, Max wrote: ext4 рулит и бибикает. btrfs еще больше рулит и бибикает :) -- WBR, Dmitry signature.asc Description: Digital signature
Re: ФС на сторадж
Stanislav Vlasov пишет: Для хранения (надёжного) xfs не подходит категорически. Можно немного больше аргументировать? При разрешении проблем проблемные куски тупо забиваются нулями. То есть чтобы убедиться, что всё в порядке и ничего не утрачено -- нужно чексуммы сравнивать периодически. xfs -- это быстрота за счёт надёжности и нагрузки на CPU. Отсутствие возможности уменьшения размера FS является дополнительным вкусным пряником на десерт. -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b85416c.2080...@gmail.com
Re: ФС на сторадж
On Mon, Feb 22, 2010 at 03:06:13AM +0300, George Shuklin wrote: PPS А ещё рейзер феерически сосёт в условиях сильной фрагментации. Они все сосут (и ntfs, и ext3, и xfs, и raiserfs3), но райзер - особо злобно. Мой антирекорд копирования 500Гб с него принципиально и полностью фрагментированных данных (привет кривой делюге) - около двух дней. Да-да, со скоростью от 10 до 1Мб/с. Подтверждаю. В свое время пришел абсолютно к тем же выводам, потому райзер у меня надолго не задержался. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100223102008.ga...@kaiba.homelan
Re: ФС на сторадж
22 февраля 2010 г. 15:42 пользователь Alexey Pechnikov pechni...@mobigroup.ru написал: А разделить на N разделов и проверять их отдельно религия не позволяет? Мысль интересная, но с учётом того, что на сторадже будут в том числе и файлы образов дисков, причём в ближайшем будущем их количество будет расти - сомневаюсь, что мне хватит разделов в 1Тб, а 4Тб будут проверяться не намного меньше. Если вы туда захотите засовывать 2-х терабайтные образы, эдак места ни на что не хватит :-) Имхо можно выделить 4 Гб на образы, остальное поделить на Нет, максимальный размер образа пока что 200Гб. В ближайшее время будет 400, но, пожалуй, это всё. Остальное образами копироваться не будет. несколько частей для инкрементальных бэкапов. Тогда раздел с образами может чекаться, не мешая никому. Не подумал... Надо будет таки подумать на эту тему, возможно так и сделаю. А записать 7,5 терабайт данных на один раздел... если они будут повреждены, вы готовы сделать харакири? Вот именно поэтому и требуется выбрать фс с наименьшей вероятностью сдыхания. Если так вопрос ставить, то это ext3, как наиболее распространенная и проверенная. Ранее вы приоритетом ставили быстрый чек и проч., вам и нарекомендовали... У меня до вопроса в рассылку было два варианта - ext3 и xfs. P.S. Вот откуда берется слепая вера в надежность техники? То кто-то по данным gps на машине в столб въедет, то админ все бэкапы на один сторадж сложит... У меня НЕТ еще одного стораджа. И не будет в ближайший год. Объективная реальность, данная в ощущениях, ибо на еще один сторадж, расположенный в другом месте денег не дадут, как и на подходящий канал связи до него. При доступных 2-х гиговых дисках не вижу проблем организовать бэкапы в любом месте. Есть такая штука - бюрократия называется... То есть, заказать я могу всё что угодно, но а) могут потребовать урезать осетра, б) получу я это не раньше, чем в следующий квартал, в бюджет которого будет включено. Причём, не факт, что вообще будет включено. А 2Тб диски, вероятно, сдохнут раньше, чем этот сторадж... Да и там, куда имеет смысл их втыкать, канал связи всего 5 мбит и через него всё не протащить. Самое важное, впрочем, и так туда копируется... -- Stanislav
Re: ФС на сторадж
Stanislav Vlasov пишет: У меня до вопроса в рассылку было два варианта - ext3 и xfs. Для хранения (надёжного) xfs не подходит категорически. -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b846386.3040...@gmail.com
Re: ФС на сторадж
24 февраля 2010 г. 4:23 пользователь Dmitri Samsonov samson.samson.sam...@gmail.com написал: У меня до вопроса в рассылку было два варианта - ext3 и xfs. Для хранения (надёжного) xfs не подходит категорически. Можно немного больше аргументировать? -- Stanislav
Re: ФС на сторадж
Hello Stanislav! On Sun, 21 Feb 2010 16:00:01 +0100 Stanislav Vlasov wrote: SV SV Вопрос: что нынче больше подходит для хранения смеси из больших и мелких файлов? SV SV Если я правильно ошибаюсь, для хранения лучше всего подходит ext3. SV SV Потому что для хранения ключевым является надёжность, не? SV SV И время, за которое система будет готова к эксплуатации после SV SV включения питания - тоже. SV SV jfs, по моим наблюдениям... SV SV Забыл уточнить - Debian/stable. Почему-то у меня есть сомнения, что в SV нём можно использовать jfs. Я не встречал дистрибутива linux, в котором нельзя использовать jfs, правда не все видел, естественно :-). В debian, начиная с sarge по меньшей мере, проблем нет точно. Только jfsutil надо установить. Я то сам из OS/2 сюда попал, поэтому и знаю её. Главных преимуществ 2 - более экономное использование дискового пространства и очень быстрое чекание. -- С уважением, Владимир Онищенко E-Mail: vl.an.on(at)tochka(dot)ru
Re: ФС на сторадж
Hello Dmitri! On Sun, 21 Feb 2010 16:10:01 +0100 Dmitri Samsonov wrote: DS Отключить и получить возможность поиметь проблем. DS Не отключить и получить возможность не успеть дождаться загрузки DS сервера до конца рабочего дня. DS DS Тестирование (которое производится при каждом -цатом монтировании) у DS меня на полтерабайта занимает пару минут. Выходит, что проверка 7.5 DS терабайт займёт не более получаса. Крутая у Вас машина! :-))) У меня на Athlon 64 X2 4200+ с современными SATA-дисками тестирование 10 гб на ext3 занимает не менее минуты точно, даже более, но точно не замерял. Когда я увидел, сколько занимает тестирование 300 гб (десятки минут!), то был озадачен... В результате поиска альтернативы сейчас всё, кроме системного раздела 10 гб, держу на jfs. -- С уважением, Владимир Онищенко E-Mail: vl.an.on(at)tochka(dot)ru
Re: ФС на сторадж
Hello! On Monday 22 February 2010 10:38:21 Stanislav Vlasov wrote: 22 февраля 2010 г. 3:51 пользователь Alexey Pechnikov А разделить на N разделов и проверять их отдельно религия не позволяет? Мысль интересная, но с учётом того, что на сторадже будут в том числе и файлы образов дисков, причём в ближайшем будущем их количество будет расти - сомневаюсь, что мне хватит разделов в 1Тб, а 4Тб будут проверяться не намного меньше. Если вы туда захотите засовывать 2-х терабайтные образы, эдак места ни на что не хватит :-) Имхо можно выделить 4 Гб на образы, остальное поделить на несколько частей для инкрементальных бэкапов. Тогда раздел с образами может чекаться, не мешая никому. А записать 7,5 терабайт данных на один раздел... если они будут повреждены, вы готовы сделать харакири? Вот именно поэтому и требуется выбрать фс с наименьшей вероятностью сдыхания. Если так вопрос ставить, то это ext3, как наиболее распространенная и проверенная. Ранее вы приоритетом ставили быстрый чек и проч., вам и нарекомендовали... P.S. Вот откуда берется слепая вера в надежность техники? То кто-то по данным gps на машине в столб въедет, то админ все бэкапы на один сторадж сложит... У меня НЕТ еще одного стораджа. И не будет в ближайший год. Объективная реальность, данная в ощущениях, ибо на еще один сторадж, расположенный в другом месте денег не дадут, как и на подходящий канал связи до него. При доступных 2-х гиговых дисках не вижу проблем организовать бэкапы в любом месте. Единственное, что я еще могу сделать - копировать небольшую часть серверов на удалённый сервер, но это - всё, для остальных мест нет. Пара двухтерабайтников, воткнутая на любой сервер, даст вам еще половину объема стораджа. Что касается цены вопроса - средний офис в год на туалетную бумагу больше тратит :-) Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: ФС на сторадж
On Mon, Feb 22, 2010 at 05:37:52AM +0300, George Shuklin wrote: В Пнд, 22/02/2010 в 04:50 +0300, Иван Лох пишет: On Mon, Feb 22, 2010 at 04:32:33AM +0300, George Shuklin wrote: PS Я предпочту ФС, которая будет быстро работать всегда, пусть и ценою скольки-то там процентов дискового пространства. RTFM RTFM: missing operand man mount /notail -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100222113621.gd31...@nano.ioffe.rssi.ru
Re: ФС на сторадж
Vladimir Onishchenko пишет: Я не встречал дистрибутива linux, в котором нельзя использовать jfs, правда не все видел, естественно :-). В debian, начиная с sarge по меньшей мере, проблем нет точно. Только jfsutil надо установить. Я то сам из OS/2 сюда попал, поэтому и знаю её. Главных преимуществ 2 - более экономное использование дискового пространства и очень быстрое чекание. Очень быстрое чекание -- это когда нет проблем и проходит только нулевая фаза. Когда проблемы и требуется полная проверка, то получается очень долгое чекание. По крайней мере так было под OS/2. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8277d8.3000...@mail.ru
Re: ФС на сторадж
Roman S. Gushcha пишет: Добавлю к этому (правда кому надо и так знает) что mke2fs по умолчанию резервирует 5%(!) для рута. Если не нравится -- можно поменять. Я делаю на хранилищах 0,5-1% (и то ни разу не пригодилось). На хранилищах (где не нужно позволять руту писать с превышением -- логи, например) это -- средство борьбы с фрагментацией. Так что спорный вопрос, пригождалось или нет. -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b828c7f.8090...@gmail.com
Re: ФС на сторадж
20 февраля 2010 г. 22:36 пользователь Dmitri Samsonov samson.samson.sam...@gmail.com написал: И время, за которое система будет готова к эксплуатации после включения питания - тоже. А какие могут быть особенные тормоза у ext3 на 7.5Тб за исключением времени (несколько минут) периодической проверки файловой системы, которую можно отключить? Отключить и получить возможность поиметь проблем. Не отключить и получить возможность не успеть дождаться загрузки сервера до конца рабочего дня. -- Stanislav
Re: ФС на сторадж
20 февраля 2010 г. 23:30 пользователь Vladimir Onishchenko vl.an...@stream.ru написал: SV Вопрос: что нынче больше подходит для хранения смеси из больших и мелких файлов? SV Если я правильно ошибаюсь, для хранения лучше всего подходит ext3. SV Потому что для хранения ключевым является надёжность, не? SV И время, за которое система будет готова к эксплуатации после SV включения питания - тоже. jfs, по моим наблюдениям... Забыл уточнить - Debian/stable. Почему-то у меня есть сомнения, что в нём можно использовать jfs. Буду рад, если это не так. -- Stanislav
Re: ФС на сторадж
Stanislav Vlasov пишет: Отключить и получить возможность поиметь проблем. Не отключить и получить возможность не успеть дождаться загрузки сервера до конца рабочего дня. Тестирование (которое производится при каждом -цатом монтировании) у меня на полтерабайта занимает пару минут. Выходит, что проверка 7.5 терабайт займёт не более получаса. Притом, что можно тестирование проводить не автоматически, а самостоятельно в удобное время. Я в чём-то заблуждаюсь? -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b814ad4.50...@gmail.com
Re: ФС на сторадж
21 февраля 2010 г. 20:01 пользователь Dmitri Samsonov samson.samson.sam...@gmail.com написал: Отключить и получить возможность поиметь проблем. Не отключить и получить возможность не успеть дождаться загрузки сервера до конца рабочего дня. Тестирование (которое производится при каждом -цатом монтировании) у меня на полтерабайта занимает пару минут. Выходит, что проверка 7.5 терабайт займёт не более получаса. Притом, что можно тестирование проводить не автоматически, а самостоятельно в удобное время. Я в чём-то заблуждаюсь? На разделе 1Тб с несколькими миллионами файлов (бекапируемый диск сервера) тестирование занимает больше часа. На 7.5Тб файлов будет несколько поболе, ибо серверов несколько... Я не против ручной проверки фс, но предпочитаю, чтоб целостность данных не зависела от моей или чьей-то еще забывчивости. -- Stanislav
Re: ФС на сторадж
Stanislav Vlasov пишет: Я не против ручной проверки фс, но предпочитаю, чтоб целостность данных не зависела от моей или чьей-то еще забывчивости. Чем плоха проверка по крону в середине дня уже примонтированной ФС? -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b814e1a.5060...@gmail.com
Re: ФС на сторадж
21 февраля 2010 г. 20:15 пользователь Dmitri Samsonov samson.samson.sam...@gmail.com написал: Stanislav Vlasov пишет: Я не против ручной проверки фс, но предпочитаю, чтоб целостность данных не зависела от моей или чьей-то еще забывчивости. Чем плоха проверка по крону в середине дня уже примонтированной ФС? Тем, что не действенна и может быть опасна. -- Stanislav
Re: ФС на сторадж
21 февраля 2010 г. 21:09 пользователь Sergey Korobitsin underta...@arta.kz написал: jfs, по моим наблюдениям... Забыл уточнить - Debian/stable. Почему-то у меня есть сомнения, что в нём можно использовать jfs. Буду рад, если это не так. Если мне не изменяет склероз, то jfs можно было использовать ещё с sarge. Может, вы путаете с ZFS? Таки да, путаю. Надо будет поглядеть на эту фс поближе... -- Stanislav
Re: ФС на сторадж
On Sun, Feb 21, 2010 at 08:17:21PM +0500, Stanislav Vlasov wrote: Я не против ручной проверки фс, но предпочитаю, чтоб целостность данных не зависела от моей или чьей-то еще забывчивости. Чем плоха проверка по крону в середине дня уже примонтированной ФС? Тем, что не действенна и может быть опасна. Есть решение - проверять снапшот и, если он нормален, то взводить флаг нормальности на ФС. Если нет, то отмонтировать и проверять по-настоящему. Вот сам автор ext3 пишет: http://archives.free.net.ph/message/20080122.225248.c6dd5240.en.html -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100221200803.ga15...@pompeii.v.shared.ru
Re: ФС на сторадж
Hello! On Sunday 21 February 2010 18:09:46 Stanislav Vlasov wrote: На разделе 1Тб с несколькими миллионами файлов (бекапируемый диск сервера) тестирование занимает больше часа. На 7.5Тб файлов будет несколько поболе, ибо серверов несколько... Я не против ручной проверки фс, но предпочитаю, чтоб целостность данных не зависела от моей или чьей-то еще забывчивости. А разделить на N разделов и проверять их отдельно религия не позволяет? А записать 7,5 терабайт данных на один раздел... если они будут повреждены, вы готовы сделать харакири? Что касается надежности купленного хранилища - поймите, что производитель вовсе не бросится под поезд, если с вашими данными что-то приключится - это ваша проблема и ваша ответственность. Поставщик лишь обеспечивает некоторую, на его взгляд, низкую вероятность программных и аппаратных сбоев. P.S. Вот откуда берется слепая вера в надежность техники? То кто-то по данным gps на машине в столб въедет, то админ все бэкапы на один сторадж сложит... Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: ФС на сторадж
В Вск, 21/02/2010 в 18:01 +0300, Dmitri Samsonov пишет: Stanislav Vlasov пишет: Отключить и получить возможность поиметь проблем. Не отключить и получить возможность не успеть дождаться загрузки сервера до конца рабочего дня. Тестирование (которое производится при каждом -цатом монтировании) у меня на полтерабайта занимает пару минут. Выходит, что проверка 7.5 терабайт займёт не более получаса. Притом, что можно тестирование проводить не автоматически, а самостоятельно в удобное время. Я в чём-то заблуждаюсь? У меня на файлопомойке (ака домашний компьютер) LVM c ext3 на 5Тб, занятый на 97%. Проверка в случае доброго электрика занимает не более минуты. Ну двух-трёх максимум, я не засекал, сколько из общего времени занимает конкретно 5Тб диск. По ощущениям, ковыряние в var/tmp (мелкого размера) не меньше. Вот если подчиниться злой воле resize2fs, и сделать форсед проверку, то да, операция не быстрая... Порядка 2-3 часов. PS До этого был рейзер. Я глубоко не копал, но в случае внезапного выключения он мурыжил несчастные 700Гб минут 10. PPS А ещё рейзер феерически сосёт в условиях сильной фрагментации. Они все сосут (и ntfs, и ext3, и xfs, и raiserfs3), но райзер - особо злобно. Мой антирекорд копирования 500Гб с него принципиально и полностью фрагментированных данных (привет кривой делюге) - около двух дней. Да-да, со скоростью от 10 до 1Мб/с.
Re: ФС на сторадж
On Mon, Feb 22, 2010 at 03:06:13AM +0300, George Shuklin wrote: PPS А ещё рейзер феерически сосёт в условиях сильной фрагментации. Они все сосут (и ntfs, и ext3, и xfs, и raiserfs3), но райзер - особо злобно. Мой антирекорд копирования 500Гб с него принципиально и полностью фрагментированных данных (привет кривой делюге) - около двух дней. Да-да, со скоростью от 10 до 1Мб/с. Когда рейзер начинает тормозить, то с точки зрения других FS место уже закончилось. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100222005348.gi25...@nano.ioffe.rssi.ru
Re: ФС на сторадж
В Пнд, 22/02/2010 в 03:53 +0300, Иван Лох пишет: PPS А ещё рейзер феерически сосёт в условиях сильной фрагментации. Они все сосут (и ntfs, и ext3, и xfs, и raiserfs3), но райзер - особо злобно. Мой антирекорд копирования 500Гб с него принципиально и полностью фрагментированных данных (привет кривой делюге) - около двух дней. Да-да, со скоростью от 10 до 1Мб/с. Когда рейзер начинает тормозить, то с точки зрения других FS место уже закончилось. Не-а. У deluge (торрент-клиент) был (а может и есть) забавный баг: он злоупотребляет sparsed файлами. Даже когда ему говорят full allocation. В результате, если файл после скачивания не двигается между разделами (т.е. не копируется), он ЖУТКО фрагментированный. Эта фрагментация связана с какими-то личными тараканами deluge'и. Так вот, после месяца-двух-трёх работы делюги мы имеем каталог со скачанным, в котором каждый файл тщательнейшим образом фрагментирован. И после этого и настаёт момент истины. Больше всех тормозили (на чтении) рейзер и ntfs-3g (ну ему можно, всё ж не родной код). Субъективно, рейзер больше. Но очень близко. Существенно лучше (раза в полтора) себя вёл xfs. ext3 по ощущениям ещё чуть лучше, но близко к xfs. PS Я предпочту ФС, которая будет быстро работать всегда, пусть и ценою скольки-то там процентов дискового пространства.
Re: ФС на сторадж
On Mon, Feb 22, 2010 at 04:32:33AM +0300, George Shuklin wrote: PS Я предпочту ФС, которая будет быстро работать всегда, пусть и ценою скольки-то там процентов дискового пространства. RTFM -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100222015047.gj25...@nano.ioffe.rssi.ru
Re: ФС на сторадж
В Пнд, 22/02/2010 в 04:50 +0300, Иван Лох пишет: On Mon, Feb 22, 2010 at 04:32:33AM +0300, George Shuklin wrote: PS Я предпочту ФС, которая будет быстро работать всегда, пусть и ценою скольки-то там процентов дискового пространства. RTFM RTFM: missing operand
Re: ФС на сторадж
22 февраля 2010 г. 3:51 пользователь Alexey Pechnikov pechni...@mobigroup.ru написал: На разделе 1Тб с несколькими миллионами файлов (бекапируемый диск сервера) тестирование занимает больше часа. На 7.5Тб файлов будет несколько поболе, ибо серверов несколько... Я не против ручной проверки фс, но предпочитаю, чтоб целостность данных не зависела от моей или чьей-то еще забывчивости. А разделить на N разделов и проверять их отдельно религия не позволяет? Мысль интересная, но с учётом того, что на сторадже будут в том числе и файлы образов дисков, причём в ближайшем будущем их количество будет расти - сомневаюсь, что мне хватит разделов в 1Тб, а 4Тб будут проверяться не намного меньше. А записать 7,5 терабайт данных на один раздел... если они будут повреждены, вы готовы сделать харакири? Вот именно поэтому и требуется выбрать фс с наименьшей вероятностью сдыхания. P.S. Вот откуда берется слепая вера в надежность техники? То кто-то по данным gps на машине в столб въедет, то админ все бэкапы на один сторадж сложит... У меня НЕТ еще одного стораджа. И не будет в ближайший год. Объективная реальность, данная в ощущениях, ибо на еще один сторадж, расположенный в другом месте денег не дадут, как и на подходящий канал связи до него. Единственное, что я еще могу сделать - копировать небольшую часть серверов на удалённый сервер, но это - всё, для остальных мест нет. -- Stanislav
Re: ФС на сторадж
Stanislav Vlasov пишет: Вопрос: что нынче больше подходит для хранения смеси из больших и мелких файлов? Если я правильно ошибаюсь, для хранения лучше всего подходит ext3. Потому что для хранения ключевым является надёжность, не? -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b801989.6060...@gmail.com
Re: ФС на сторадж
20 февраля 2010 г. 22:19 пользователь Dmitri Samsonov samson.samson.sam...@gmail.com написал: Вопрос: что нынче больше подходит для хранения смеси из больших и мелких файлов? Если я правильно ошибаюсь, для хранения лучше всего подходит ext3. Потому что для хранения ключевым является надёжность, не? И время, за которое система будет готова к эксплуатации после включения питания - тоже. -- Stanislav
Re: ФС на сторадж
Stanislav Vlasov пишет: И время, за которое система будет готова к эксплуатации после включения питания - тоже. А какие могут быть особенные тормоза у ext3 на 7.5Тб за исключением времени (несколько минут) периодической проверки файловой системы, которую можно отключить? -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b801d80.7000...@gmail.com
Re: ФС на сторадж
Hello Stanislav! On Sat, 20 Feb 2010 18:30:02 +0100 Stanislav Vlasov wrote: SV 20 февраля 2010 г. 22:19 пользователь Dmitri Samsonov SV samson.samson.sam...@gmail.com написал: SV SV Вопрос: что нынче больше подходит для хранения смеси из больших и мелких файлов? SV Если я правильно ошибаюсь, для хранения лучше всего подходит ext3. SV Потому что для хранения ключевым является надёжность, не? SV SV И время, за которое система будет готова к эксплуатации после SV включения питания - тоже. jfs, по моим наблюдениям... -- С уважением, Владимир Онищенко E-Mail: vl.an.on(at)tochka(dot)ru
Re: ФС на сторадж
+1 за JFS -- Rgds, Feata`lion
