[vgovseychuk 0]

Всем привет!

 

Интересует вопрос, как сделать возможным возврат системы к начальным настройкам (overlay)?

 

Сейчас на NAND-флешке 5 разделов: bootloader, environment, devicetree, kernel и rootfs.

Файловая система UBIFS.

Систему собирал сам, железо кастомное, поэтому некоторых модулей может не быть.

Доп. инфа:

root@OpenWrt:~# mount
rootfs on / type rootfs (rw)
ubi0_0 on / type ubifs (rw,noatime)
proc on /proc type proc (rw,noatime)
sysfs on /sys type sysfs (rw,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

root@OpenWrt:~# df -h
Filesystem				Size	  Used Available Use% Mounted on
rootfs				  104.6M	 14.7M	 89.9M  14% /
ubi0_0				  104.6M	 14.7M	 89.9M  14% /
tmpfs					61.2M	528.0K	 60.7M   1% /tmp
tmpfs				   512.0K		 0	512.0K   0% /dev

 

Ну и простыня dmesg (не нашел, как скрыть/свернуть, если знаете, научите):

root@OpenWrt:~# dmesg
[	0.000000] Booting Linux on physical CPU 0x0
[	0.000000] Linux version 3.18.21 (denominat0r@denominat0r-virtual-machine) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r47239) ) #3 Wed Oct 21 14:18:47 MSK 2015
[	0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[	0.000000] CPU: VIVT data cache, VIVT instruction cache
[	0.000000] Machine model: I2SE Duckbill
[	0.000000] Memory policy: Data cache writeback
[	0.000000] On node 0 totalpages: 32768
[	0.000000] free_area_init_node: node 0, pgdat c0434448, node_mem_map c7efc000
[	0.000000]   Normal zone: 256 pages used for memmap
[	0.000000]   Normal zone: 0 pages reserved
[	0.000000]   Normal zone: 32768 pages, LIFO batch:7
[	0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[	0.000000] pcpu-alloc: [0] 0 
[	0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[	0.000000] Kernel command line: console=ttyAPP4,115200 rootfstype=ubifs ubi.mtd=4 root=ubi0_0 rw mtdparts=gpmi-nand:100m(bootloader)ro,256k(environment),128k(fdt),5m(kernel),-(rootfs)
[	0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[	0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[	0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[	0.000000] Memory: 125244K/131072K available (3234K kernel code, 104K rwdata, 884K rodata, 128K init, 188K bss, 5828K reserved)
[	0.000000] Virtual kernel memory layout:
vector  : 0xffff0000 - 0xffff1000   (   4 kB)
fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
modules : 0xbf000000 - 0xc0000000   (  16 MB)
  .text : 0xc0008000 - 0xc040dce4   (4120 kB)
  .init : 0xc040e000 - 0xc042e000   ( 128 kB)
  .data : 0xc042e000 - 0xc0448340   ( 105 kB)
   .bss : 0xc0448340 - 0xc047741c   ( 189 kB)
[	0.000000] NR_IRQS:16 nr_irqs:16 16
[	0.000046] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
[	0.000496] Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)
[	0.080344] pid_max: default: 32768 minimum: 301
[	0.080688] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[	0.080739] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[	0.081977] CPU: Testing write buffer coherency: ok
[	0.082824] Setting up static identity map for 0x40010eb8 - 0x40010f10
[	0.087793] pinctrl core: initialized pinctrl subsystem
[	0.088973] regulator-dummy: no parameters
[	0.107484] NET: Registered protocol family 16
[	0.108742] DMA: preallocated 256 KiB pool for atomic coherent allocations
[	0.112158] cpuidle: using governor ladder
[	0.112260] cpuidle: using governor menu
[	0.144355] Serial: AMBA PL011 UART driver
[	0.145078] 80074000.serial: ttyAMA0 at MMIO 0x80074000 (irq = 216, base_baud = 0) is a PL011 rev2
[	0.165697] mxs-dma 80004000.dma-apbh: initialized
[	0.172488] mxs-dma 80024000.dma-apbx: initialized
[	0.173792] 3P3V: 3300 mV 
[	0.174091] reg-fixed-voltage regulators:3p3v: 3P3V supplying 3300000uV
[	0.174794] usb0_vbus: 5000 mV 
[	0.175032] reg-fixed-voltage regulators:usb0_vbus: usb0_vbus supplying 5000000uV
[	0.175725] usb1_vbus: 5000 mV 
[	0.175956] reg-fixed-voltage regulators:usb1_vbus: usb1_vbus supplying 5000000uV
[	0.178117] usbcore: registered new interface driver usbfs
[	0.178463] usbcore: registered new interface driver hub
[	0.178726] usbcore: registered new device driver usb
[	0.179227] pps_core: LinuxPPS API ver. 1 registered
[	0.179263] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
[	0.179429] PTP clock support registered
[	0.183035] Switched to clocksource mxs_timer
[	0.187735] NET: Registered protocol family 2
[	0.189744] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[	0.189831] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[	0.189887] TCP: Hash tables configured (established 1024 bind 1024)
[	0.190069] TCP: reno registered
[	0.190121] UDP hash table entries: 256 (order: 0, 4096 bytes)
[	0.190178] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[	0.190734] NET: Registered protocol family 1
[	0.194189] futex hash table entries: 256 (order: -1, 3072 bytes)
[	0.207369] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[	0.207437] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) © 2001-2006 Red Hat, Inc.
[	0.208244] msgmni has been set to 244
[	0.213447] io scheduler noop registered
[	0.213515] io scheduler deadline registered (default)
[	0.214415] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[	0.216391] Serial: AMBA driver
[	0.216725] of_dma_request_slave_channel: dma-names property of node '/apb@80000000/apbx@80040000/serial@80074000' missing or empty
[	0.216784] uart-pl011 80074000.serial: no DMA platform data
[	0.217608] 8006c000.serial: ttyAPP1 at MMIO 0x8006c000 (irq = 214, base_baud = 1500000) is a 8006c000.serial
[	0.218388] mxs-auart 8006c000.serial: Found APPUART 3.1.0
[	0.218974] 80072000.serial: ttyAPP4 at MMIO 0x80072000 (irq = 215, base_baud = 1500000) is a 80072000.serial
[	0.649003] console [ttyAPP4] enabled
[	0.653503] mxs-auart 80072000.serial: Found APPUART 3.1.0
[	0.694715] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xda
[	0.701113] nand: Macronix MX30LF2G18AC
[	0.705073] nand: 256MiB, SLC, page size: 2048, OOB size: 64
[	0.710866] Scanning device for bad blocks
[	0.721202] Bad eraseblock 1 at 0x000000020000
[	0.727059] Bad eraseblock 2 at 0x000000040000
[	0.733156] Bad eraseblock 3 at 0x000000060000
[	1.163750] 5 cmdlinepart partitions found on MTD device gpmi-nand
[	1.169974] Creating 5 MTD partitions on "gpmi-nand":
[	1.175160] 0x000000000000-0x000006400000 : "bootloader"
[	1.183912] 0x000006400000-0x000006440000 : "environment"
[	1.191816] 0x000006440000-0x000006460000 : "fdt"
[	1.199165] 0x000006460000-0x000006960000 : "kernel"
[	1.206927] 0x000006960000-0x000010000000 : "rootfs"
[	1.215531] mtd: device 4 (rootfs) set to be root filesystem
[	1.222214] mtdsplit: no squashfs found in "rootfs"
[	1.227266] mtdsplit: no squashfs found in "gpmi-nand"
[	1.232464] gpmi-nand 8000c000.gpmi-nand: driver registered.
[	1.240725] fec 800f0000.ethernet: Looking up phy-supply from device tree
[	1.240798] fec 800f0000.ethernet: Looking up phy-supply property in node /ahb@80080000/ethernet@800f0000 failed
[	1.240836] 800f0000.ethernet supply phy not found, using dummy regulator
[	1.361201] libphy: fec_enet_mii_bus: probed
[	1.368021] fec 800f4000.ethernet: Looking up phy-supply from device tree
[	1.368092] fec 800f4000.ethernet: Looking up phy-supply property in node /ahb@80080000/ethernet@800f4000 failed
[	1.368129] 800f4000.ethernet supply phy not found, using dummy regulator
[	1.378150] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[	1.384875] ehci-platform: EHCI generic platform driver
[	1.391000] i2c /dev entries driver
[	1.397033] TCP: cubic registered
[	1.400424] NET: Registered protocol family 17
[	1.405236] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[	1.418016] 8021q: 802.1Q VLAN Support v1.8
[	1.427320] UBI: attaching mtd4 to ubi0
[	1.701441] random: nonblocking pool is initialized
[	3.037728] UBI: scanning is finished
[	3.064217] UBI: attached mtd4 (name "rootfs", size 150 MiB) to ubi0
[	3.070618] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[	3.077542] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[	3.084349] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[	3.091255] UBI: good PEBs: 1205, bad PEBs: 0, corrupted PEBs: 0
[	3.097352] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
[	3.104586] UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 0
[	3.112882] UBI: available PEBs: 0, total reserved PEBs: 1205, PEBs reserved for bad PEB handling: 40
[	3.122272] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[	3.135618] UBI: background thread "ubi_bgt0d" started, PID 277
[	3.145638] UBIFS: background thread "ubifs_bgt0_0" started, PID 280
[	3.330016] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[	3.336184] UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[	3.345429] UBIFS: FS size: 119357440 bytes (113 MiB, 940 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[	3.355346] UBIFS: reserved for root: 0 bytes (0 KiB)
[	3.360442] UBIFS: media format: w4/r0 (latest is w4/r0), UUID C1093420-21D9-495D-A90E-32D8584A8357, small LPT model
[	3.375535] VFS: Mounted root (ubifs filesystem) on device 0:10.
[	3.382230] Freeing unused kernel memory: 128K (c040e000 - c042e000)
[	3.775149] init: Console is alive
[	4.615180] SCSI subsystem initialized
[	4.647047] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[	4.655642] ohci-platform: OHCI generic platform driver
[	4.686062] platform 80080000.usb: Driver imx_usb requests probe deferral
[	4.693463] platform 80090000.usb: Driver imx_usb requests probe deferral
[	4.706951] imx_usb 80080000.usb: Looking up vbus-supply from device tree
[	4.707871] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: c8a60100 op: c8a60140
[	4.711278] ci_hdrc ci_hdrc.0: It is OTG capable controller
[	4.718955] ci_hdrc ci_hdrc.0: EHCI Host Controller
[	4.724043] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[	4.743176] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[	4.752301] hub 1-0:1.0: USB hub found
[	4.756888] hub 1-0:1.0: 1 port detected
[	4.764998] imx_usb 80090000.usb: Looking up vbus-supply from device tree
[	4.765943] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: c8a80100 op: c8a80140
[	4.769103] ci_hdrc ci_hdrc.1: It is OTG capable controller
[	4.769196] ci_hdrc ci_hdrc.1: EHCI Host Controller
[	4.774354] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
[	4.786728] usbcore: registered new interface driver usb-storage
[	4.793296] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[	4.802050] hub 2-0:1.0: USB hub found
[	4.806119] hub 2-0:1.0: 1 port detected
[	5.796008] init: - preinit -
[	8.133129] usb 2-1: new high-speed USB device number 2 using ci_hdrc
[	9.446359] mount_root: mounting /dev/root
[	9.485012] procd: - early -
[   10.204282] procd: - ubus -
[   11.221281] procd: - init -
[   15.709832] NET: Registered protocol family 10
[   15.740209] Initializing XFRM netlink socket
[   15.760289] NET: Registered protocol family 15
[   15.776470] tun: Universal TUN/TAP device driver, 1.6
[   15.781570] tun: © 1999-2004 Max Krasnyansky <[email protected]>
[   15.803585] gre: GRE over IPv4 demultiplexor driver
[   15.814010] ip_gre: GRE over IPv4 tunneling driver
[   15.914106] Linux video capture interface: v2.00
[   16.110804] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[   16.127672] cdc_acm 2-1:1.2: ttyACM1: USB ACM device
[   16.138344] cdc_acm 2-1:1.4: ttyACM2: USB ACM device
[   16.157738] cdc_acm 2-1:1.6: ttyACM3: USB ACM device
[   16.168713] cdc_acm 2-1:1.8: ttyACM4: USB ACM device
[   16.186422] cdc_acm 2-1:1.10: ttyACM5: USB ACM device
[   16.197099] cdc_acm 2-1:1.12: ttyACM6: USB ACM device
[   16.214259] usbcore: registered new interface driver cdc_acm
[   16.219961] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[   16.232191] usbcore: registered new interface driver cdc_wdm
[   16.245776] Loading modules backported from Linux version master-2015-03-09-0-g141f155
[   16.253854] Backport generated by backports.git backports-20150129-0-gdd4a670
[   16.342563] nf_conntrack version 0.5.0 (1958 buckets, 7832 max)
[   16.579268] usbcore: registered new interface driver usbserial
[   16.585573] usbcore: registered new interface driver usbserial_generic
[   16.592416] usbserial: USB Serial support registered for generic
[   16.642842] usbcore: registered new interface driver uvcvideo
[   16.648748] USB Video Class driver (1.1.1)
[   16.756563] xt_time: kernel timezone is -0000
[   16.765796] usbcore: registered new interface driver cdc_ether
[   16.795820] usbcore: registered new interface driver cdc_ncm
[   16.969096] cfg80211: Calling CRDA to update world regulatory domain
[   16.983645] cfg80211: World regulatory domain updated:
[   16.988835] cfg80211:  DFS Master region: unset
[   16.993317] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[   17.003189] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[   17.011231] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[   17.019362] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[   17.027480] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[   17.035600] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[   17.045200] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[   17.053401] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[   17.061444] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[   17.109012] ip_tables: © 2000-2006 Netfilter Core Team
[   17.497914] PPP generic driver version 2.4.2
[   17.515848] NET: Registered protocol family 24
[   17.531823] usbcore: registered new interface driver qmi_wwan
[   17.547926] usbcore: registered new interface driver rndis_host
[   17.623934] usbcore: registered new interface driver sierra
[   17.629875] usbserial: USB Serial support registered for Sierra USB modem
[   17.648773] usbcore: registered new interface driver sierra_net
[   17.672781] usbcore: registered new interface driver cdc_mbim
[   17.712612] usbcore: registered new interface driver option
[   17.718731] usbserial: USB Serial support registered for GSM modem (1-port)
[   17.836637] usbcore: registered new interface driver rt2800usb
[   31.671818] usb 2-1: USB disconnect, device number 2
[   78.463577] fec 800f0000.ethernet eth0: Freescale FEC PHY driver [sMSC LAN8710/LAN8720] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[   78.476950] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   80.463708] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   80.471767] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  141.283118] usb 2-1: new high-speed USB device number 3 using ci_hdrc
[  141.475515] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[  141.501149] cdc_acm 2-1:1.2: ttyACM1: USB ACM device
[  141.514332] cdc_acm 2-1:1.4: ttyACM2: USB ACM device
[  141.526840] cdc_acm 2-1:1.6: ttyACM3: USB ACM device
[  141.552503] cdc_acm 2-1:1.8: ttyACM4: USB ACM device
[  141.568859] cdc_acm 2-1:1.10: ttyACM5: USB ACM device
[  141.588001] cdc_acm 2-1:1.12: ttyACM6: USB ACM device
[  165.073014] 3g-3G: renamed from ppp0

Спасибо!

Изменено 20 января, 2016 пользователем vgovseychuk

[IgorKossak 0]

Ну и простыня dmesg (не нашел, как скрыть/свернуть, если знаете, научите)

Вместо тегов code используйте codebox (теги слева от поля редактирования текста).

[vgovseychuk 0]

Вместо тегов code используйте codebox (теги слева от поля редактирования текста).

Спасибо, поправил.

 

[shamrel 0]

Моя статья по теме:

Быстро поднятое не считается упавшим. Повышаем отказоустойчивость встраиваемых систем

 

Заодно и попиарюсь :1111493779:

Будут вопросы, пишите.

[alx2 0]

Интересует вопрос, как сделать возможным возврат системы к начальным настройкам (overlay)?

Если под начальными настройками подразумевается возврат всей системы в исходное состояние, в котором оно было выпущено с завода, то напрашивается вариант хранить rootfs дважды: первая копия записывается на заводе и никогда не модифицируется, вторая копия - рабочая. Для возврата к начальным настройкам вторая копия переписывается первой.

[shamrel 0]

Если под начальными настройками подразумевается возврат всей системы в исходное состояние, в котором оно было выпущено с завода, то напрашивается вариант хранить rootfs дважды: первая копия записывается на заводе и никогда не модифицируется, вторая копия - рабочая. Для возврата к начальным настройкам вторая копия переписывается первой.

Для этих целей придумали каскадно-объединенное монтирование. Идея следующая: создаем «виртуальный» раздел из двух физических разделов на носителе. Один раздел содержит образ rootfs, доступный только для чтения, а во время работы операционной системы все изменения заносятся во второй раздел, который доступен для чтения и записи. Для каскадно-объединенного монтирования разделов использована вспомогательная файловая система UnionFS, AUFS или OverlayFS.

В статье (ссылка в предыдущем сообщении) подробный пример и объяснение создание такого пирога по технологии AUFS.

 

Как уже говорилось выше, происходит объединение двух физических разделов. Первый раздел, в который изначально записан образ рабочей КФС, доступен только для чтения (RO – read only), второй раздел, изначально пустой, служит для хранения изменений, соответственно, он доступен как для чтения, так и для записи (RW – read write). В терминах aufs первый и второй разделы называются ветвями (branch). Объединение ветвей происходит в процессе монтирования. В результате операционная система видит смонтированную область как единое целое. Доступ к данным осуществляется драйвером ядра. Запросы на чтение файла драйвер в первую очередь направляет к RW ветви; если данные там присутствуют, то выдаются они, если там данных нет, то файл читается из ветви RO. При записи, данные попадают в ветвь RW. При удалении файла, в ветвь RW добавляется метка о том, что данный файл был удален (создается соответствующий пустой скрытый файл с определенным префиксом в названии). Физически файл остается в ветви RO целым. Такой подход позволяет избежать операций записи в разделе с критической информацией. Кроме того, так как ветвь RO доступна только для чтения, появляется принципиальная возможность добавить дополнительный контроль целостности данных. Реализовать это можно средствами UBIFS, сделав создаваемый раздел статическим. Статический раздел доступен только для чтения и данные там защищены контрольной суммой (CRC-32).

 

При необходимости отката, или в случае повреждения данных, просто форматируем раздел с ветвью RW.

[vgovseychuk 0]

Моя статья по теме:

Быстро поднятое не считается упавшим. Повышаем отказоустойчивость встраиваемых систем

 

Заодно и попиарюсь :1111493779:

Будут вопросы, пишите.

 

Спасибо, на первый взгляд это именно то, что нужно. Буду пробовать.

Изменено 21 января, 2016 пользователем vgovseychuk

[Tarbal 4]

Моя статья по теме:

Быстро поднятое не считается упавшим. Повышаем отказоустойчивость встраиваемых систем

 

Заодно и попиарюсь :1111493779:

Будут вопросы, пишите.

 

Спасибо. Интересно.

[alx2 0]

Будут вопросы, пишите.

Раз уж Вы все равно начали себя цитировать, :) то задам вопрос, хоть он и не имеет прямого отношения к откату к заводским настройкам.

 

Проблемы начались когда была изготовлена установочная партия, и устройства разошлись по отделам и КБ для создания прикладного ПО. Пошли возвраты с формулировкой: «Чего-то не загружается».

 

В ходе осмотра выяснилось, что в 100% случаях отказа повреждался раздел NAND с файловой системой (rootfs)

Интересно, каким образом удалось убить FS, просто отключая питание. Вы что, использовали нежурналируемую файловую систему?

[shamrel 0]

Интересно, каким образом удалось убить FS, просто отключая питание. Вы что, использовали нежурналируемую файловую систему?

 

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

Причины сбоев и потери информации в NAND

 

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

Отключение питания происходит в момент начала работы со страницей NAND. После перезагрузки, страница может быть прочтена корректно: считаются все единицы (0xFF), но иногда, после перезагрузки можно из этой области считать только нули. Кроме того, если потом опять записать эту страницу, иногда может возникнуть ошибка ECC. Причина – опять нестабильные биты.

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

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

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

 

P.S.: Чего-то спойлер не работает.

[MIKS 0]

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

 

Статья интересная. А если ТС в процессе работы нужно менять только конфиги то их можно хранить отдельно на spi-flash и монтировать mount --bind. (я полагаю какой то костыль придется делать при порче spi-flash дергать заводской конфиг из ro rootfs)

[alx2 0]

Причина может быть в нестабильных битах

Спасибо за ссылку. Возможная причина "умирания" FS понятна. Но, на мой взгляд, это особенность конкретной реализации, а не уязвимость журналирования как такового. Как мне кажется, ключевым моментом является то, что в рассмотренном примере при восстановлении после отказа питания решение о валидности записанных данных (или о чистоте стираемого блока) принимается на основании тестового чтения, а не на основании информации журнала.

 

Насколько я понимаю принцип работы журналирования (безотновительно UBIFS или какой-либо другой конкретной FS), при операции, допустим, стирания блока:

1. в журнал записывается информация о планируемой операции;

2. выполняется собственно стирание;

3. после успешного завершения операции запись в журнале уничтожается, а блок считается чистым.

 

Если в процессе выполнения п.2 отключилось питание, то при последующем старте файловая система читает журнал, видит, что операция стирания не была успешно завершена, и трактует блок как "грязный" (то есть требующий повторного стирания). Что читается из "грязного" блока, есть там нестабильные биты или нет, по идее, никого интересовать не должно...

 

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

 

Так что говорить "журнал - не панацея" без привязки к конкретной реализации я бы не стал...

Интересно, применяется ли аналогичный подход (принятие решения о валидности данных на основании контрольного чтения) в jffs2...

[shamrel 0]

Насколько я понимаю принцип работы журналирования (безотновительно UBIFS или какой-либо другой конкретной FS), при операции, допустим, стирания блока:

1. в журнал записывается информация о планируемой операции;

2. выполняется собственно стирание;

3. после успешного завершения операции запись в журнале уничтожается, а блок считается чистым.

 

....

Так что говорить "журнал - не панацея" без привязки к конкретной реализации я бы не стал...

Интересно, применяется ли аналогичный подход (принятие решения о валидности данных на основании контрольного чтения) в jffs2...

Согласен, реализация имеет огромное огромное значение. В данном случае проблема в ней.

Подлость "нестабильных" бит, в том, что при первом после сброса доступе они ведут себя адекватно. В результате транзакция будет закрыта. UBIFS имеет оптимистичный поход к данным, она доверяет проверке памяти. То-есть, например, захотела стереть блок, внесла пометку в журнал, начала стирать. Когда уже все стерла, но не "закрыла" LEB, отключается питание. И после перезагрузки, высмотрев в журнале незавершенное действие, файловая система сканирует это блок, видит, что там все единицы (то есть память стерта) и делает запись в журнал о счастливом завершении. Нет, чтоб, наивной еще разок стереть. А в результате может образоваться область нестабильных бит, последующая запись в которую, приведет к порчи данных.

Аналогично и при других операциях. UBIFS доверяет CRC и если все Ok, то не производит операцию повторно.

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

Разработчики знают о проблемах. Надуюсь на обновление.