К сравнению надёжности и наработки на критический отказ btrfs и ext3

Понятно. Тут дело не в бобине пацаны, расходимся.

но у меня и до этого были разные приключения с ext3-ext4 файловыми системами.

Опа! А это оказывается не единичный случай акта насилия над флешками со стороны ТС.

И то, что запись на файловую систему ext3 стала пороговой записью для контроллера, после которой он перевёл flash память в режим только чтения не означает, что виной этому ext3.

Допустим, но это если контролёр флешки умный и на нём есть WearLeveling, про который ты сейчас говоришь.
И вот тут у меня есть сомнения в том, что на нём это есть.

Понятно. Тут дело не в бобине пацаны, расходимся.

Если дело не в бобине, то почему у меня с btrfs всё хорошо?
может потому что btrfs надёжнее и разумнее EXTx файловых систем?

Ну так вскрой флэшку, найди микросхему и найди на нё даташит. У меня сомнений нет. Как и сомнений в том, что ты не понимаешь ничего ни в устройстве флэш, ни в устройстве ФС и бредишь. Тебе тут 3 разных человека уже аргументировали, что ты не прав, че выкобениваешься то? Иди лучше изучай матчасть, чтобы не задавать таких вопросов ещё раз.

Если дело не в бобине, то почему у меня с btrfs всё хорошо?

Потому, что дело не в бобине, а в прокладке между стулом и монитором.

Если дело не в бобине, то почему с btrfs всё хорошо?

Потому что БТР не подводит танкистов.

Если дело не в бобине, то почему с btrfs всё хорошо?

Потому что БТР не подводит танкистов.

Чему тема и посвящена, в практическом использовании btrfs лучше чем ext3/ext4.

Ну ещё я думал что кто данными о крахе заинтересуется, мало ли какую полезную информацию для улучшения кода ФС найдёт.

Чем меньше свободного пространства на разделе, тем больше перезаписей приходится на одни и те же блоки. А журналы так вообще постоянно пишутся максимально в одно и тоже место. Чем меньше раздел, тем больше перезаписей. Во всяком случае, я это воспринимаю так.

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

Так даташит будет на контроллёр? Или все должны верить твоим словам, что ext3 убивает флэшки?

Чему тема и посвящена

Из мотопехоты ТС один в «теме». Все остальные «асы» и «Штирлицы».

Для тех, кто в танке: Не насилуй свои флешки.

Чему тема и посвящена, в практическом использовании btrfs лучше чем ext3/ext4.

Да ничего твоя тема не доказывает. Она лишь доказывает, что в момент внесения измений в метаинформацию файловую системы ext3 контроллер заблокировал запись на флеш памяти и поэтому у тебя рухнула ext3 и всё.

Если бы у тебя в этот момент что-либо писалось на btfs, то рухнулабы она.

Да не. Он даже когда у него бэтр рассыплется, будет кричать что «бэтр хорош, это ваше говно даже сломаться нормально не умеет - почти всегда чинится, а вот бэтр если ломается то насовсем».

будет кричать что «бэтр хорош, это ваше говно даже сломаться нормально не умеет

Плюсую.

Так даташит будет на контроллёр?

Речь о флешке Sandisk Cruser Fit

root@debian:~# lsusb -v -d 0781:5571

Bus 002 Device 008: ID 0781:5571 SanDisk Corp. Cruzer Fit
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5571 Cruzer Fit
  bcdDevice            1.27
  iManufacturer           1 SanDisk
  iProduct                2 Cruzer Fit
  iSerial                 3 4C530102870215113483
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)
root@debian:~#

Я знаю, о чем речь. Раз он в RO - ударь молотком и скажи что там за контроллёр. Ты совсем глупый? У меня таких флэшек лежит несколько, и в RO в том числе. А ещё даже в MicroSD уже давно WearLeveling есть, странное ты создание.

У тебя флешка могла умереть даже от статики и любой перегрузки по питанияю.

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

Есть специ утилиты, но они для Windows, от китайцев, которые позволят восстановить работоспособность флешки, только данные все будут затёрты и немного уменьшена ёмкость.

