Баг или фича?

jamakasi	# 5 лет, 3 месяца назад
Темы: 1 Сообщения: 16 Участник с: 20 декабря 2018	52th Для того чтобы контроллер ssd провел НАСТОЯЩУЮ проверку состояний надо принудительно провести полное чтение\запись всего диска от и до Возможно, спорить не буду. Просто я Викой прогоняю тест поверхности HDD, на предмет битых блоков (бэды). Но в SSD нет блоков, как и нет физического доступа к диску (он есть только у контроллера). Если есть возможность, скиньте ссылочку, где расписана данная методология проверки SSD. Я почитаю на досуге, самому интересно. Вика не так давно научилась с ssd работать. По методологии не скину прям статью с исследованиями но много где встречается такой подход, в том числе на личном опыте проверено не раз что это действенный способ. Ну чисто логически заставляя прогнать весь объем памяти это заставляет погонять физику ssd, гоняет кэш, гоняет банки памяти. Соответсвенно если вдруг гдето что то не так то контроллер ssd это ощущает и принимает решение сделать ему remap( хотя на практике не у всех ssd есть резервные банки памяти но часто можно встретить), следом вносит корректировки в смарты. Если же просто тыкаться в самоконтрольки смарта то они сейчас бестолковые и как правило выполняют только поверхностный осмотр путем дерганий инфы с банок по шине, типа есть она или нет, объем и т.д. А практически всегда ,если банку заглючило, то это проявляется только на непосредственном физическом воздействии на нее (чтение\запись). Как то так. Еще кстати многие производители особенно ноунеймы гришат тем что смарт у них выдает всегда только хорошее состояние в целях маркетинга и рекламы.

# 5 лет, 3 месяца назад

Сообщения: 16

Участник с: 20 декабря 2018

52th
Для того чтобы контроллер ssd провел НАСТОЯЩУЮ проверку состояний надо принудительно провести полное чтение\запись всего диска от и до
Возможно, спорить не буду.
Просто я Викой прогоняю тест поверхности HDD, на предмет битых блоков (бэды). Но в SSD нет блоков, как и нет физического доступа к диску (он есть только у контроллера). Если есть возможность, скиньте ссылочку, где расписана данная методология проверки SSD. Я почитаю на досуге, самому интересно.

Вика не так давно научилась с ssd работать. По методологии не скину прям статью с исследованиями но много где встречается такой подход, в том числе на личном опыте проверено не раз что это действенный способ. Ну чисто логически заставляя прогнать весь объем памяти это заставляет погонять физику ssd, гоняет кэш, гоняет банки памяти. Соответсвенно если вдруг гдето что то не так то контроллер ssd это ощущает и принимает решение сделать ему remap( хотя на практике не у всех ssd есть резервные банки памяти но часто можно встретить), следом вносит корректировки в смарты. Если же просто тыкаться в самоконтрольки смарта то они сейчас бестолковые и как правило выполняют только поверхностный осмотр путем дерганий инфы с банок по шине, типа есть она или нет, объем и т.д. А практически всегда ,если банку заглючило, то это проявляется только на непосредственном физическом воздействии на нее (чтение\запись). Как то так. Еще кстати многие производители особенно ноунеймы гришат тем что смарт у них выдает всегда только хорошее состояние в целях маркетинга и рекламы.

red	# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	`-A, --acls preserve ACLs (implies --perms) -X, --xattrs preserve extended attributes` jamakasi И собственно что там особенного опции aAXv и мои использованные avx? jamakasi хватает того все работает. ping тоже нормально работает ? если да, то странно, так как он использует capability который rsync переносит только с ключом -X(–xattrs) хотя я конечно придираюсь и возможно ваша система вышла на новый уровень развития что позволяет ей легко обходить такие условности п.с возможно стоит поменять название темы дабы описание было более полным, предлагаю - "Баг, фича или кривые руки ?"

red

# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011


 -A, --acls                  preserve ACLs (implies --perms)
 -X, --xattrs                preserve extended attributes

jamakasi
И собственно что там особенного опции aAXv и мои использованные avx?

jamakasi
хватает того все работает.

