Как всегда накосячил и подробных логов нет.
Есть зеркальный том Safe, но старенький P4 лопает много электричества.
Возникла мысль - сделать копию и подключить к микро-ПК.
Потом, временами - буду подключать тот винт и рсинкать изменения назад на рейд. Или правильнее сделать как то по другому?

Сначала сделал снэпшот этого тома:
#zfs snap -r Safe@250328-1200

Потом его послал в другой том:
#zfs send -R Safe@250328-1200|zfs recv -Fuv T4T3S

Это всё шуршало 26 часов. Пытаюсь экспортировать пул назначения: Бизи...

$sudo zfs list
-----
NAME USED AVAIL REFER MOUNTPOINT
.....
Safe/:pub 1.42T 363G 1.42T /opt/:pub
....
T4T3S/:pub 1.42T 363G 1.42T /opt/:pub
-----
и таких строчек много, т.е. Вся иерархия Safe скопировалась на T4T3S и у всей иерархии на обоих томах стали одинаковые точки монтирования.

Начал этот топик, отвлекли домашние дела. Вернулся через несколько часов, в соседнем окне решил запротоколировать ошибку экспорта - но увы, пул сэкспортировался без ошибки и теперь могу спокойно отключить диск и подключить к МикроПК - лопающему 15 Ватт, а не 200. Это по результатам топиков где мне говорили что за пару лет работы - МикроПК сэкономит свою цену, если отключить древний комп.

Однако вопрос остался: Что это? Почему send/receive монтируют копию туда же где и источник? Так и должно быть? Или где я накосячил?

P.S. Не пугайтесь таких имён подтомов начинающихся с ":" или испугайте меня чем это грозит. Как уже говорил, с памятью у меня проблемы и тяжело помнить все подтома и различать их с подкаталогами. Тепрь всё что начинается с ":" это подтом, такой я придумал протокол именования подтомов.
Пока вроде в командах прокатывают. Пробовал другие символы для индикации подтомов, но нашел только этот, или были какие то другие косяки.

Есть USB3 SSD, проинициализированная на современном Ноутбуке с современной виндой.

Нужно прочитать содержимое этой SSD.

Включаю, получаю /dev/sdb

# fdisk -l /dev/sdb
Disk /dev/sdb: 953,87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: UnionSine USB3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1DC78EDF-F15D-11EF-BD93-64D69AE5C9C2

Device      Start        End    Sectors   Size Type
/dev/sdb1    2048     264191     262144   128M Microsoft reserved
/dev/sdb2  264192 2000408575 2000144384 953,7G Microsoft Storage Spaces

# mount /dev/sdb1 sdb1
mount: /mnt/sdb1: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

# mount /dev/sdb2 sdb2
mount: /mnt/sdb2: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

# blkid /dev/sdb1
/dev/sdb1: PARTUUID="1dc78ee0-f15d-11ef-bd93-64d69ae5c9c2"
# blkid /dev/sdb2
/dev/sdb2: PARTLABEL="M-PM-^_M-QM-^CM-PM-; M-PM-=M-PM->M-QM-^AM-PM-8M-QM-^BM-PM-5M-PM-;M-PM-5M-PM-9" PARTUUID="1dc78ee2-f15d-11ef-bd93-64d69ae5c9c2"

В общем поломал благодаря USB 3. Переставил местами 2 адаптера, у них были кабели разной длины, и вот один из них не смог нормально отработать с кабелем от другого. Делал банальный рсинк. В нгазначении получил что то типа:

  pool: T4T3S
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: scrub repaired 464K in 06:48:46 with 8 errors on Sun Feb  9 07:12:55 202
5
config:

        NAME         STATE     READ WRITE CKSUM
        T4T3S        DEGRADED     0     0     0
          T4T3STORE  DEGRADED     0     0 41.7K  too many errors

errors: Permanent errors have been detected in the following files:

        T4T3S/:Backup:<0x50700>
        /zfs/=T4T3S/:Backup/Hosts/HGST-750/Backup-241127=330(172)Gb/p8-zz750/zz-s64root/usr/share/doc/gcc-6-base/libstdc++/user/a09413.html

# zpool status T4T3S
  pool: T4T3S
 state: ONLINE
  scan: scrub repaired 16K in 06:01:52 with 0 errors on Tue Feb 25 21:27:33 2025
config:

	NAME         STATE     READ WRITE CKSUM
	T4T3S        ONLINE       0     0     0
	  T4T3STORE  ONLINE       0     0     0

errors: No known data errors

unC0Rr

undef

Играюсь здесь с ЯДом... Решил сделать протокол. Делаю:

# /usr/bin/time "cd /e"
/usr/bin/time: cannot run cd /e: No such file or directory
Command exited with non-zero status 127
0.00user 0.00system 0:00.00elapsed 61%CPU (0avgtext+0avgdata 1240maxresident)k
0inputs+0outputs (0major+37minor)pagefaults 0swaps

