[sisyphus] RAID5/LVM - как-то подтормаживает.

[sisyphus] RAID5/LVM - как-то подтормаживает.

[Sergey]

Приветствую.

Продолжаю наблюдаюдать за RAID5/LVM (напоминаю - это мой первый опыт
с софтраид).  load average, 0.70, 0.57, 0.43. Система двухядерная,
соответственно, совсем небольшие значения. При этотм дисковые операции
Исполняются как-то медленно. lilo - до 20-и секунд и более, lilo -R 
7-10 секунд. Это нормальное явление, или что-то где-то надо крутить ?

Нагрузка на запись там некоторая есть: collectd уже пишет 1926 rrd-шек.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID5/LVM - как-то подтормаживает.

[Michael Shigorin]

On Fri, Sep 24, 2010 at 02:52:28PM +0400, Sergey wrote:
> Продолжаю наблюдаюдать за RAID5/LVM
[...]
> Нагрузка на запись там некоторая есть: collectd уже пишет 1926 rrd-шек.

RAID5 по записи и так плох, а ещё ты точно почитал сперва
http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID#h4072-3
насчёт выравнивания разделов, если они используются?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] RAID5/LVM - как-то подтормаживает.

[Sergey]

On Saturday 25 September 2010, Michael Shigorin wrote:

> RAID5 по записи и так плох,

На храдварных, если процессор у контроллера хороший и кэш большой, это не
особенно заметно...

> а ещё ты точно почитал сперва
> http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID#h4072-3
> насчёт выравнивания разделов, если они используются?

Хе-хе. Не почитал. Надо посмотреть, куда оно попало...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID5/LVM - как-то подтормаживает.

[Michael Shigorin]

On Sun, Sep 26, 2010 at 01:46:40PM +0400, Sergey wrote:
> > RAID5 по записи и так плох,
> На храдварных, если процессор у контроллера хороший и кэш
> большой, это не особенно заметно...

Они тогда стоят, аки аэробус.  Особенно если кэш с батарейкой...

> > http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID#h4072-3
> Хе-хе. Не почитал. Надо посмотреть, куда оно попало...

Гругря "отбиваем максимальный stripe size в начале дисков
и следим, чтоб начала остальных цилиндров также были ему
кратны, следим по секторам".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] RAID5/LVM - как-то подтормаживает.

[Sergey]

On Monday 27 September 2010, Michael Shigorin wrote:

> > На храдварных, если процессор у контроллера хороший и кэш
> > большой, это не особенно заметно...
> 
> Они тогда стоят, аки аэробус.  Особенно если кэш с батарейкой...
 
К хорошему быстро привыкаешь. Отвыкать сложно. :-)

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID5/LVM - как-то подтормаживает.

[Sergey]

On Monday 27 September 2010, Michael Shigorin wrote:

> > > http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID#h4072-3
> > Хе-хе. Не почитал. Надо посмотреть, куда оно попало...
> 
> Гругря "отбиваем максимальный stripe size в начале дисков
> и следим, чтоб начала остальных цилиндров также были ему
> кратны, следим по секторам".
 
Дошёл до чтения. А как размер страйпа посмотреть ?  mdadm --detail только 
размер чанка показывает...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID5/LVM - как-то подтормаживает.

[Sergey]

On Saturday 25 September 2010, Michael Shigorin wrote:

> RAID5 по записи и так плох, а ещё ты точно почитал сперва
> http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID#h4072-3
> насчёт выравнивания разделов, если они используются?
 
Почитал, переделал. Вроде бы правильно (особенно не думал, взял те же 16M
за максимальный размер):

/dev/sda1           32768      425983      196608   83  Linux
/dev/sda2          425984     4489215     2031616   82  Linux swap / Solaris
/dev/sda3         4489216   976773167   486141976   fd  Linux raid autodetect

Раид на sd[abc]3

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID5/LVM - как-то подтормаживает.

[Michael Shigorin]

