А почему?

seagate ST16000NM004J

16тб каждый

SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0 2 Throughput_Performance 0x0005 100 100 050 Pre-fail Offline - 0 3 Spin_Up_Time 0x0027 100 100 001 Pre-fail Always - 7756 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 27 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 100 100 050 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 072 072 000 Old_age Always - 11207 10 Spin_Retry_Count 0x0033 100 100 030 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 26 23 Helium_Condition_Lower 0x0023 100 100 075 Pre-fail Always - 0 24 Helium_Condition_Upper 0x0023 100 100 075 Pre-fail Always - 0 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 3 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 4 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 2261 194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 29 (Min/Max 18/57) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 9 220 Disk_Shift 0x0002 100 100 000 Old_age Always - 235012097 222 Loaded_Hours 0x0032 086 086 000 Old_age Always - 5818 223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 0 224 Load_Friction 0x0022 100 100 000 Old_age Always - 0 226 Load-in_Time 0x0026 100 100 000 Old_age Always - 533 240 Head_Flying_Hours 0x0001 100 100 001 Pre-fail Offline - 0 SMART Error Log Version: 1 ATA Error Count: 9 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 9 occurred at disk power-on lifetime: 11206 hours (466 days + 22 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 43 a0 8f dc 16 40 Error: ICRC, ABRT at LBA = 0x0016dc8f = 1498255 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 08 70 78 dd 16 40 00 13d+12:36:57.632 READ FPDMA QUEUED 60 08 c8 70 dd 16 40 00 13d+12:36:57.632 READ FPDMA QUEUED 60 08 c0 68 dd 16 40 00 13d+12:36:57.631 READ FPDMA QUEUED 60 08 b8 60 dd 16 40 00 13d+12:36:57.631 READ FPDMA QUEUED 60 08 20 58 dd 16 40 00 13d+12:36:57.631 READ FPDMA QUEUED

Ребятки всем привет! Пожалуйста, просветите меня, теоретический вопрос! У меня рекордсайз 4М, сжатие zle, сколько места займёт файл на диске если его размер 2,5МБ? Спасибо!

Ребятки всем привет! Пожалуйста, просветите меня, теоретический вопрос! У меня рекордсайз 4М, сжатие zle, сколько места займёт файл на диске если его размер 2,5МБ? Спасибо!

2.5 и займёт, примерно. Рекорд сайз - это максимальный размер , если файл меньше - будет меньше, с округлением до размера ashift.

Ставлю на 2,5 или меньше, если пожмётся сколько-нибудь Проверим: zpool create epool mirror sde sdf -o ashift=12 echo 16777216 >> /sys/module/zfs/parameters/zfs_max_recordsize zfs set recordsize=4M epool zfs set compression=zle epool dd if=/dev/urandom bs=1KB count=2500 of=testfile_001 2500+0 records in 2500+0 records out 2500000 bytes (2.5 MB, 2.4 MiB) copied, 0.0482634 s, 51.8 MB/s du -sh * 2.4M testfile_001 А ты чего ждал?)

Zfs знает что файл 2.5 и исправно покажет тебе именно эту цифру и это ну никак не зависит от того какой оверхед будет у этого файла

И более того я думал редуцируется только кратно степени двойки а не до ашифта

А это говорило мне о том что занимать будет все 4

где-то бывают суровые рекомендации что raidz не стоит использовать для дисков больше 1ТБ. имхо это перебор, но 16 точно надо хотя бы raidz2

Ставлю на 2,5 или меньше, если пожмётся сколько-нибудь Проверим: zpool create epool mirror sde sdf -o ashift=12 echo 16777216 >> /sys/module/zfs/parameters/zfs_max_recordsize zfs set recordsize=4M epool zfs set compression=zle epool dd if=/dev/urandom bs=1KB count=2500 of=testfile_001 2500+0 records in 2500+0 records out 2500000 bytes (2.5 MB, 2.4 MiB) copied, 0.0482634 s, 51.8 MB/s du -sh * 2.4M testfile_001 А ты чего ждал?)