Ох уж эти «облака», особенно ЯД... Начал использовать 3 года назад, купился за 2Т на 2 года за 1000р.
Начал использовать, поставил yandex-disk, синкнул и понял что адрибуты и владелцы - не синхронизируются. Это что за облако? Которое не хранит атрибутов/владельцев файлов? Мало того - он тупо не хранят время создания/модификации и заменяют его временем закачки на ресурс. Ну синкнул я 2 гигатонны барахла, написал запрос. ответили: такое поведение у синхронизатора! Естественно исправлять никто не озадачился. Прошло время, это дерьмо никто не исправил, а хоть отстойную - а копию данных стоит иметь. Сейчас дошел до того что сделал 4Т zfs зеркало, на днях приедет ещё 4Т под резервный рсинк. Написал этим цензоредам письмо, что 3 года назад ставил вопрос, до сих пор никто не шевельнулся, и если так то придётся отказаться от их сервиса когда закончится срок. Такое дерьмо ещё раз продлять не собираюсь. 4 дня они думали (потом ответили только на ту часть вопроса где я спрашивал: почему yandex-disk start - стартует дольше суток?), и сослались что «сверяет» и может сверять долго из за слабого компьютера/интернета. Про вопрос сохранности атрибутов просто игнор.


Вот решил узнать у общественности, может для Линукс придумали какую то систему хранящую метаинформацию в каких нибудь сервисных файлах на ресурсе? Помнится у IBM в OS/2 на FAT были EADATA.SF в которых замечательно жило то что в FAT не помещалось.

Или кто как такую проблему ЯДа решал? Есть наверное их пользователи? Или нет? Хотел скажем тупо синкать /usr/local/bin - где храню разные скриптики... Но они твари теряют атрибут исполняемости.

В общем ЯД? Или не ЯД?
Какое ещё можете рекомендовать «облако» не дороже 2.5к/год?
А то эта утеря времени/атрибутов и сутки пиления винта и жарки процессора после каждой перезагрузки - весьма надоели, а хочется резервного хранилища. Мало того что винты таки такие штуки - что был у меня прецедент сдыхания зеркального винта в процессе восстановления рейда. ну и хранение дома - уязвимо в плане пожара/грабителей.

P.S. Как вы помните, «травма несовместимая с жизнью» и вследствие плохая память. С этим топиком озадачился вновь, хотя по дате/времени файлов в хранилище - выходит что я решил эту задачу ещё в 2018. Есть у меня в ЯДе .cryfs и .ecryptfs - Обе хранят и сведения о владельцах и атрибуты файлов и время создания/модификации.
Возможно есть косяки при работе с нескольких хостов сразу - надо провентилировать этот вопрос и определить безопасный протокол использования. Ну и перелить 2Т дерево с открытого в эти контейнеры. Это будет отдельный кейс...

И ДА, заливать надо не с ЯДа, а с оригинальных файлов ещё живых на моей системе (надеюсь).

Отмечаю топик как решенный, жаль никто не «ткнул» в решение, начали балабольство про облака и что они должны делать...

(250208) P.P.S. cryfs и ecryptfs - разочаровали. Решение оказалось нерешенным.
cryfs - Оттормаживается по 40-60 секунд на команде df на шифрованном разделе с залитыми 64Gb. Но и аремя и атрибуты сохраняет и они «пролазят» с хоста на хост через ЯД.
ecryptfs - Работает быстро, но время/дату/rwx, хранит в атрибутах зашифрованных файлов и естественно это не «пролазит» через ЯД.

Вообще заголовок не совсем отражает содержимое.
15 лет назад я «выпал» из жизни, и у меня до сих пор были только BIOS компьютеры, на которых я без проблем грузился с винтов подцепленных по USB.
Сейчас я наконец смог позволить себе UEFI устройства, и с ужасом обнаружил что я банально не могу подключить старый винт по USB и загрузить старый Линукс.
Мало того и загрузиться можно далеко не с каждой флешки. Вставляешь флешку, а UEFI БИОС её не видит, и тут же ставишь какой нибудь Debian Boot USB - он видится и грузится.
Как в нынешних условиях сделать USB с которой можно было бы загрузить рабочую систему?
Где можно прочитать современный алгоритм загрузки компьютера?
Каким образом современный БИОС решает - может ли он грузиться именно с этой флешки, или нет?
Надеюсь уважаемая общественность, отправит в нужном направлении.
Желательно в разрезе Debian, я в основном использую этот дистрибутив.

Поставил Debian 12.
Как всегда в mc, к простой консольке не привычен.
Как всегда - при операциях с FS - вставляю имена с противоположной панельки. Вставил путь, переместился, обычные ESC-Enter и Enter... Команда выругалась на ./ в пути... Приглядываюсь и правда:
ПУТЬ/./ИМЯ вместо ПУТЬ/ИМЯ.