ping тоже нормально работает ? если да, то странно, так как он использует capability который rsync переносит только с ключом -X(–xattrs)
хотя я конечно придираюсь и возможно ваша система вышла на новый уровень развития что позволяет ей легко обходить такие условности

п.с
возможно стоит поменять название темы дабы описание было более полным, предлагаю - "Баг, фича или кривые руки ?"

vasek	# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	red "Баг, фича или кривые руки ?" Нужно проводить анализ на низком уровне. jamakasi Виктория была задействована чтобы убедиться в исправности ssd. Про Викторию уже пора забыть, да и толку от нее на современных дисках уже нет. Все осилить не смог, не хватило сил. Но с таким не сталкивался. И если уж анализировать, то, по моему мнению, нужно использовать другие методы. Кроме того не нужно забывать, что хоть информация и записывается в блоки (512 или 4096, смотря что забито), но эта информация записывается страницами объемом 4K (4096). И я бы анализ делал так - создаем файл - nano ~/test.txt, с одним словом T E S T ( cat ~/test.txt …. T E S T) - определяем, что данный файл имеет inode 657574 и занимает 4,0К (4096 байт), а точнее 8 блоков/секторов по 512 байт, а еще точнее begin_LBA=292503421, end_LBA= 292503428 - читаем эти 8 секторов диска sudo hexdump -C -n 4096 -s 149761751552 /dev/sda `22de7efa00 54 20 45 20 53 20 54 0a 00 00 00 00 00 00 00 00 \|T E S T.........\| 22de7efa10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| * 22de7f0a00` и видим, что в данных 4096 байтах занято всего 8 байт, остальные нули. Дальше копируй этот файл куда угодно, возвращай обратно и проводи анализ по-новой - и, в принципе, должен получить точно такой же вывод - 8 байт и никакого мусора. Это самый точный анализ. А вот если будет мусор, то тогда ОЙ ... UPD - и еще, если этот файл удалить (rm ~/test.txt), а затем посмотреть эти же 4096 байт, то увидишь тот же самый вывод (T E S T), а если посмотреть через какое то время, в течение которого выполнялась запись на диск, то увидишь опять то же самое и плюс к этому возможно мусор (в зависимости как много писал и сколько времени прошло). Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

red
"Баг, фича или кривые руки ?"

Нужно проводить анализ на низком уровне.

jamakasi
Виктория была задействована чтобы убедиться в исправности ssd.

Про Викторию уже пора забыть, да и толку от нее на современных дисках уже нет.
Все осилить не смог, не хватило сил. Но с таким не сталкивался. И если уж анализировать, то, по моему мнению, нужно использовать другие методы. Кроме того не нужно забывать, что хоть информация и записывается в блоки (512 или 4096, смотря что забито), но эта информация записывается страницами объемом 4K (4096).
И я бы анализ делал так
- создаем файл - nano ~/test.txt, с одним словом T E S T ( cat ~/test.txt …. T E S T)
- определяем, что данный файл имеет inode 657574 и занимает 4,0К (4096 байт), а точнее 8 блоков/секторов по 512 байт, а еще точнее begin_LBA=292503421, end_LBA= 292503428
- читаем эти 8 секторов диска
sudo hexdump -C -n 4096 -s 149761751552 /dev/sda

22de7efa00  54 20 45 20 53 20 54 0a  00 00 00 00 00 00 00 00  |T E S T.........|
22de7efa10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
22de7f0a00

и видим, что в данных 4096 байтах занято всего 8 байт, остальные нули.
Дальше копируй этот файл куда угодно, возвращай обратно и проводи анализ по-новой - и, в принципе, должен получить точно такой же вывод - 8 байт и никакого мусора.
Это самый точный анализ. А вот если будет мусор, то тогда ОЙ ...

UPD - и еще, если этот файл удалить (rm ~/test.txt), а затем посмотреть эти же 4096 байт, то увидишь тот же самый вывод (T E S T), а если посмотреть через какое то время, в течение которого выполнялась запись на диск, то увидишь опять то же самое и плюс к этому возможно мусор (в зависимости как много писал и сколько времени прошло).

Ошибки не исчезают с опытом - они просто умнеют

