Quantcast

как(куда) файловая система пишет инфу об изменениях на диск?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

как(куда) файловая система пишет инфу об изменениях на диск?

Anton Maksimenkov-2
Hi.

Вопрос в тему "как бы подольше не заёрзать/убить флешку-диск".

Вот берём файлик и будем в него регулярно писать (будем считать что
"дополнять", то есть дописывать, добавлять, увеличивать так сказать).
Я так понимаю что файловая система при этом:
(А) куда-то пишет на диск собственно это содержимое,
(Б) плюс ещё куда-то пишет своё изменяющееся состояние. Ну там, какие
блоки на диске используются теперь этим файликом, они теперь не
свободные, или что-то в этом роде. Или там, дату изменения/доступа к
этому файлу.

То что (А) будет писаться в разные места по диску и одни и те же места
ёрзать не будет - это вроде бы очевидно.
Вопрос: как будет писаться (Б), то есть будет ли это перезапись неких
одних и тех же блоков на диске, где ФС условилась хранить данные о
себе, либо как-то тоже распределяться?
Есть ли разница и смысл в том, чтобы сразу заранее выделить файлик
нужного размера, чтобы ФС сразу "записала" инфу о его блоках и не
"перестраивала" её по мере того как?
--
antonvm
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: как(куда) файловая система пишет инфу об изменениях на диск?

Valentin Nechayev

 Fri, Sep 09, 2011 at 10:10:41, anton200 wrote about "как(куда) файловая система пишет инфу об изменениях на диск?":

> Вопрос в тему "как бы подольше не заёрзать/убить флешку-диск".
>
> Вот берём файлик и будем в него регулярно писать (будем считать что
> "дополнять", то есть дописывать, добавлять, увеличивать так сказать).
> Я так понимаю что файловая система при этом:
> (А) куда-то пишет на диск собственно это содержимое,
> (Б) плюс ещё куда-то пишет своё изменяющееся состояние. Ну там, какие
> блоки на диске используются теперь этим файликом, они теперь не
> свободные, или что-то в этом роде. Или там, дату изменения/доступа к
> этому файлу.
>
> То что (А) будет писаться в разные места по диску и одни и те же места
> ёрзать не будет - это вроде бы очевидно.
> Вопрос: как будет писаться (Б), то есть будет ли это перезапись неких
> одних и тех же блоков на диске, где ФС условилась хранить данные о
> себе, либо как-то тоже распределяться?

Если говорить про UFS и аналоги - как минимум один и тот же будет: inode
файла, где будут изменяться его размер, mtime, ctime, а при расширении -
карта блоков (хотя после относительно небольшого размера уже пойдёт
меняться не inode, а косвенные блоки). Также будет обновляться заголовок
полосы, в которой идёт запись файла, и суперблок с суммарной
информацией. Полоса может меняться (стандартный алгоритм распределения
старается писать от одного и того же файла на одну полосу не более 1/2
её объёма, а затем принудительно перебрасывает на следующую), но
суперблок один на всю FS и инода - одна на файл.

> Есть ли разница и смысл в том, чтобы сразу заранее выделить файлик
> нужного размера, чтобы ФС сразу "записала" инфу о его блоках и не
> "перестраивала" её по мере того как?

На UFS - практически нет, потому что самым перезаписываемым блоком
всё равно остаётся (основной) суперблок, при любых изменениях на FS.


-netch-

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: как(куда) файловая система пишет инфу об изменениях на диск?

Gregory Edigarov-2
In reply to this post by Anton Maksimenkov-2

On Fri, 9 Sep 2011 10:10:41 +0600
Anton Maksimenkov <[hidden email]> wrote:

> Hi.
>
> Вопрос в тему "как бы подольше не заёрзать/убить флешку-диск".
>
> Вот берём файлик и будем в него регулярно писать (будем считать что
> "дополнять", то есть дописывать, добавлять, увеличивать так сказать).
> Я так понимаю что файловая система при этом:
> (А) куда-то пишет на диск собственно это содержимое,
> (Б) плюс ещё куда-то пишет своё изменяющееся состояние. Ну там, какие
> блоки на диске используются теперь этим файликом, они теперь не
> свободные, или что-то в этом роде. Или там, дату изменения/доступа к
> этому файлу.
>
> То что (А) будет писаться в разные места по диску и одни и те же места
> ёрзать не будет - это вроде бы очевидно.
> Вопрос: как будет писаться (Б), то есть будет ли это перезапись неких
> одних и тех же блоков на диске, где ФС условилась хранить данные о
> себе, либо как-то тоже распределяться?
> Есть ли разница и смысл в том, чтобы сразу заранее выделить файлик
> нужного размера, чтобы ФС сразу "записала" инфу о его блоках и не
> "перестраивала" её по мере того как?
я бы в такой ситуации подумал про рамдиск. тогда можно сбрасывать
данные неа флешку ну, скажем, 1 раз в 5 минут, и предусмотреть
правильные действия в случае shutdown'a.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: как(куда) файловая система пишет инфу об изменениях на диск?

Anton Maksimenkov-2
9 сентября 2011 г. 13:31 пользователь Gregory Edigarov
<[hidden email]> написал:
> я бы в такой ситуации подумал про рамдиск. тогда можно сбрасывать
> данные неа флешку ну, скажем, 1 раз в 5 минут, и предусмотреть
> правильные действия в случае shutdown'a.

Прога конечно будет буферизовывать данные "готовые к сохранению" и
изредка писать-сбрасывать содержимое большим куском. Рамдиск и обвязка
это имитатор такого "правильного" поведения. Правда если бы прога была
не собственная, то вполне может и такой имитатор был бы выходом.

В принципе, если верно то, что написал Valentin Nechayev, то ёрзания
по одной и той же иноде можно избежать путём создания новых файлов
(ну, после некоторого кол-ва сбросов данных в один файл можно его
закрывать и создавать следующий, новая инода будет).

Однако остаются ёрзания по одному суперблоку.
Я так понимаю, их тоже можно "избежать" если заранее насоздавать кучу
разделов и так же, периодически, переносить активность с раздела на
раздел... Только вот, во-первых, кол-во разделов весьма ограничено, а
во-вторых, работать с таким веником может стать довольно головотяжко.
И... а как же "альтернативные суперблоки", которые newfs делает? Они
что, все вместе, с первым суперблоком одновременно перезаписываются
постоянно (а иначе нафиг они, если инфа в них неактуальная будет)?

Вот взять эти USB'шные флешки, как правило с одним каким-нить FAT'овым
разделом, на котором юзера носят туда-сюда свои файлопомойки и
постоянно чото с ними делают, а то и "работают на них" - там что, тоже
некий единый "суперблок" который постоянно ёрзается при всех-любых
изменениях на флешке?
И они ведь (эти флешки) долго живут при этом, годами. У меня вот аська
на флешке живёт...

А вот опен на SD'шке пожил пару месяцев и начались ошибки.
Два девайса было, оба через пару месяцев стали показывать недоброе.
Правда при этом не делалось ничего "для сохранения флешки", просто
была поставлена ОС, и прога писала немного инфы, раз в неско минут в
базу.
Время от времени что-то читалось.
И вот что интересно, проблемы начались на /usr (отдельный раздел, даже
/usr/src и /usr/obj отдельные), которую так-то никто "не трогал" на
запись, только то что ОС (ФС) сама по себе там делала.
Странно. Оно конечно, флешки это есть гнилые девайсы. Но всё же.
--
antonvm
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: как(куда) файловая система пишет инфу об изменениях на диск?

Andrey N. Oktyabrski-2

On 09.09.11 12:24, Anton Maksimenkov wrote:
> Странно. Оно конечно, флешки это есть гнилые девайсы. Но всё же.
Немножко в сторону от основной темы: вопрос SLC vs MLC уже исследован?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: как(куда) файловая система пишет инфу об изменениях на диск?

Grigoriy Orlov
In reply to this post by Anton Maksimenkov-2
> -----Original Message-----
> From: Anton Maksimenkov [mailto:[hidden email]]
> Sent: Friday, September 09, 2011 8:11 AM
> To: [hidden email]
> Subject: как(куда) файловая система пишет инфу об изменениях на
> диск?
>
> Hi.
>
> Вопрос в тему "как бы подольше не заёрзать/убить флешку-диск".

Если речь идет об OS на флешке, то более всего флешку будет мучать /var.
По возможности его надо держать на рамдиске. Если логи нужны, то
их можно писать на другую машину. /tmp, /var/tmp -> ramdisk.