Может уважаемый олл - знает как это побороть?

P.S. Всё весьма странно, видимо особенность, может кто скажет в чём фишка?

Создаю Файл: Name и он вставляется как положено.
Если же он: -Name то вставляется ./-Name

Просто я таким образом начал именовать подтома в ZFS чтобы подтома отличались от подкаталогов. Пробовал символы «=» и «#» - Их ZFS не принимает в именах томов, "-" приняла но начал бастовать mc.

P.P.S. Спасибо всем за обсуждение! По результатам обсуждения - пока избрал другой "протокол".
Монтировать zfs Том буду в /zfs/=Том
А подтома создавать с именами :Подтом
Если вдруг подтом потребуется смонтировать в отдельный каталог то соответственно mountpoint будет в =Имя, Имя будет выбираться по потребности, хотя случаи разные бывают. Надо рассмотреть протокол монтирования во всякие /var/spool или /var/log (Скажем чтобы распухшие каталоги можно было вынести из сиситемного раздела.)
Нужно предусмотреть индикацию того что этот каталог за пределами fs. ну скажем в виде подкаталога \#zfs=ТОМ--ПОДТОМ.
Просто скажем видел уже на ЛОР жалобы на распухшие временные каталоги - забивавшие системный раздел в ноль. Стоит рассмотреть такой вариант подстраховки. Плюсом и одновременно минусом zfs является то что достаточно для ресурса задать точку монтирования, она её запомнит и будет потом монтировать сама.

Приветствую уважаемый LOR.

Новый виток китайской лотереи. Взял китайский ноут с характеристиками 32Gb RAM и 1Tb SSD.

Загрузился с SystemRescueCD, набираю:

#free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       1.0Gi        14Gi       102Mi       736Mi        14Gi
Swap:             0B          0B          0B

     *-memory
          description: System Memory
          physical id: 39
          slot: System board or motherboard
          size: 32GiB
        *-bank:0
             description: SODIMM DDR4 Synchronous 2667 MHz (0.4 ns)
             vendor: 0x0000
             physical id: 0
             serial: 4100014D
             slot: Controller0-ChannelA
             size: 16GiB
             width: 64 bits
             clock: 2667MHz (0.4ns)
        *-bank:1
             physical id: 1
             slot: Controller0-ChannelB-DIMM0
             size: 16GiB

Приветствую уважаемых генералов, пишу из оФФТОПИКА, потому что никак не завезу линукс на дешевый китайский ноутбук с UEFI (На самом деле я слабо предстваляю кто виноват и надеюсь кто то подскажет чо делать?)

В общем есть дешеывый нонейм ноутбук, аж с 64Гб SSD на который накачена лицензионная W10. Естественно просто так лицензию выкидывать не стану, пусть живёт.

Весь такой резвый, подключаю винт с линуксом в USB3 и ОБАНА! Комп его видит, видит накопитель, но по кнопке F7 только Win и Восстановление Win. Варианта загрузить Linux - не нашел.

Ладно, в USB вставляю Debian - netinst, в MicroSD слот ставлю MicroSD 64 Gb, устанавливаю на неё Debian но в F7 так и не появляется возможности выбора загрузки.

Мало того, есть у миеня какие то флешки с линуксом, но!
Debian Netinst - появляется в F7 (с префиксом:UEFI) а флешки с системой не появляются и их невозможно загрузить.

Подозреваю что нужны какие то заклинания в виде загрузочной флешки с grub с которой уже грузить всё обилие имеющегося.
Но как заставить её видеться? F7 (Загрузчик BIOS) к выбору предлагает далеко не каждую флешку.

Надеюсь найдутся ясновидящие - покажущие направление куда копать.

Пока вот живу в винде, а линукс есть гле то там, на MicroSD и я не могу его загрузить...