On Thu, Nov 25, 2010 at 11:59:25AM +0300, Sergey wrote:
> > RAID5 по записи и так плох, а ещё ты точно почитал сперва
> > http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID#h4072-3
> > насчёт выравнивания разделов, если они используются?
> Почитал, переделал. Вроде бы правильно (особенно не думал, взял
> те же 16M за максимальный размер):
> 
> /dev/sda1           32768      425983      196608   83  Linux
> /dev/sda2          425984     4489215     2031616   82  Linux swap / Solaris
> /dev/sda3         4489216   976773167   486141976   fd  Linux raid autodetect

Порядок.

> Раид на sd[abc]3

BTW пятёрка на трёх дисках -- худший вариант RAID5, я обычно
такое стараюсь использовать как RAID1 плюс отдельный шпиндель
под менее важное, но активное по записи (логи или бэкап).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[Sergey]

On Friday 24 September 2010, Sergey wrote:

> Продолжаю наблюдаюдать за RAID5/LVM (напоминаю - это мой первый опыт
> с софтраид).  load average, 0.70, 0.57, 0.43. Система двухядерная,
> соответственно, совсем небольшие значения. При этотм дисковые операции
> Исполняются как-то медленно. lilo - до 20-и секунд и более, lilo -R 
> 7-10 секунд. Это нормальное явление, или что-то где-то надо крутить ?

Мда... До перехода на RAID10 прошло пол года... Тем не менее, теперь
с RAID10/LVM, ничего не поменялось. Кстати, не очень понятно, как на
это влияет RAID, так как /boot живёт на обычном разделе. Или HDD на
столько занят ? NCQ, вроде как, имеется:

[    2.300675] ata1.00: ATA-8: ST3500418AS, CC38, max UDMA/133
[    2.300808] ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    2.300940] ata2.00: ATA-8: ST3500418AS, CC38, max UDMA/133
[    2.301058] ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    2.301186] ata3.00: ATA-8: ST3500418AS, CC38, max UDMA/133
[    2.301303] ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    2.301607] ata4.00: ATA-8: ST3500418AS, CC38, max UDMA/133
[    2.301733] ata4.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[Sergey]

On Saturday, April 16, 2011, Sergey wrote:

> Тем не менее, теперь с RAID10/LVM, ничего не поменялось.

Для статистики. С 2.6.38-std-def-alt2 работает одно ядро, 
основная нагрузка wite-io, средняя нагрузка 0.4. В этой
же ситуации с 2.6.32-ovz-el-alt15 гузятся уже два ядра,
на одном wite-io те же 0.4 в среднем, на другом - где-то 
0.25. Всего ядер в испытуемой системе 4.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[Sergey]

On Saturday 16 April 2011, Sergey wrote:

> > Продолжаю наблюдаюдать за RAID5/LVM (напоминаю - это мой первый опыт
> > с софтраид).  load average, 0.70, 0.57, 0.43. Система двухядерная,
> 
> Мда... До перехода на RAID10 прошло пол года... Тем не менее, теперь
> с RAID10/LVM, ничего не поменялось.

В общем, по барабану, по большому счёту, RAID5 или RAID10. С количеством
snmp-источников данных для collectd в районе 700 штук (в основном,
коммутаторы от 8 до 48 портов), система находится в состоянии, близком
к ступору (LA > 9 даже если графики не пытаться смотреть посредством
collection 3) и с RAID10, даже при использовании rrdcached. А стоит там
2 x X3440 @ 2.53GHz.

Аппаратный RAID на попробовать пока не получается освободить, зато 
получилось попробовать SSD. Перенос /var/lib/collectd на INTEL SSDSC2CT060A3
проблему решил просто волшебно: load average: 0.20, 0.33, 0.44

Даже попытка открыть один здоровенный набор графиков на 3К штук (так
получилось :-) ) вызвала рост LA до 6 примерно. В общем, неплохой
эффект. Ну и непонятно время жизни SSD в таком режиме.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[Sergey]

On Tuesday 16 December 2014, Sergey wrote:

> В этом году проведён долговременный эксперимент.
>  
> Model Family:     SandForce Driven SSDs
> Device Model:     KINGSTON SV300S37A60G
> 
> Время жизни - около пяти месяцев. Не Intel, конечно, но думалось, что года
> полтора-два продержится. Правда пока непонятно, что с ним случилось, вроде
> бы, должен быть жив. Кое-что из SMART:
> 
>   9 Power_On_Hours_and_Msec 0x0032  095  095  000  Old_age  Always -  4438h+49m+07.620s

Второй такой же носитель прожил значительно дольше и умер штатно, в смысле с
предупреждением заранее:

Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SV300S37A60G

  9 Power_On_Hours_and_Msec 0x0032   086   086   000    Old_age   Always       -       12722h+42m+23.370s
231 SSD_Life_Left           0x0013   001   001   010    Pre-fail  Always   FAILING_NOW 1


Сейчас работает третий носитель. Тут понятно, что должно жить подольше, так
как объём вырос далеко не кратно объёму SSD - больше резерва на размазывание
теперь. Пошёл четвёртый год:

Device Model:     KINGSTON SUV400S37240G

  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       26760
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       173459
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       1876

Интересно, как LBA для Кингстона считается...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[Anton Farygin]

On 12.11.2019 0:58, Sergey wrote:
> On Tuesday 16 December 2014, Sergey wrote:
>
>> В этом году проведён долговременный эксперимент.
>>   
>> Model Family:     SandForce Driven SSDs
>> Device Model:     KINGSTON SV300S37A60G
>>
>> Время жизни - около пяти месяцев. Не Intel, конечно, но думалось, что года
>> полтора-два продержится. Правда пока непонятно, что с ним случилось, вроде
>> бы, должен быть жив. Кое-что из SMART:
>>
>>    9 Power_On_Hours_and_Msec 0x0032  095  095  000  Old_age  Always -  4438h+49m+07.620s
> Второй такой же носитель прожил значительно дольше и умер штатно, в смысле с
> предупреждением заранее:
>
> Model Family:     SandForce Driven SSDs
> Device Model:     KINGSTON SV300S37A60G
>
>    9 Power_On_Hours_and_Msec 0x0032   086   086   000    Old_age   Always       -       12722h+42m+23.370s
> 231 SSD_Life_Left           0x0013   001   001   010    Pre-fail  Always   FAILING_NOW 1
>
>
> Сейчас работает третий носитель. Тут понятно, что должно жить подольше, так
> как объём вырос далеко не кратно объёму SSD - больше резерва на размазывание
> теперь. Пошёл четвёртый год:
>
> Device Model:     KINGSTON SUV400S37240G
>
>    9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       26760
> 241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       173459
> 242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       1876
>
> Интересно, как LBA для Кингстона считается...
>
А какой у тебя объём ?

Intel Optane живёт гораздо дольше всего что есть на рынке.

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[Sergey]

On Tuesday 12 November 2019, Anton Farygin wrote:

> А какой у тебя объём ?

16Gb rrd-шек, коммутаторы по SNMP раз в минуту опрашиваются.
Но ещё rrdcached используется и памяти 18Gb:

KiB Mem:  18453696 total, 18209384 used,   244312 free,   530020 buffers
KiB Swap:  6094836 total,        0 used,  6094836 free, 16556496 cached

> Intel Optane живёт гораздо дольше всего что есть на рынке.

Это понятно, но когда второй Кингстон прожил полтора года,
это показалось нормально. Раз в неделю статистику бакапить 
вроде бы нам достаточно.

-- 
С уважением, Сергей.

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[Michael Shigorin]

On Tue, Nov 12, 2019 at 02:02:46PM +0400, Sergey wrote:
> > А какой у тебя объём ?
> 16Gb rrd-шек, коммутаторы по SNMP раз в минуту опрашиваются.

relatime или noatime есть?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] RAID/LVM - как-то подтормаживает.

[alexei]