Да не. Он даже когда у него бэтр рассыплется, будет кричать что «бэтр хорош, это ваше говно даже сломаться нормально не умеет - почти всегда чинится, а вот бэтр если ломается то насовсем».

По моемпу ты сам фанатик, я просто смотрю какая ФС мне доставляет больше не обоснованных проблем, ей оказывается ext3/4.

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

Что-нибудь вроде smartctl -d sat -A /dev/sdc не работает?

я просто смотрю какая ФС мне доставляет больше не обоснованных проблем, ей оказывается ext3/4

Правильно. Давай вместе топить за reiserfs.

Используй лубую фс которую хочешь. Только в данном случае флешка умерла не от ext3, а от того, что ты её (флешку) использовал не по назначению и ext3 просто оказалась последней куда писалась запись.

В данном случае у тебя флешка умерла от количества циклов записи.

Но этот кусок сам понимаешь чего, мог умереть и просто от статики, потому что в таких маленьких флешки контакты припаяны напрямую к контроллеру.

Что-нибудь вроде smartctl -d sat -A /dev/sdc не работает?

root@debian:/home/user# smartctl --all /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-7-amd64] (local build)
....
/dev/sdc: Unknown USB bridge [0x0781:0x5571 (0x127)]
...
root@debian:/home/user# smartctl -d sat -A /dev/sdc
...
Read Device Identity failed: scsi error unsupported scsi opcode
...

Чтобы умерло от статики надо как либо физически трогать флешку или её контакты, как можно понять флешку я флешку не дорставал и не трогал, откуда там взяться электростатическому удару?

Во вторых, электростатика бы просто сожгла входы и флешка бы не работала вообще.

электростатика бы просто сожгла входы

Фига себе! У тебя комп от танкового акума питается, что ли?

У тебя проблема с логикой. Ты прочитал что я написал?

Я написал, что у тебя флешка перешла в RO потому, что достигнут порог циклов записи.

Но такой кусок сам понимаешь чего мог умееть и от статики, я это написал лишь к тому, что сама по себе флешка у тебя так себе.

И надеяться на то, что у тебя там хорошая флеш памяти с большим числом циклов записи не стоит.

Не для SanDisk. Я в теме.

Да хватит уже этого упоротого лечить пытаться. Здесь только лоботомия поможет, и она уже, видимо, была сделана.

Понимешь, у меня такое впечатление, что со мной переписываются фанатики ext3, при чём глупые фанатики, так как даже нормально провести защиту своей ФС не могут.

И так,
1. электростатического удара не было и быть не могло, а если бы даже в следствие касания и был то из-за конструкции разъёма флешки пошёл бы через внешнею металлическую часть на землю материнки и сжёг бы что угодно, кроме самой флешки.
2. На флешке нет смарта К сравнению надёжности и наработки на критический отказ btrfs и ext3 (комментарий) по этому контролёр судя по всему у флешки простой.
3. Внешний вид флешки Sandisk Cruser Fit располагает к тому, что контролёр её крайне примитивен и не факт что он умел переназначать блоки памяти, а значит каждая ФС скорее всего писалась только на "свои" блоки флешпамяти.

При чём я допускаю слова "так получилось" и "возможно", нол вы т вы как раз как фанатик катигорично отрицаете то что выглядит достаточно вероятным.

Это вы фанатики, а не я.

Да хватит уже этого упоротого лечить пытаться.

И тебе тоже К сравнению надёжности и наработки на критический отказ btrfs и ext3 (комментарий)
Сам упоротый.

Понимаешь, ты даже не понимаешь, что мы все тебе говорим, мы не говорим, что ext3 лучше btrfs или btrfs лучше, а ext3 - хуже.

Мы лишь говорим, что причиной поломки файловой системы ext3 в данном случае и сохранении работоспособности btrfs стало то, что контроллер перевёл flash памяти в режим только чтения.

И то, что это произошло во время записи служебной информации на флеш накопитель просто случайность.