И что самбое обидное, в отъезде и забыл дома «дорожную мыльницу» с флешками :( - даже экспериментировать на досуге нечем. С собой только ноут и одна флешка в слоте.

Может ручками можно поправить что то на UEFI boot разделе и добавить меню выбора загрузки при перезагрузке?

Но пока это сделать могу лишь из Win10.Windows,

Или может уважаемая общественность пошлёт куда по делу?

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

Может кто то знает - ведёт ли логи ведроид? Есть ли приложение для их анализа? И где можно об этом почитать? Что послужило причиной перезагрузки?

Сейчас очередной прецедент, меня все назовут «нищеброд», но сейчас (Сейчас это: «В данный момент, в другом городе, в другой хате», дома у меня оптика до дома) я сижу на бесплатном интернете от Йота, и вот там какая то сложная технология редиректов для включения бесплатного интернета.

Регулярно выскакивает окно типа: «Подключить пакет или продолжить бесплатно на 64Кбит».

Сейчас пишу с нищебродского нетбука на Атоме, с дохлой матрицей работающем на 15" монитор с MicroSD карты на 32Gb.

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

А вообще как ни странно, у MSEdge лучшая работа с памятью. И Firefox и Chrome и Даже Опера - Постепенно съедают память при нескольких открытых окнах и вкладках, и их приходится регулярно убивать и перезапускать.

MSEdge не требует таких мероприятий. Хотя конечно в нём не хватает мастер пароля как у Мозиллы.

Это сугубо моё мнение, есть масса браузеров, но MSEdge пока отрабатывает всё в лучшем виде.


Перемещено hobbit из talks

Преамбула:

Не судите меня строго, я «дурачок». В 2009 в результате лётного происшествия - тяжелый ушиб ствола мозга и неделя мозговой комы.
Благо окружающие «прорешали» хорошего русского реаниматолога, я выжил и обошлось без оперативного вмешательства. Первый месяц я был практически овощь, но постепенно даже компьютерами продолжил заниматься, но увы, теперь не хватает памяти и концентрации внимания на анализ ситуации.

Теперь о ситуации:

Там где сейчас импортирую том - Мини ПК (BMAX B1 Pro) и стоит Debian Bookworm. Но это началось на основном компе с классическим P4. На Мини ПК винт подключен через USB3, Полный SMART тест прошел, хотя на основном компе - издавал странные звуки и возможно они привели к ситуации упавшего тома.

Использую zfs, как бы её не ругали... Винты дохнут и решил сделать рейд на zfs, но не успел. Во время массированного перемещения данных между 14T собравшегося дискового пространства, что то , где то, повисло (Или сбой электричества был? Увы, в этом и моя проблема. То что не зафиксировано я часто забываю.)

в общем имею 4T накопитель, на котором собирал рабочую реплику инфы, чтобы впоследствии сделать зеркало на второй 4T.
(Этим и нравится zfs, можно не сразу делать рейд как в mdadm, а потом. Впрочем могу и заблуждаться, может и mdadm так может).
Собрать не успел. Сейчас там есть zfs том: Safe - который рождает панику во время #zpool import. Он просто повисает, а в journalctl

июл 08 20:50:53 0F-BMAX kernel: VERIFY3(0 == dmu_buf_hold_array(os, object, offset, size, FALSE, FTAG, &numbufs, &dbp)) failed (0 == 5)
июл 08 20:50:53 0F-BMAX kernel: PANIC at dmu.c:1123:dmu_write()
июл 08 20:50:53 0F-BMAX kernel: Showing stack for process 11716
июл 08 20:50:53 0F-BMAX kernel: CPU: 0 PID: 11716 Comm: txg_sync Tainted: P           OE      6.1.0-22-amd64 #1  Debian 6.1.94-1
июл 08 20:50:53 0F-BMAX kernel: Hardware name: AMI Intel/Intel, BIOS V1.3_231 08/22/2023
июл 08 20:50:53 0F-BMAX kernel: Call Trace:
июл 08 20:50:53 0F-BMAX kernel:  <TASK>
июл 08 20:50:53 0F-BMAX kernel:  dump_stack_lvl+0x44/0x5c
июл 08 20:50:53 0F-BMAX kernel:  spl_panic+0xf0/0x108 [spl]
июл 08 20:50:53 0F-BMAX kernel:  ? dnode_rele_and_unlock+0x59/0xf0 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  dmu_write+0xb5/0x190 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  space_map_write+0x154/0x900 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  ? zap_lookup+0xdb/0x100 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  metaslab_flush+0xcd/0x350 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  ? spa_cleanup_old_sm_logs+0xbc/0x170 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  spa_flush_metaslabs+0x195/0x420 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  spa_sync+0x5f9/0xf90 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  ? spa_txg_history_init_io+0x113/0x120 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  txg_sync_thread+0x227/0x3e0 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  ? txg_fini+0x260/0x260 [zfs]
июл 08 20:50:53 0F-BMAX kernel:  ? __thread_exit+0x20/0x20 [spl]
июл 08 20:50:53 0F-BMAX kernel:  thread_generic_wrapper+0x57/0x70 [spl]
июл 08 20:50:53 0F-BMAX kernel:  kthread+0xd7/0x100
июл 08 20:50:53 0F-BMAX kernel:  ? kthread_complete_and_exit+0x20/0x20
июл 08 20:50:53 0F-BMAX kernel:  ret_from_fork+0x1f/0x30
июл 08 20:50:53 0F-BMAX kernel:  </TASK>
июл 08 20:50:53 0F-BMAX zed[11725]: eid=1 class=data pool='Safe' priority=0 err=52 flags=0x808881 bookmark=0:77:1:0
июл 08 20:50:53 0F-BMAX zed[11729]: eid=2 class=checksum pool='Safe' vdev=T4T1DATA algorithm=fletcher4 size=4096 offset=322630197248 priority=0 err=52 flags=0x180880 bookmark=0:77:1:0
июл 08 20:50:53 0F-BMAX zed[11730]: eid=3 class=checksum pool='Safe' vdev=T4T1DATA algorithm=fletcher4 size=4096 offset=300510576640 priority=0 err=52 flags=0x180880 bookmark=0:77:1:0
июл 08 20:50:53 0F-BMAX zed[11731]: eid=4 class=checksum pool='Safe' vdev=T4T1DATA algorithm=fletcher4 size=4096 offset=287929151488 priority=0 err=52 flags=0x180880 delay=13ms bookmark=0:77:1:0
июл 08 20:54:24 0F-BMAX kernel: INFO: task zpool:11636 blocked for more than 120 seconds.
июл 08 20:54:24 0F-BMAX kernel:       Tainted: P           OE      6.1.0-22-amd64 #1 Debian 6.1.94-1
июл 08 20:54:24 0F-BMAX kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
июл 08 20:54:24 0F-BMAX kernel: task:zpool           state:D stack:0     pid:11636 ppid:3271   flags:0x00004002
июл 08 20:54:24 0F-BMAX kernel: Call Trace:
июл 08 20:54:24 0F-BMAX kernel:  <TASK>
июл 08 20:54:24 0F-BMAX kernel:  __schedule+0x34d/0x9e0
июл 08 20:54:24 0F-BMAX kernel:  schedule+0x5a/0xd0
июл 08 20:54:24 0F-BMAX kernel:  io_schedule+0x42/0x70
июл 08 20:54:24 0F-BMAX kernel:  cv_wait_common+0xaa/0x130 [spl]
июл 08 20:54:24 0F-BMAX kernel:  ? cpuusage_read+0x10/0x10
июл 08 20:54:24 0F-BMAX kernel:  txg_wait_synced_impl+0xcb/0x110 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  txg_wait_synced+0xc/0x40 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  spa_load+0x153a/0x17c0 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  spa_load_best+0x54/0x2c0 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  spa_import+0x232/0x6b0 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  zfs_ioc_pool_import+0x157/0x180 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  zfsdev_ioctl_common+0x8d2/0xa00 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  zfsdev_ioctl+0x4f/0xd0 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  __x64_sys_ioctl+0x8d/0xd0
июл 08 20:54:24 0F-BMAX kernel:  do_syscall_64+0x55/0xb0
июл 08 20:54:24 0F-BMAX kernel:  ? do_filp_open+0xaf/0x160
июл 08 20:54:24 0F-BMAX kernel:  ? do_filp_open+0xaf/0x160
июл 08 20:54:24 0F-BMAX kernel:  ? __rseq_handle_notify_resume+0xa9/0x4a0
июл 08 20:54:24 0F-BMAX kernel:  ? exit_to_user_mode_prepare+0x44/0x1f0
июл 08 20:54:24 0F-BMAX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
июл 08 20:54:24 0F-BMAX kernel:  ? do_syscall_64+0x61/0xb0
июл 08 20:54:24 0F-BMAX kernel:  ? call_rcu+0xde/0x6b0
июл 08 20:54:24 0F-BMAX kernel:  ? exit_to_user_mode_prepare+0x44/0x1f0
июл 08 20:54:24 0F-BMAX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
июл 08 20:54:24 0F-BMAX kernel:  ? do_syscall_64+0x61/0xb0
июл 08 20:54:24 0F-BMAX kernel:  ? clear_bhb_loop+0x15/0x70
июл 08 20:54:24 0F-BMAX kernel:  ? clear_bhb_loop+0x15/0x70
июл 08 20:54:24 0F-BMAX kernel:  ? clear_bhb_loop+0x15/0x70
июл 08 20:54:24 0F-BMAX kernel:  ? clear_bhb_loop+0x15/0x70
июл 08 20:54:24 0F-BMAX kernel:  ? clear_bhb_loop+0x15/0x70
июл 08 20:54:24 0F-BMAX kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
июл 08 20:54:24 0F-BMAX kernel: RIP: 0033:0x7f5c1036ac5b
июл 08 20:54:24 0F-BMAX kernel: RSP: 002b:00007fff18f7f020 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
июл 08 20:54:24 0F-BMAX kernel: RAX: ffffffffffffffda RBX: 00005626f5cf3540 RCX: 00007f5c1036ac5b
июл 08 20:54:24 0F-BMAX kernel: RDX: 00007fff18f7f0f0 RSI: 0000000000005a02 RDI: 0000000000000003
июл 08 20:54:24 0F-BMAX kernel: RBP: 00007fff18f82fe0 R08: 00007f5c104403f0 R09: 00007f5c104403f0
июл 08 20:54:24 0F-BMAX kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff18f7f0f0
июл 08 20:54:24 0F-BMAX kernel: R13: 00005626f5d14ea0 R14: 0000000000000000 R15: 00005626f5d14e10
июл 08 20:54:24 0F-BMAX kernel:  </TASK>
июл 08 20:54:24 0F-BMAX kernel: INFO: task txg_sync:11716 blocked for more than 120 seconds.
июл 08 20:54:24 0F-BMAX kernel:       Tainted: P           OE      6.1.0-22-amd64 #1 Debian 6.1.94-1
июл 08 20:54:24 0F-BMAX kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
июл 08 20:54:24 0F-BMAX kernel: task:txg_sync        state:D stack:0     pid:11716 ppid:2      flags:0x00004000
июл 08 20:54:24 0F-BMAX kernel: Call Trace:
июл 08 20:54:24 0F-BMAX kernel:  <TASK>
июл 08 20:54:24 0F-BMAX kernel:  __schedule+0x34d/0x9e0
июл 08 20:54:24 0F-BMAX kernel:  schedule+0x5a/0xd0
июл 08 20:54:24 0F-BMAX kernel:  spl_panic+0x106/0x108 [spl]
июл 08 20:54:24 0F-BMAX kernel:  ? dnode_rele_and_unlock+0x59/0xf0 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  dmu_write+0xb5/0x190 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  space_map_write+0x154/0x900 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  ? zap_lookup+0xdb/0x100 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  metaslab_flush+0xcd/0x350 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  ? spa_cleanup_old_sm_logs+0xbc/0x170 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  spa_flush_metaslabs+0x195/0x420 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  spa_sync+0x5f9/0xf90 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  ? spa_txg_history_init_io+0x113/0x120 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  txg_sync_thread+0x227/0x3e0 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  ? txg_fini+0x260/0x260 [zfs]
июл 08 20:54:24 0F-BMAX kernel:  ? __thread_exit+0x20/0x20 [spl]
июл 08 20:54:24 0F-BMAX kernel:  thread_generic_wrapper+0x57/0x70 [spl]
июл 08 20:54:24 0F-BMAX kernel:  kthread+0xd7/0x100
июл 08 20:54:24 0F-BMAX kernel:  ? kthread_complete_and_exit+0x20/0x20
июл 08 20:54:24 0F-BMAX kernel:  ret_from_fork+0x1f/0x30
июл 08 20:54:24 0F-BMAX kernel:  </TASK>

Как то давно поставил zfs, экспериментируя раздал точки монтирования подтомам. Сейчас решил сменить точку монтирования тома.
Попытка сменить точку монтирования у тома даёт: Dataset is busy
Ладно, сделал set mountpoint=none всем подтомам, сменил точку монтирования тома, а в нём пусто... Сменил у всех подтомов точку монтирования на legacy = получил тот же хрен...
Экспортировал, импортировал том - подтома всё так же «оторваны»

T3T1Solo 706G 92.7G 99.9G /zfs/T3T1Solo
T3T1Solo/Backup 563G 92.7G 41K legacy
T3T1Solo/Backup/gzip-9 563G 92.7G 444G legacy
T3T1Solo/Backup/gzip-9/ShortBackup 118G 92.7G 118G legacy
T3T1Solo/Backup/lz4 27K 92.7G 27K legacy
T3T1Solo/Backup/off 24K 92.7G 24K legacy
T3T1Solo/DL 43.2G 92.7G 43.2G legacy
T3T1Solo/subYDZFS 72K 92.7G 24K legacy
T3T1Solo/subYDZFS/Obsolete 24K 92.7G 24K legacy
T3T1Solo/subYDZFS/Solo 24K 92.7G 24K legacy

Подскажите, как правильно их вернуть в иерархию относительно T3T1Solo?
Я конечно сейчас явно пропишу все вложенные туда куда смонтировал T3T1Solo, но правильно ли это?

Или сделать брутально? Создать новые подтома и рсинкнуть туда старые?

По совету гуру местного форума, купил себе МикроПК.
И теперь это мой эксперимент. Поставил Debian Bookworm x64,
но поставил не на ext4 а на jfs. Всё бы хорошо, но МикроПК - BMAX B1 pro - не прошел испытаний. Поначалу я обрадовался, он на самом «злом» алгоритме упаковки zfs: zstd-19 - который жужжал по 11 часов показывал производительность выше чем P4. Но, когда я решил взглянуть Ютуб - он «упал» (Слишком высокая температура). При перезагрузке он «рисовал"перманентный „трап“, который решился перезагрузкой со сменного носителя и fsck этого раздела.

Помогите сделать выбор. Сменить fs с помощью fstransform или каким то образом заставить jfs взлтать после падений?

До кучи - подскажите, как в новой системе журналов - посмотреть журналы падающей системы - загрузившись с внешнего носителя (например с флешки). Мне вот даже сложно здесь привести аргументы. Загрузился с флешки и пишу вам сообщение, сделал fsck корневого раздела и сейчас перезагружусь в него.


Перемещено hobbit из general

Приветствую, уважаемое сообщество.
Занялся тут изучением zfs и прогоном скорости паковки разными алгоритмами. Вся работа была с SATA hdd подключенном через USB3 рэк. Идея была в прогоне этого винта на разных процессорах и замера скорости упаковки (отработки rsync на одних и тех же данных).
Всё сумбурно, и не всегда читал/фиксировал вывод команд. Они в общем то выводили в скриптах и в финале ошибки уже пролетали. После очередного цикла - заметил ошибку при rm -rf
Оставались неудаляемые файлы. Я даже и не представляю как это показать общественности.

Например

/usr/share/icons/matefaenza/mimetypes# ls -ld 64 
drwxr-xr-x 2 root root 373 мая 27  2018 64

/usr/share/icons/matefaenza/mimetypes# rm -rf 64 
rm: невозможно удалить '64': Каталог не пуст

/usr/share/icons/matefaenza/mimetypes# ls -l 64 
ls: чтение каталога '64': Ошибка ввода/вывода
итого 0

/usr/share/icons/matefaenzadark/actions/16# ls -l stock_mail-send-receive.png 
ls: невозможно получить доступ к 'stock_mail-send-receive.png': Некорректный обмен

# zfs list
NAME                         USED  AVAIL     REFER  MOUNTPOINT
S1T1Archive                  736G   164G     16.6M  /S1T1Archive
S1T1Archive/gzip            37.7G   164G     37.7G  /S1T1Archive/gzip
S1T1Archive/gzip-1          38.6G   164G     38.6G  /S1T1Archive/gzip-1
S1T1Archive/gzip-9          37.6G   164G     37.6G  /S1T1Archive/gzip-9
S1T1Archive/lz4             41.4G   164G     41.4G  /S1T1Archive/lz4
S1T1Archive/lzjb            43.9G   164G     43.9G  /S1T1Archive/lzjb
S1T1Archive/off             64.4G   164G     64.4G  /S1T1Archive/off
S1T1Archive/off-copy        64.4G   164G     64.4G  /S1T1Archive/off-copy
S1T1Archive/zle             60.8G   164G     60.8G  /S1T1Archive/zle
S1T1Archive/zstd            37.9G   164G     37.9G  /S1T1Archive/zstd
S1T1Archive/zstd-1          38.2G   164G     38.2G  /S1T1Archive/zstd-1
S1T1Archive/zstd-19         36.9G   164G     36.9G  /S1T1Archive/zstd-19
S1T1Archive/zstd-fast       39.5G   164G     39.5G  /S1T1Archive/zstd-fast
S1T1Archive/zstd-fast-1     39.5G   164G     39.5G  /S1T1Archive/zstd-fast-1
S1T1Archive/zstd-fast-10    42.2G   164G     42.2G  /S1T1Archive/zstd-fast-10
S1T1Archive/zstd-fast-100   50.4G   164G     50.4G  /S1T1Archive/zstd-fast-100
S1T1Archive/zstd-fast-1000  60.5G   164G     60.5G  /S1T1Archive/zstd-fast-1000

В LOR сообществе масса профессионалов, и надеюсь мне дадут ответ, на давно мучающий вопрос.

Постоянно мы сталкиваемся с массой гаджетов, и большинство сейчас питается от LiION аккумуляторов. Сейчас распространен формат: 18650 и у меня в голове не укладывается схема их соединения в павербанках. Они там соединены параллельно. В моей голове укладывается только вариант того, что в каждой батарее вмонтировано своё зарядное устройство, не позволяющее току перетекать из заряженного элемента в разряженный и выбирающее свой ток заряда для каждого элемента, достаточно подать номинальное напряжение заряда. Или таки они там перетекают? Тогда что ограничивает эти перетекающие токи?

Как чёрт-побери устроен это аккумулятор позволяющий параллельный заряд/разряд?

Заранее прошу прощения если это злостный оффтопик, но не представляю где ещё спросить это.

Стоит Debian Bookworm, zfs-dkms.
История идёт давно. Купил 4Т винт и начался анекдот про негра жмущего F6-ENTER-TAB-F6. Началась реорганизация всего барахла между 16TB дискового пространства из 5 дисков.

В частности была операция по резервированию «половинки» от старого рейда (DEGRADED RAID). Идея была в том чтобы тупо /dev/md0 /dev/md1 (root,/opt) рсинкнуть на zfs с упаковкой gzip-9, затем вместо DEGRADED рейда сделать один раздел zfs/gzip-9 и вернуть данные на него.
(Раз пишу - отчитаюсь: с первого взгляда squash не сильно опережает gzip-9. Для примера корень размером 64Gb, на zfs занимает 38Gb к которым можно полноценно обращаться. squashfs вариант занимает 36Gb, но он естественно только для чтения.)

Финал, не спал, может забыл, но:
rsync -axvPH md0-root /S1TArchive - Посчитал и ничего не стал копировать. Как будто в назначении уже есть все эти файлы. Но там ЧИСТО!

Я все ключи перепробовал. Не помогает! Потом пришла мысль: Сделать на назначении каталог: 2Try. Добавил rsync в назначении /2Try и он начал копировать... НО! В другом окне, в mc я вижу чистый каталог!

Сейчас сижу, пишу сообщение, а в фоне 2 окна с копиями. В одном копирует rsync, а в другом ТУПО нажал F5 в mc, в каталог /3Try.

Так вот rsync трудится, а файлы в пути назначения НЕ ПОЯВЛЯЮТСЯ!
В другом окне - mc копирует и файлы появляются.

Какие есть предположения? Что это за «подземный стук»?
P.S. Винт назначения (впрочем и источник тоже) включен по USB3 и в финале экспортирую винт назначения и взгляну на него с другого компа (откуда он родом).

P.P.S. Дело было не в бобине...
Модеры могут удалить тему, а могут сохранить. В назидание.
Я понимал что этого не может быть, но упорно не видел ошибку.
Рсинк в скрипте шел не в тот каталог в котором я смотрел, разница была в букве и цифре, вместо винта S1 всё шло на T2.
Бывает когда подмонтировал к одному компу 5 Многотерабайтных винтов...

Первая покупка:

Model Family:     Toshiba 3.5" MG03ACAxxx(Y) Enterprise HDD
Device Model:     TOSHIBA MG03ACA400
Serial Number:    Z4FEK62FF
LU WWN Device Id: 5 000039 5fbd822f6
Firmware Version: FL1A
User Capacity:    4 000 785 948 160 bytes [4,00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches

Model Family:     Toshiba 3.5" MG03ACAxxx(Y) Enterprise HDD
Device Model:     TOSHIBA MG03ACA400
Serial Number:    Z494K77TF
LU WWN Device Id: 5 000039 5fb88138a
Firmware Version: FL1A
User Capacity:    4 000 787 030 016 bytes [4,00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches

Dimez

Ты написал очень много букв вместо простой проверки HPA.

И тут всё встало на места, я «посыпал голову пеплом», за 33+ года работы с компами я знал аббревиатуру HPA, но НИ РАЗУ не использовал и не знал сути.

#hdparm -N /dev/sda
/dev/sda:
max sectors = 7814035055/7814037168, HPA is enabled

#hdparm -N p7814037168 /dev/sda

# hdparm -N /dev/sda

/dev/sda:
 max sectors   = 7814037168/7814037168, HPA is disabled

cannot attach /dev/sdc2 to /dev/sda3: can only attach to mirrors and top-level disks

	NAME        STATE     READ WRITE CKSUM
	zer0-safe   ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sda3    ONLINE       0     0     0
	    sdc2    ONLINE       0     0     0  block size: 512B configured, 4096B native

Целиком диски? gpt разделы? Их UUID? Или может банально LVM VG/LV? Ведь LVM переносим и его адресация не зависит от имени диска, но с ним гораздо проще видеть организацию тома чем по UUID.

Проще ведь видеть разделы по именам:

   pool: zfs-raidz_4
     id: 14845661564733668607
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        zfs-raidz_4  ONLINE
          Data_1     ONLINE
          Data_2     ONLINE
          Data_3     ONLINE
          Data_4     ONLINE

   pool: zfs-mirror
     id: 11702920276725354413
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        zfs-mirror                                ONLINE
          mirror-0                                ONLINE
            72cf2c0b-fe32-4649-9aa6-45d1314d1139  ONLINE
            27300dce-6a76-6a49-a10c-905100118633  ONLINE

Решил поставить zfs, как и раньше написал: #apt install zfs-dkms
Но в этот раз оно ругнулось: Module build for kernel 6.1.0-20-amd64 was skipped since the kernel headers for this kernel do not seem to be installed.

Увы, тут помню тут не помню. Просто доставил linux-source (Логично что там и headers должны быть) - не помогло. Долго гуглил ошибку, вразумительного решения не нагуглил. Потом решил посмотреть не со стороны проблемы, а со стороны задачи и начал гуглить «Debian Bookworm установить zfs».
Сразу же нашлось на:
https://orcacore.com/set-up-zfs-debian-12-bookworm/

sudo apt install linux-headers-amd64 zfsutils-linux zfs-dkms zfs-zed -y

У меня не хватало linux-headers-amd64

Не понятно, почему все предыдущие разы оно поставилось без проблем? Ведь так же ставил Bookworm с netinst usb и устанавливал. Подгружались все зависимости и собиралось.