----- Исходное сообщение -----
> От: "Sergey" <a_s_y@sama.ru>
> Кому: "ALT Linux Sisyphus discussions" <sisyphus@lists.altlinux.org>
> Отправленные: Вторник, 12 Ноябрь 2019 г 18:02:46
> Тема: Re: [sisyphus]	RAID/LVM - как-то подтормаживает.

> On Tuesday 12 November 2019, Anton Farygin wrote:
> 
>> А какой у тебя объём ?
> 
> 16Gb rrd-шек, коммутаторы по SNMP раз в минуту опрашиваются.
> Но ещё rrdcached используется и памяти 18Gb:
> 
> KiB Mem:  18453696 total, 18209384 used,   244312 free,   530020 buffers
> KiB Swap:  6094836 total,        0 used,  6094836 free, 16556496 cached
> 
>> Intel Optane живёт гораздо дольше всего что есть на рынке.
> 
> Это понятно, но когда второй Кингстон прожил полтора года,
> это показалось нормально. Раз в неделю статистику бакапить
> вроде бы нам достаточно.

Model Family:     Phison Driven OEM SSDs (OEM от DNS, даже наклейки желтее желтого)

  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       9403
 12 Power_Cycle_Count       0x0012   100   100   000    Old_age   Always       -       12
168 SATA_Phy_Error_Count    0x0012   100   100   000    Old_age   Always       -       0
170 Bad_Blk_Ct_Erl/Lat      0x0003   065   065   010    Pre-fail  Always       -       0/373
173 MaxAvgErase_Ct          0x0012   100   100   000    Old_age   Always       -       1705 (Average 1616)
192 Unsafe_Shutdown_Count   0x0012   100   100   000    Old_age   Always       -       8
194 Temperature_Celsius     0x0023   067   067   000    Pre-fail  Always       -       33 (Min/Max 33/33)
218 CRC_Error_Count         0x000b   100   100   050    Pre-fail  Always       -       0
231 SSD_Life_Left           0x0013   100   100   000    Pre-fail  Always       -       46
241 Lifetime_Writes_GiB     0x0012   100   100   000    Old_age   Always       -       109010

Работает под ceph osd, обслуживающий writeback-кэш. По моим прикидкам еще месяцев шесть-семь
точно отпашет.

[sisyphus] стресс-тест ssd (Re: RAID/LVM - как-то =?utf-8?b?INC/0L7QtNGC0L7RgNC80LDQttC40LLQsNC10YI=?=)

[Sergey]

On Tuesday 12 November 2019, Michael Shigorin wrote:

> > 16Gb rrd-шек, коммутаторы по SNMP раз в минуту опрашиваются.
> 
> relatime или noatime есть?

/dev/sde1 on /var/lib/collectd type f2fs (rw,nosuid,nodev,noexec,relatime,lazytime,background_gc=on,discard,nouser_xattr,noacl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)

-- 
С уважением, Сергей.

Re: [sisyphus] стресс-тест ssd (Re: RAID/LVM - как-то =?utf-8?b?INC/0L7QtNGC0L7RgNC80LDQttC40LLQsNC10YI=?=)

[Michael Shigorin]

On Wed, Nov 13, 2019 at 12:27:05PM +0400, Sergey wrote:
> > > 16Gb rrd-шек, коммутаторы по SNMP раз в минуту опрашиваются.
> > relatime или noatime есть?
> /dev/sde1 on /var/lib/collectd type f2fs
> (rw,nosuid,nodev,noexec,relatime,lazytime,background_gc=on,discard,nouser_xattr,noacl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)

Возможно, вместо discard всё-таки лучше fstrim -a по крону
раз в сутки или подобрав частоту под темп*объём unlink().

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] стресс-тест ssd (Re: RAID/LVM - как-то подтормаживает)

[Sergey V Turchin]

On Thursday, 14 November 2019 15:45:33 MSK Michael Shigorin wrote:

[...]
> Возможно, вместо discard всё-таки лучше fstrim -a
Точно лучше, т.к. тогда эта операция производится в отдельное время.

> по крону раз в сутки
systemctl status fstrim.timer