То, что smartctl не умеет считывать информацию с контроллера флеш накопителя это нормально и это ничего не показывает.

Что бы понять что умеет делать контроллер тебу нужно в начале определить что это за контроллер.

Что бы понять что умеет делать контроллер тебу нужно в начале определить что это за контроллер.

Ну я привёл всю информацию какая у меня есть.
К сравнению надёжности и наработки на критический отказ btrfs и ext3 (комментарий)
К сравнению надёжности и наработки на критический отказ btrfs и ext3 (комментарий)
Если есть что определить, могу определить, но скажи как это сделать.
Ну могу ещё сказать то, что запись на флешку со временем очень сильно замедлялась и после форматирования какоето время шла быстрее(я давно переустанавливал ОС).
Это конечно можно понимать и так, что контролёр медленно писал так как подбирал наименее использованные блоки и переносил с них информацию ещё куда-то.
Но это версия, он мог замедляться просто из-за роста таблицы ПЕРЕНАЗНАЧЕННЫХ, а неперенесённых блоков.
А так крохотный размер флешки и то, что это младшая серия позволяют думать что контролёр был примитивен и переносить блоки не умел, а значит было чёткое разделение на блоки ext3 и блоки btrfs, которые из-за специфики разных файловых систем изнашивались с разной скоростью.
Ну я конечно понимаю что это версия, но она не хуже и не лучше вашей о том, что контролёр блоки переносил и соответственно ext3 и btrfs пользовались одним общим массивом блоков.

И то, что это произошло во время записи служебной информации на флеш накопитель просто случайность.

Если моя версия о том, что ext3 и btrfs из-за отсутствия в контролёре переноса блоков правильна, то износ блоков под ext3 и btrfs был разным и то, что отказ произошёл на ext3 не случайность, как и не было бы случайностью если бы он произошёл на btrfs.
(Но вот на ext3 сломался, а не на btrfs)

Для чистоты эксперимента обеспечь, что бы размеры файловой системы ext3 и btrfs был одинаков, а так же реальный процент занятого пространства, а потом проверяй.

Ну у ext3 то условия более выгодные, на неё пишутся только ядра и initrd и не при каждом обновлении в отличии от btrfs у которой занятось меньше 40% не смотря на компрессию не опускалась и на которой находится всё остальное кроме хомяка.
Вот если бы btrfs обвалилась то тогда да, про равные условия говорить бы стоило.

При этом надо учесть что занятость у ext3 подскочила до 18% недавно, в связи с установкой memtest86+, раньше она была ещё меньше.

Насколько я понимаю, контроллер далеко не каждой флешки умеет в wear leveling

https://forums.anandtech.com/threads/any-fit-size-usb-flash-drives-with-static-wear-leveling.2524358/

У меня тоже флешка с линем (арчем) есть. Она уже года 2 живет на btrfs разделе с сжатием.

Kubuntu Xenial 16.04 и прочие производные де первично потому что технология была создана на них , арч вторично и не нужно , просто арч это порозит

технология была создана на них

Не совсем понимаю. btrfs была создана для Kubuntu Xenial или сжатие?

Разупорись кошечка!

Зачем ты используешь журнал. ФС для флешки? Есть ext2 и fat32 для этого.

В Btrfs нет журнала.

Так это не простая btrfs балбесина она внутри ext4 работает наверное как контейнер и по этому журнал есть ,увидеть как происходит проверка btrfs можно в режиме старта без plymoth

Не читайте этот тред. Тут бред.

Я прочитал 😕

По автору темы уже можно понять.

Чё за херню ты несёшь

Это достаточно умный контроллёр. И всё он умеет: и в RO переводиться при сбоях ячеек, и износ выраснивать.

Так ведь обычные флешки под систему дохнут как мухи? Тут уже долговечность упирается не в фс а саму флеш память. Если сдох сектор по понятным причинам в месте где расположен ext3 или btrfs, это не значит что кто то из них является виновником.

сначала докажи, что на ехт3 бэдов нет, как на бтрфс