52th	# 5 лет, 3 месяца назад
Темы: 11 Сообщения: 462 Участник с: 01 октября 2012	jamakasi Вика не так давно научилась с ssd работать. Хорошая новость. Надо будет потыкать. Просто на работе на критичных участках метода простая - через "родное" приложение для контроля SSD сморится процент износа. Если более 5% - диск под замену. Потом он ставится либо на некритичные участки, либо на подмену.

52th

# 5 лет, 3 месяца назад

Темы: 11

Сообщения: 462

Участник с: 01 октября 2012

jamakasi

Вика не так давно научилась с ssd работать.

Хорошая новость. Надо будет потыкать.
Просто на работе на критичных участках метода простая - через "родное" приложение для контроля SSD сморится процент износа. Если более 5% - диск под замену. Потом он ставится либо на некритичные участки, либо на подмену.

vasek	# 5 лет, 3 месяца назад
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	Дальнейший эксперимент - удаляем файл - rm ~/test.txt - копируем в эту директорию файл размером 1 G, плюс к этому создаем 2 небольших файла, ~/test1.txt (T E S T 1) и ~/test2.txt (T E S T 2) - снова смотрим sudo hexdump -C -n 4096 -s 149761751552 /dev/sda `22de7efa00 54 20 45 20 53 20 54 0a 00 00 00 00 00 00 00 00 \|T E S T.........\| 22de7efa10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| * 22de7f0a00` и как видим, хоть файл и удалили и позаписали новой инфы, но инфа удаленного файла все еще жива. Это удаленный файл, а вот если его не удалить, а просто перенести на другой диск, а потом вернуть обратно, то содержимое тем более не изменится. Может на SSD не много другая технология работы с блоками? ... но, думаю, вряд ли это должно сказаться на содержимое файла. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 3 месяца назад

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

Дальнейший эксперимент
- удаляем файл - rm ~/test.txt
- копируем в эту директорию файл размером 1 G, плюс к этому создаем 2 небольших файла, ~/test1.txt (T E S T 1) и ~/test2.txt (T E S T 2)
- снова смотрим
sudo hexdump -C -n 4096 -s 149761751552 /dev/sda

22de7efa00  54 20 45 20 53 20 54 0a  00 00 00 00 00 00 00 00  |T E S T.........|
22de7efa10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
22de7f0a00

и как видим, хоть файл и удалили и позаписали новой инфы, но инфа удаленного файла все еще жива.
Это удаленный файл, а вот если его не удалить, а просто перенести на другой диск, а потом вернуть обратно, то содержимое тем более не изменится.
Может на SSD не много другая технология работы с блоками? ... но, думаю, вряд ли это должно сказаться на содержимое файла.

Ошибки не исчезают с опытом - они просто умнеют

jamakasi	# 5 лет, 3 месяца назад
Темы: 1 Сообщения: 16 Участник с: 20 декабря 2018	red `-A, --acls preserve ACLs (implies --perms) -X, --xattrs preserve extended attributes` jamakasi И собственно что там особенного опции aAXv и мои использованные avx? jamakasi хватает того все работает. ping тоже нормально работает ? если да, то странно, так как он использует capability который rsync переносит только с ключом -X(–xattrs) хотя я конечно придираюсь и возможно ваша система вышла на новый уровень развития что позволяет ей легко обходить такие условности п.с возможно стоит поменять название темы дабы описание было более полным, предлагаю - "Баг, фича или кривые руки ?" Еще раз повторяю, эти ключи абсолютно никак не связаны с тем что сами файлы в конечном счете оказались битыми.

jamakasi

# 5 лет, 3 месяца назад

Темы: 1

Сообщения: 16

Участник с: 20 декабря 2018

red
 -A, --acls                  preserve ACLs (implies --perms)
 -X, --xattrs                preserve extended attributes
jamakasi
И собственно что там особенного опции aAXv и мои использованные avx?
jamakasi
хватает того все работает.
ping тоже нормально работает ? если да, то странно, так как он использует capability который rsync переносит только с ключом -X(–xattrs)
хотя я конечно придираюсь и возможно ваша система вышла на новый уровень развития что позволяет ей легко обходить такие условности

п.с
возможно стоит поменять название темы дабы описание было более полным, предлагаю - "Баг, фича или кривые руки ?"