> или подобрав частоту под темп*объём unlink().
Скопировать /lib/systemd/system/fstrim.timer в	/etc/systemd/system/ и 
отредактировать.

-- 
Regards, Sergey.

Re: [sisyphus] стресс-тест ssd (Re: RAID/LVM - как-то подтормаживает)

[Anton Farygin]

On 14.11.2019 15:45, Michael Shigorin wrote:
> On Wed, Nov 13, 2019 at 12:27:05PM +0400, Sergey wrote:
>>>> 16Gb rrd-шек, коммутаторы по SNMP раз в минуту опрашиваются.
>>> relatime или noatime есть?
>> /dev/sde1 on /var/lib/collectd type f2fs
>> (rw,nosuid,nodev,noexec,relatime,lazytime,background_gc=on,discard,nouser_xattr,noacl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)
> Возможно, вместо discard всё-таки лучше fstrim -a по крону
> раз в сутки или подобрав частоту под темп*объём unlink().
>
discard вообще уже не нужен, вместо него fstrim.timer

Re: [sisyphus] стресс-тест ssd (Re: RAID/LVM - как-то =?utf-8?b?INC/0L7QtNGC0L7RgNC80LDQttC40LLQsNC10YI=?=)

[Sergey]

On Thursday 14 November 2019, Anton Farygin wrote:

> discard вообще уже не нужен, вместо него fstrim.timer
 
Я всё ещё не планирую пускать systemd на сервера. :-) А тут и вовсе p8 ещё.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] стресс-тест ssd (Re: RAID/LVM - как-то =?utf-8?b?INC/0L7QtNGC0L7RgNC80LDQttC40LLQsNC10YI=?=)

[Sergey]

On Thursday 14 November 2019, Sergey V Turchin wrote:

> > Возможно, вместо discard всё-таки лучше fstrim -a

> Точно лучше, т.к. тогда эта операция производится в отдельное время.
 
А смысл в отдельном времени, если речь про постоянно работающий collectd?
Вот если бы было нечто с большим объёмом обращений к данным в какое-то 
время суток, тогда было бы понятно. 

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] стресс-тест ssd (Re: RAID/LVM - как-то подтормаживает)

[Anton Farygin]

On 14.11.2019 18:44, Sergey wrote:
> On Thursday 14 November 2019, Anton Farygin wrote:
>
>> discard вообще уже не нужен, вместо него fstrim.timer
>   
> Я всё ещё не планирую пускать systemd на сервера. :-) А тут и вовсе p8 ещё.
>
Тогда fstrim в крон.

[sisyphus] про SSD для RRD (Re: RAID/LVM - как-то =?utf-8?b?INC/0L7QtNGC0L7RgNC80LDQttC40LLQsNC10YI=?=)

[Sergey]

On Tuesday 16 December 2014, Sergey wrote:

> > Даже попытка открыть один здоровенный набор графиков на 3К штук (так
> > получилось :-) ) вызвала рост LA до 6 примерно. В общем, неплохой
> > эффект. Ну и непонятно время жизни SSD в таком режиме.
> 
> В этом году проведён долговременный эксперимент.
>  
> Model Family:     SandForce Driven SSDs
> Device Model:     KINGSTON SV300S37A60G
> 
> Время жизни - около пяти месяцев.

Эта штука (сервер) всё ещё работает. Сегодня поставил 4-ый SSD, теперь
AMD R3SL60G (что под руку попало). Статистика по первым трём, включая
вышеотквоченное устройство, если вдруг кому интересно.

1. KINGSTON SV300S37A60G, умер через 4438 часов (184 дня, упала скорость
   записи, заменён по гарантии на следующий)

2. KINGSTON SV300S37A60G, умер через 12722 часов (530 дней, умер совсем,
   но писал за месяц статус FAILING_NOW у параметра SSD_Life_Left)

3. KINGSTON SUV400S37240G, умер через 29417 часов (1225 дня, отпадает
   при записи, но после сброса по питанию данные считываются, параметра 
   SSD_Life_Left в SMART нет, FAILING_NOW нет ни у одного параметра).