Zfs знает что файл 2.5 и исправно покажет тебе именно эту цифру и это ну никак не зависит от того какой оверхед будет у этого файла

а с файлом оазмером 4.1мб что получается ?

Нужно создать пару миллионы этих файлов и глянуть занимаемый объем в zpool list тогда примерно можно будет прикинуть оверхед

А du разве имеет хит какое то понятие о размере сектора? Он же берет данные из меты условно говоря а не реально занимаемый обеим

Если верить манам по stat2 du все таки вернет размер файла а не занимаемой им место

root@s2:~# du --apparent-size -h /var/log/syslog 146K /var/log/syslog root@s2:~# du -h /var/log/syslog 25K /var/log/syslog

А я ман просто по du читал, там --apparent-size описан так: --apparent-size print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like

Так, пункт первый интересный: stripe width in RAIDZ is dynamic, and starts with at least one data block part, or up to disks count minus parity number parts of data block То есть при записи файла размером меньше, чем recordsize у нас не будет 1 диск с файлом и 5 с 0. А будет играться от ashift

Я не шибко спец в сях, но насколько вижу du берет данные из fts и если он про реальный размер не знает то откуда du узнает ?

возвращаясь к . example a 5-wide RAIDZ-1 ... A 11-sector block will use 1 parity + 4 data + 1 parity + 4 data + 1 parity + 3 data , что вполне ожидаемо. Подробнее на https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz RAID-Z also requires that each allocation be a multiple of (p+1) - оттуда же Примеры на https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAIDZ.html плохо понятны. А ситуация, когда "if recordsize is less or equal to sector size" если и может быть вообще, то только на чистом zfs без raidz. Да и то сложно придумать зачем делать рекордсайз маленьким. Его уменьшать в принципе нужно лишь в очень узких случаях - базы данных и редкие оптимизации write amplification. Ещё одно хорошее объяснение про padding block внезапно нашлось на https://www.reddit.com/r/zfs/comments/ujba3i/does_allocation_overhead_still_exist_with/ The larger your record size, the less impact this has. ... Sometimes it even works out to 0%, with RAID-Z2, a 16KB record is 4 sectors + 2 parity, is already a multiple of 3, so no padding is required.

В итоге никто не знает где собака зарыта?

нубский вопрос по кэшу. если присобачить к пулу кэш раздел с ссд то это просто кэш на чтение. а если добавить ссд как LOG к пулу - это кэш на запись получается или я чет путаю. спасибо

в какую сторону копать?

А какой смысл держать люстру под убунтой? Есть проверенные/протестированные серверные пакеты lustre + zfs (хотя и не самый свежий) под RHEL, которые можно просто взять и установить.. Клиентские пакеты есть готовые для некоторых RHEL/SLES/Ubuntu, также клиента люстры можно легко собрать под многие линуксы...

В моём понимании после того как люстра стала независима от ldiskfs её стало возможно принести на любое ядро

у меня не получилось :( но она прекрасно в кубе крутится

возвращаясь к . example a 5-wide RAIDZ-1 ... A 11-sector block will use 1 parity + 4 data + 1 parity + 4 data + 1 parity + 3 data , что вполне ожидаемо. Подробнее на https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz RAID-Z also requires that each allocation be a multiple of (p+1) - оттуда же Примеры на https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAIDZ.html плохо понятны. А ситуация, когда "if recordsize is less or equal to sector size" если и может быть вообще, то только на чистом zfs без raidz. Да и то сложно придумать зачем делать рекордсайз маленьким. Его уменьшать в принципе нужно лишь в очень узких случаях - базы данных и редкие оптимизации write amplification. Ещё одно хорошее объяснение про padding block внезапно нашлось на https://www.reddit.com/r/zfs/comments/ujba3i/does_allocation_overhead_still_exist_with/ The larger your record size, the less impact this has. ... Sometimes it even works out to 0%, with RAID-Z2, a 16KB record is 4 sectors + 2 parity, is already a multiple of 3, so no padding is required.

Как думаете?