Еще раз повторяю, эти ключи абсолютно никак не связаны с тем что сами файлы в конечном счете оказались битыми.

jamakasi	# 5 лет, 3 месяца назад
Темы: 1 Сообщения: 16 Участник с: 20 декабря 2018	vasek ооо, это уже больше подходит под лабораторное повторение. [n04-aleksandrov jamakasi]# echo "TEST" >> test.file [n04-aleksandrov jamakasi]# cat test.file TEST [n04-aleksandrov jamakasi]# hdparm --fibmap /home/jamakasi/test.file /home/jamakasi/test.file: filesystem blocksize 4096, begins at LBA 192714752; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 0 289820264 289820271 8 [n04-aleksandrov jamakasi]# cp test.file /mnt/tempmnt/ [n04-aleksandrov jamakasi]# sha256sum test.file 13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b test.file [n04-aleksandrov jamakasi]# sha256sum /mnt/tempmnt/test.file 13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b /mnt/tempmnt/test.file [n04-aleksandrov jamakasi]# rsync -avx test.file /mnt/tempmnt/test.file1 sending incremental file list test.file sent 100 bytes received 35 bytes 270.00 bytes/sec total size is 5 speedup is 0.04 [n04-aleksandrov jamakasi]# sha256sum test.file 13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b test.file [n04-aleksandrov jamakasi]# sha256sum /mnt/tempmnt/test.file1 13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b /mnt/tempmnt/test.file1 [n04-aleksandrov jamakasi]# hdparm --fibmap /mnt/tempmnt/test.file /mnt/tempmnt/test.file: filesystem blocksize 1024, begins at LBA 2048; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 0 18950 18951 2 [n04-aleksandrov jamakasi]# hdparm --fibmap /mnt/tempmnt/test.file1 /mnt/tempmnt/test.file1: filesystem blocksize 1024, begins at LBA 2048; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 0 18952 18953 2 [n04-aleksandrov jamakasi]# expr 18950 \* 512 9702400 [n04-aleksandrov jamakasi]# expr 18952 \* 512 9703424 [n04-aleksandrov jamakasi]# hexdump -C -n 1024 -s 9702400 /dev/sdb 00940c00 54 45 53 54 0a 00 00 00 00 00 00 00 00 00 00 00 \|TEST............\| 00940c10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| * 00941000 [n04-aleksandrov jamakasi]# hexdump -C -n 1024 -s 9703424 /dev/sdb 00941000 54 45 53 54 0a 00 00 00 00 00 00 00 00 00 00 00 \|TEST............\| 00941010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| * 00941400 Погоняю сегодня более основательно такое действо. Тут накосячил и размеры не 4096 а 1024 на пациенте =(

jamakasi

# 5 лет, 3 месяца назад

Темы: 1

Сообщения: 16

Участник с: 20 декабря 2018

vasek ооо, это уже больше подходит под лабораторное повторение.

[n04-aleksandrov jamakasi]# echo "TEST" >> test.file
[n04-aleksandrov jamakasi]# cat test.file
TEST
[n04-aleksandrov jamakasi]# hdparm --fibmap /home/jamakasi/test.file

/home/jamakasi/test.file:
 filesystem blocksize 4096, begins at LBA 192714752; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0  289820264  289820271          8
[n04-aleksandrov jamakasi]# cp test.file /mnt/tempmnt/
[n04-aleksandrov jamakasi]# sha256sum test.file
13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b  test.file
[n04-aleksandrov jamakasi]# sha256sum /mnt/tempmnt/test.file
13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b  /mnt/tempmnt/test.file
[n04-aleksandrov jamakasi]# rsync -avx test.file /mnt/tempmnt/test.file1
sending incremental file list
test.file

sent 100 bytes  received 35 bytes  270.00 bytes/sec
total size is 5  speedup is 0.04
[n04-aleksandrov jamakasi]# sha256sum test.file
13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b  test.file
[n04-aleksandrov jamakasi]# sha256sum /mnt/tempmnt/test.file1
13b896d551a100401b0d3982e0729efc2e8d7aeb09a36c0a51e48ec2bd15ea8b  /mnt/tempmnt/test.file1
[n04-aleksandrov jamakasi]# hdparm --fibmap /mnt/tempmnt/test.file