По 3-ему есть статистика:

241 Total_LBAs_Written  0x0032  100  100  000   Old_age   Always   -   190967
242 Total_LBAs_Read     0x0032  100  100  000   Old_age   Always   -   1923

В принципе поток данных на первые два устройства был почти такой же:
объём RRD-файлов за эти годы вырос незначительно, гигабайт с 12 до 15.
У AMD 1 LBA, похоже, равен 1 Гб. Может и у кингстонов так же.

-- 
Regards,
Sergey

Re: [sisyphus] про SSD для RRD (Re: RAID/LVM - как-то подтормаживает)

[Leonid Krivoshein]

03.03.2020 20:45, Sergey пишет:
> On Tuesday 16 December 2014, Sergey wrote:
>
>>> Даже попытка открыть один здоровенный набор графиков на 3К штук (так
>>> получилось :-) ) вызвала рост LA до 6 примерно. В общем, неплохой
>>> эффект. Ну и непонятно время жизни SSD в таком режиме.
>> В этом году проведён долговременный эксперимент.
>>   
>> Model Family:     SandForce Driven SSDs
>> Device Model:     KINGSTON SV300S37A60G
>>
>> Время жизни - около пяти месяцев.
> Эта штука (сервер) всё ещё работает. Сегодня поставил 4-ый SSD, теперь
> AMD R3SL60G (что под руку попало). Статистика по первым трём, включая
> вышеотквоченное устройство, если вдруг кому интересно.
>
> 1. KINGSTON SV300S37A60G, умер через 4438 часов (184 дня, упала скорость
>     записи, заменён по гарантии на следующий)
>
> 2. KINGSTON SV300S37A60G, умер через 12722 часов (530 дней, умер совсем,
>     но писал за месяц статус FAILING_NOW у параметра SSD_Life_Left)
>
> 3. KINGSTON SUV400S37240G, умер через 29417 часов (1225 дня, отпадает
>     при записи, но после сброса по питанию данные считываются, параметра
>     SSD_Life_Left в SMART нет, FAILING_NOW нет ни у одного параметра).
>
> По 3-ему есть статистика:
>
> 241 Total_LBAs_Written  0x0032  100  100  000   Old_age   Always   -   190967
> 242 Total_LBAs_Read     0x0032  100  100  000   Old_age   Always   -   1923
>
> В принципе поток данных на первые два устройства был почти такой же:
> объём RRD-файлов за эти годы вырос незначительно, гигабайт с 12 до 15.
> У AMD 1 LBA, похоже, равен 1 Гб. Может и у кингстонов так же.
>

Вопрос в том, сколько на них свободного (гарантировано 
зарезервированного) места? Служебное пространство не в счёт.


-- 
Best regards,
Leonid Krivoshein.

Re: [sisyphus] про SSD для RRD (Re: RAID/LVM - как-то =?utf-8?b?INC/0L7QtNGC0L7RgNC80LDQttC40LLQsNC10YI=?=)

[Sergey]

On Tuesday 03 March 2020, Leonid Krivoshein wrote:

> Вопрос в том, сколько на них свободного (гарантировано 
> зарезервированного) места? Служебное пространство не в счёт.
 
Объём SSD из модели видно, первые две по 60Гб, вторая 240Гб,
а объём данных 12-15Гб. Как написал. Больше никаких данных
на SSD нет. Вот не знаю, на самом деле, про раздел, как лучше,
60-гиговые были без разделов, сразу e2fs на всё устройство, 
240 - с одним разделом на те же 60Гб. Новую AMD-шную сейчас
тоже без разделов поставил.

-- 
С уважением, Сергей.

Re: [sisyphus] про SSD для RRD (Re: RAID/LVM - как-то =?utf-8?b?INC/0L7QtNGC0L7RgNC80LDQttC40LLQsNC10YI=?=)

[Sergey]

On Wednesday 04 March 2020, Sergey wrote:

> сразу e2fs на всё устройство,

f2fs то есть.

-- 
С уважением, Сергей.