Теперь немного оффтопика:

 У меня стоит NAS под FreeBSD - грузится с USB flash.
/, /usr, /var - все на USB flash. Сделано это для того чтобы
диски могли останавливаться, когда от них ничего не нужно.
Конфигурация с USB ежедневно синхронизируется на диски.
Живет уже полтора года, хотя я думал что flash умрет через месяц.
Правда при конфигурировании другой флешки посыпались ошибки еще
на этапе форматирования и заливки системы.

 Самое главное - на флешке ZFS. ZFS сильно кеширует данные,
операций чтения с маленькой и тормозной флешки очень мало.
Запись, я думаю, более равномерно размазана по флешке,
чем при использовании FFS. Плюс ко всему на ZFS включена компрессия.
Сейчас коэффициет сжатия 2.36. На 2Гб флешке занято 665М, без
компрессии флешка была бы забита под завязку.
Чтение/запись сжатых данных с тормозной флешки намного быстрее, чем
несжатых данных.

        /gluk
 

> Вот берём файлик и будем в него регулярно писать (будем считать что
> "дополнять", то есть дописывать, добавлять, увеличивать так
> сказать).
> Я так понимаю что файловая система при этом:
> (А) куда-то пишет на диск собственно это содержимое,
> (Б) плюс ещё куда-то пишет своё изменяющееся состояние. Ну там,
> какие
> блоки на диске используются теперь этим файликом, они теперь не
> свободные, или что-то в этом роде. Или там, дату изменения/доступа
> к
> этому файлу.
>
> То что (А) будет писаться в разные места по диску и одни и те же
> места
> ёрзать не будет - это вроде бы очевидно.
> Вопрос: как будет писаться (Б), то есть будет ли это перезапись
> неких
> одних и тех же блоков на диске, где ФС условилась хранить данные о
> себе, либо как-то тоже распределяться?
> Есть ли разница и смысл в том, чтобы сразу заранее выделить файлик
> нужного размера, чтобы ФС сразу "записала" инфу о его блоках и не
> "перестраивала" её по мере того как?
> --
> antonvm
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: как(куда) файловая система пишет инфу об изменениях на диск?

Andrey N. Oktyabrski-2
In reply to this post by Andrey N. Oktyabrski-2

On 09.09.11 12:54, Andrey N. Oktyabrski wrote:
> On 09.09.11 12:24, Anton Maksimenkov wrote:
>> Странно. Оно конечно, флешки это есть гнилые девайсы. Но всё же.
> Немножко в сторону от основной темы: вопрос SLC vs MLC уже исследован?
Кстати, вспомнилось вдруг. Когда Dillon написал swapcache для dfly, он
дал несколько советов, как обращаться с SSD. Один из них - не
использовать всю ёмкость, оставить 5-10% вообще незанятыми ничем. Тогда
SSD битые блоки вычисляет и подменяет незанятыми сам. Не знаю, насколько
это относится к флэшкам, но вполне может быть, что более-менее приличные
ведут себя примерно так же.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: как(куда) файловая система пишет инфу об изменениях на диск?

Dinar Talypov
In reply to this post by Anton Maksimenkov-2

On Fri, 9 Sep 2011 10:10:41 +0600
Anton Maksimenkov <[hidden email]> wrote:

> Hi.
>
> Вопрос в тему "как бы подольше не заёрзать/убить флешку-диск".
>
А зачем вообще писать на флешку?
Флешку надо использовать только для загрузки и сохранения конфигов.

Если узкое место флешка, может совсем отказаться от флешки?


--
Dinar Talypov <[hidden email]>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: как(куда) файловая система пишет инфу об изменениях на диск?

Anton Maksimenkov-2
>> Вопрос в тему "как бы подольше не заёрзать/убить флешку-диск".
> А зачем вообще писать на флешку?
Необходимо чтобы железка хранила инфу в том числе на себе. Она её
так-то отсылает тоже, но нужно чтобы и локально лежало (стока скока
сможет лежать грубо говоря).

> Флешку надо использовать только для загрузки и сохранения конфигов.
> Если узкое место флешка, может совсем отказаться от флешки?
Железка (SoC) ничо другого так-то и не имеет. Зато нету ни вентилей,
ни опасности "уронят/утащут". Ну и стоимость: тот же внешний usb hdd
стоит чуть не в полжелезки.
--
antonvm
Loading...