/mnt/tempmnt/test.file:
 filesystem blocksize 1024, begins at LBA 2048; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0      18950      18951          2
[n04-aleksandrov jamakasi]# hdparm --fibmap /mnt/tempmnt/test.file1

/mnt/tempmnt/test.file1:
 filesystem blocksize 1024, begins at LBA 2048; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0      18952      18953          2
[n04-aleksandrov jamakasi]# expr 18950 \* 512
9702400
[n04-aleksandrov jamakasi]# expr 18952 \* 512
9703424
[n04-aleksandrov jamakasi]# hexdump -C -n 1024 -s 9702400 /dev/sdb
00940c00  54 45 53 54 0a 00 00 00  00 00 00 00 00 00 00 00  |TEST............|
00940c10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00941000
[n04-aleksandrov jamakasi]# hexdump -C -n 1024 -s 9703424 /dev/sdb
00941000  54 45 53 54 0a 00 00 00  00 00 00 00 00 00 00 00  |TEST............|
00941010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00941400

Погоняю сегодня более основательно такое действо. Тут накосячил и размеры не 4096 а 1024 на пациенте =(

vasek	# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	Конечно, я взял слишком развернуто (привязался к блокам, страницам), а вообще можно и проще, просто смотреть изменились ли байтики в файле - hexdump -C ~/test.txt, так как sha256sum и смотрит только эти конкретные байты, которые фактически занимают данные файла. Но если уж искать причину, то, думаю, нужно брать шире. Хотя никогда раньше не интересовался, что конкретно смотрит sha256sum - только фактические байты файла (например, в моем случае 8 байт) или все блоки, занятые файлом (в данном случае 4096 байт). По идее должен смотреть только эти 8 байт, но лучше посмотреть на это шире, если уж взялся за анализ. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

Конечно, я взял слишком развернуто (привязался к блокам, страницам), а вообще можно и проще, просто смотреть изменились ли байтики в файле - hexdump -C ~/test.txt, так как sha256sum и смотрит только эти конкретные байты, которые фактически занимают данные файла. Но если уж искать причину, то, думаю, нужно брать шире.
Хотя никогда раньше не интересовался, что конкретно смотрит sha256sum - только фактические байты файла (например, в моем случае 8 байт) или все блоки, занятые файлом (в данном случае 4096 байт). По идее должен смотреть только эти 8 байт, но лучше посмотреть на это шире, если уж взялся за анализ.

Ошибки не исчезают с опытом - они просто умнеют

red	# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	jamakasi Еще раз повторяю, эти ключи абсолютно никак не связаны с тем что сами файлы в конечном счете оказались битыми. про это речь и не шла в моих постах, я же спецом процентировал ваши конкретные фразы дабы акцентировать внимание и на данном аспекте(отсутствие расширенных атрибутов и прав) что также может сказаться на работоспособности скопированной системы

red

# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

jamakasi
Еще раз повторяю, эти ключи абсолютно никак не связаны с тем что сами файлы в конечном счете оказались битыми.

про это речь и не шла в моих постах, я же спецом процентировал ваши конкретные фразы дабы акцентировать внимание и на данном аспекте(отсутствие расширенных атрибутов и прав) что также может сказаться на работоспособности скопированной системы

vasek	# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	red (отсутствие расширенных атрибутов и прав) что также может сказаться на работоспособности скопированной системы С этим полностью согласен. Полная информация содержится в выводе информации inode конкретного файла - и нужно обязательно проверять. EDIT 1 - имел ввиду, что у двух одинаковых файлов могут быть разные расширенные атрибуты Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 3 месяца назад (отредактировано 5 лет, 3 месяца назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

red
(отсутствие расширенных атрибутов и прав) что также может сказаться на работоспособности скопированной системы

С этим полностью согласен. Полная информация содержится в выводе информации inode конкретного файла - и нужно обязательно проверять.

EDIT 1 - имел ввиду, что у двух одинаковых файлов могут быть разные расширенные атрибуты

Ошибки не исчезают с опытом - они просто умнеют