请教NUC972+并口nand,丢系统文件问题。
本帖最后由 redworlf007 于 2021-5-14 18:38 编辑RT:
1、NUC972+并口nandflash,220V转12V的开关电源给板子供电。
2、系统;Linux,文件系统 yaffs2,整个nand是一个盘,未分区,里面移植了Python解释器2.7版本。
3、应用程序:Python写的程序,刷完系统,程序一次启动的时候,还会编译Python的一些库。
4、应用程序:每次开机会给etc/init.d/rcS 文件里面写一次ip地址。
5、应用程序:运行过程中,会写乱七八糟的日志,写入量未知。
6、应用程序:每次写flash后,没有调用sync命令。
问题:
1、现场反应:拉空开断电后,再上电,设备无法启动。
2、故障板子分析:
①、Linux系统可以启动,但是etc/init.d/ 下面的rcS文件丢失,导致无法配置ip地址,设备断网。
②、系统里面的Python的库文件及有些系统文件,有的会丢失。
概率:
1、最近出货的200套,有3块板子这样。
2、以往3年出货了也有200~300套,全部安装在现场,最近有5块板子这样,之前没有出现问题。
目前的解决方案:
1、设备第一次安装的时候,配置一次ip地址,以后每次开机,检测已经有ip地址,就不写rcs文件了,系统是内网设备,内网ip固定。
2、关闭应用程序写日志功能。
大家看看,这样能不能降低问题的概率?谢谢。
用squashfs+overlay吧 Himem 发表于 2021-5-14 18:32
用squashfs+overlay吧
好的,我搜下看。
新塘的bsp里面,有个ramfs,系统是只读的,然后割一点flash出来,作为可以读写区,是不是和你说的这个类似? 本帖最后由 Himem 于 2021-5-14 18:50 编辑
redworlf007 发表于 2021-5-14 18:35
好的,我搜下看。
新塘的bsp里面,有个ramfs,系统是只读的,然后割一点flash出来,作为可以读写区,是不 ...
差不多,
记得initramfs好像是完全加载到内存,squashfs不是这样压缩率也高些 Himem 发表于 2021-5-14 18:43
差不多,
记得initramfs好像是完全加载到内存,squashfs不是这样压缩率也高些 ...
好的,我试试看,应该是写flash的问题吧?我现在如果改成不写,应该问题会少很多吧。 1、现场反应:拉空开断电后,再上电,设备无法启动。
感觉像是掉电时写操作导致数据丢失,板上是否有电源监控芯片?比如MAX809S之类的
这种情况好像不好复现,提一个笨想法,可以做个供电控制板,模拟实际操作过程中掉电,
用一个MCU控制反复掉电来复现,同时产品板打印程序操作log,如果产品启动失败,
停止测试并提示查看log。 N_EMBED 发表于 2021-5-14 19:26
感觉像是掉电时写操作导致数据丢失,板上是否有电源监控芯片?比如MAX809S之类的
这种情况好像不好复现 ...
板子上没有电源监控芯片,我用那种可编程的的直流电源,不停的开关12V电源输出,拿了一块板子,没模拟出来。。。 redworlf007 发表于 2021-5-14 19:42
板子上没有电源监控芯片,我用那种可编程的的直流电源,不停的开关12V电源输出,拿了一块板子,没模拟出 ...
NUC972是用阻容复位方式吗?电源监控芯片的好处是监测到电压跌落到阈值电压就马上使芯片进入复位状态,防止芯片在掉电过程操作flash,如果没有,建议上一个 本帖最后由 redroof 于 2021-5-14 20:30 编辑
redworlf007 发表于 2021-5-14 19:42
板子上没有电源监控芯片,我用那种可编程的的直流电源,不停的开关12V电源输出,拿了一块板子,没模拟出 ...
我也试过。那个板子上有复位芯片,存储器是SPI NAND,然后用一个自己产品的继电器输出来控制它的电源,随机15秒到1分钟开关,最终一个星期后文件系统坏了。。。
不要问我坏在哪里,我不知道,坏了以后我就换方案了。
这个测试证明:只要是在运行的时候一直记数据库,然后再随机断它的电,就算有复位芯片,文件系统是号称最保险的YAFFS2,时间长一点也扛不住。。。。。 redroof 发表于 2021-5-14 20:24
我也试过。那个板子上有复位芯片,存储器是SPI NAND,然后用一个自己产品的继电器输出来控制它的电源,随 ...
没有ups的pc,这样操作应该也不行 可以参考openwrt的文件系统 fengyunyu 发表于 2021-5-14 20:53
没有ups的pc,这样操作应该也不行
YAFFS2自己的说明书,以及UBIFS自己的说明书,都明确的写了不怕异常掉电,保证异常掉电后文件系统自身不会坏。YAFFS2还特别注明了,掉电时写到一半的文件,写到哪里算哪里,保证已写入的部分是好的。
(我专门拷大文件然后断电测过确实如此,YAFFS2的结果文件长度只有前面一半,但前面一半是完全正确的。而UBIFS的结果文件长度是全长,但后一半内容是全0。
相比之下YAFFS2的处理更合理,因为数据库的写日志都是追加写的,没写完不要留下空洞更好)
然后sqlite数据库保证自己是先写日志后写数据内容,如果写完了日志然后数据写到一半掉电会通过日志恢复,或者如果连日志都没写完,就等于啥也没做。
这两个配合起来,最多就是掉电前最后一条数据丢失,怎么也不该弄的系统开不了机。
但实测结果并非如此。平均一天断电两千多次,第一天第二天都还好,最后好像是第5天坏掉了。。。 本帖最后由 dukelec 于 2021-5-14 23:15 编辑
redroof 发表于 2021-5-14 20:24
我也试过。那个板子上有复位芯片,存储器是SPI NAND,然后用一个自己产品的继电器输出来控制它的电源,随 ...
會不會復位芯片的觸發電壓對於 flash 芯片來說已經不安全?
我用 ubifs 沒有復位芯片,spi nand,時間久了會掉固件,有時是文件系統掛掉,有時是配置文件空了。
想想反正理論上配置文件空掉的問題無解(意外掉電或手動復位),最後就 rootfs read only,app、數據和配置放 data 分區,如果 data 分區壞掉,就觸發恢復出廠設置,app 版本也會恢復到出廠版本。
萬一因為各別配置文件或數據壞掉,或者升級 app 掛了,用戶還可以手動恢復一下出廠設置。
同樣,我搭了個電路,不停給目標板意外斷電(上電後等一段隨機時間,上電的時候會寫一次數據),也測不到。 如果硬件系统电路耗电很快,除了增加复位芯片,还可以考虑给供电电源增加输出电容,给芯片复位操作留有足够多的时间,比如加个220u以上的铝电容,如果高度受限,47u的陶瓷电容多并几个;另外关于复位芯片,如果在条件允许的情况下,换复位阈值电压更高的芯片,可以更快地进入复位状态。 N_EMBED 发表于 2021-5-14 20:09
NUC972是用阻容复位方式吗?电源监控芯片的好处是监测到电压跌落到阈值电压就马上使芯片进入复位状态,防 ...
是的,阻容复位,你用的啥电源监控芯片,推荐下。 redroof 发表于 2021-5-14 20:24
我也试过。那个板子上有复位芯片,存储器是SPI NAND,然后用一个自己产品的继电器输出来控制它的电源,随 ...
你说的那个spi nand是980的方案,这个方案我也做了,写日志,随便断电几次就丢系统文件,后来我加个一个sd nand专门存日志,解决问题了。 redworlf007 发表于 2021-5-14 23:58
你说的那个spi nand是980的方案,这个方案我也做了,写日志,随便断电几次就丢系统文件,后来我加个一个s ...
log写到tmpfs分区,也即写到内存里面。到达一定量后再整体转存到flash中,减少flash写入次数。 我开始也是测试了spi nand,后面果断换成nor了 aammoo 发表于 2021-5-15 00:05
我开始也是测试了spi nand,后面果断换成nor了
Nor 容量比较小吧?你用多大的? redworlf007 发表于 2021-5-14 23:55
是的,阻容复位,你用的啥电源监控芯片,推荐下。
我在用809S,比如MAX809s,IMP809S,S代表电压跌落到2.93V时复位。你也可以买些3.08V复位的芯片,测试看看那种更适合 redworlf007 发表于 2021-5-14 23:58
你说的那个spi nand是980的方案,这个方案我也做了,写日志,随便断电几次就丢系统文件,后来我加个一个s ...
我那个可不是几次就丢,而是接近一万次才丢。还差一点点我就要算它pass了。。。
在测试不够严格的地方几乎肯定会放它过的。
断电几次就丢肯定是你做的不对。
jetchenxg2021 发表于 2021-5-15 00:04
log写到tmpfs分区,也即写到内存里面。到达一定量后再整体转存到flash中,减少flash写入次数。 ...
我是记历史数据,不希望丢失,或者尽量少丢失。
按那些flash文件系统的说明书,我这样做应当是安全的。系统应当不会坏。 redroof 发表于 2021-5-15 08:52
我是记历史数据,不希望丢失,或者尽量少丢失。
按那些flash文件系统的说明书,我这样做应当是安全的。系 ...
能介绍一下什么更好的方案吗?YAFFS2,UBIFS我也测过,随机掉电也是会出问题,虽然概率比较小。目前我是把程序和数据分区存储了,实在撞上了数据丢了就丢了吧,系统不挂掉就行。 我也用的NUC972 NAND FLASH,YAFFS2+sqlite,不知道长期运行怎样,之前倒是电源芯片出现过问题,还特意请教过楼主,现在只能静观其变。 redroof 发表于 2021-5-15 08:50
我那个可不是几次就丢,而是接近一万次才丢。还差一点点我就要算它pass了。。。
在测试不够严格的地方几 ...
断电几次就丢,你要看你写日志的量有多大了,我们软件疯狂写日志,一天能把480M的sd nand写满再覆盖,这么大的写入量,实时给spi nand写,不丢才见鬼。 jameszxj 发表于 2021-5-15 09:21
能介绍一下什么更好的方案吗?YAFFS2,UBIFS我也测过,随机掉电也是会出问题,虽然概率比较小。目前我是把 ...
有没有试过把日志通过网络传走。 amxx 发表于 2021-5-15 09:35
我也用的NUC972 NAND FLASH,YAFFS2+sqlite,不知道长期运行怎样,之前倒是电源芯片出现过问题,还特意请教 ...
电源芯片啥问题?我记不起来了。 N_EMBED 发表于 2021-5-14 23:49
如果硬件系统电路耗电很快,除了增加复位芯片,还可以考虑给供电电源增加输出电容,给芯片复位操作留有足够 ...
增加电容根本不行,我加了法拉电容都不行,arm linux太费电了。 redworlf007 发表于 2021-5-15 09:48
增加电容根本不行,我加了法拉电容都不行,arm linux太费电了。
如果掉电太快了,是外设耗电还是本身小系统的工作电流都很大?首先增加复位芯片看看有没有改善,另外想别的办法让小系统掉电慢一些,让芯片尽可能快地在低于3V之前进入复位状态 N_EMBED 发表于 2021-5-15 09:58
如果掉电太快了,是外设耗电还是本身小系统的工作电流都很大?首先增加复位芯片看看有没有改善,另外想别 ...
我的板子上的3.3V是972和外设共用的,所以掉电快,要想掉电慢,要972一套电源,外设一套电源,电路复杂很多,我先看看复位芯片吧。已经出货的板子,我打算把写flash的操作都关闭,看看问题能不能减少。 建议找个板子按下图做测试,用个二极管将外设的5V和给972芯片供电LDO隔开,按理如果当外部掉电了,电容Cin和Cout的存电只留个最小系统用,复位芯片就有足够多的时间让972进入复位状态,不再操作FLASH。
我们设计的一款,用了30发的电容,断电后, 可以运行1分钟以上。 这种系统要加掉电中断处理才行,让cpu提前一点时间知道系统要掉电,然后处理一下 wenming 发表于 2021-5-15 12:29
我们设计的一款,用了30发的电容,断电后, 可以运行1分钟以上。
电容哪里买的,多少钱一个? redworlf007 发表于 2021-5-15 16:12
电容哪里买的,多少钱一个?
台湾的。不仅是电容,还有充放电电路,总共成本40到50吧。 wenming 发表于 2021-5-15 16:20
台湾的。不仅是电容,还有充放电电路,总共成本40到50吧。
30F的电容,上电得慢慢充。有啥资料推荐么?我看看充放电电路咋搞,谢谢。 redworlf007 发表于 2021-5-15 00:16
Nor 容量比较小吧?你用多大的?
我的系统比较小,16M的
运行在内存里,只有配置文件写入flash 我在一个lora网关上频繁历史数据记录和写日志,用的EMMC存储器件+EXT4或者3,我忘记了,当时没有测试频繁上下电对文件系统的破坏性如何,小批量产品运行2年了没有问题,不过看到楼主说的问题,心里还是怕怕的,高手评估下我这个组合稳定性怎么样? wx-ta 发表于 2021-5-16 16:45
我在一个lora网关上频繁历史数据记录和写日志,用的EMMC存储器件+EXT4或者3,我忘记了,当时没有测试频繁上 ...
你看看你的EMMC存储器件里面有没有自带掉电管理 redworlf007 发表于 2021-5-17 10:28
你看看你的EMMC存储器件里面有没有自带掉电管理
ext4 要比yaffs2优秀 三年模拟 发表于 2021-5-17 12:02
ext4 要比yaffs2优秀
这俩完全不一样的啊,没有可比性。yaffs2或者ubifs是用于裸flash的文件系统,自带坏块管理,磨损平衡这些。
ext4是普通硬盘的文件系统,不能用于裸flash。
你是哪种硬件就只能用对应的文件系统,不能混用的。 wenming 发表于 2021-5-15 16:20
台湾的。不仅是电容,还有充放电电路,总共成本40到50吧。
这种法拉电容,出问题的时候,是不是会炸?如果后面有短路。 redworlf007 发表于 2021-5-17 13:06
这种法拉电容,出问题的时候,是不是会炸?如果后面有短路。
我这边没发现过问题。 redworlf007 发表于 2021-5-17 13:06
这种法拉电容,出问题的时候,是不是会炸?如果后面有短路。
我们测试过,法拉电容短路过流几乎不会炸(偶有膨胀现象),过压或者反接极性有很大可能会炸,具体特性和电解电容很像 wenming 发表于 2021-5-18 08:50
我这边没发现过问题。
好,我试试看,我用在危爆场所,怕这个会有安全问题。。。 redworlf007 发表于 2021-5-15 09:48
增加电容根本不行,我加了法拉电容都不行,arm linux太费电了。
你是不是用的那种钮扣形的法拉电容 ?那种内阻大电流小带不动的。要用记录仪用的那种直插式的法拉电容才行,可以带挺长时间啊,记录仪那么大屏幕都可以挺一分钟 goodjob2 发表于 2021-5-19 13:51
你是不是用的那种钮扣形的法拉电容 ?那种内阻大电流小带不动的。要用记录仪用的那种直插式的法拉电容才 ...
我用的是直插的那种,估计我外设电路功耗太大了。。。 redroof 发表于 2021-5-17 12:58
这俩完全不一样的啊,没有可比性。yaffs2或者ubifs是用于裸flash的文件系统,自带坏块管理,磨损平衡这些 ...
你的nuc980的板子,最后用的啥flash?系统用的ramfs么? redworlf007 发表于 2021-5-20 13:14
你的nuc980的板子,最后用的啥flash?系统用的ramfs么?
后来我没再用了,换成IMX6了 redroof 发表于 2021-5-20 14:09
后来我没再用了,换成IMX6了
imx6你买的核心板么? redworlf007 发表于 2021-5-20 14:41
imx6你买的核心板么?
是的。
我选的myir的核心板 redroof 发表于 2021-5-20 14:47
是的。
我选的myir的核心板
我想起来一个事情,最近出现问题的货,贴的是新塘新升级的972是df61y,内部的ddr换了,以前没问题的板子上贴的是旧型号,df62y,不知道和这个有没有关系,nand flash是嘉立创买的,这玩意不应该是翻新货吧。 我们另外的200套设备,其中3块板子,出了丢文件的问题,客户给设备的220V供电上,装了这个稳压电源,然后现在暂时没出问题。。。 redroof 发表于 2021-5-20 14:47
是的。
我选的myir的核心板
你的imx6,写数据的时候掉电会丢东西么?并口nand么? dukelec 发表于 2021-5-14 23:08
會不會復位芯片的觸發電壓對於 flash 芯片來說已經不安全?
我用 ubifs 沒有復位芯片,spi nand,時間久 ...
你好请教下,你的系统rootfs read only,是怎么把app区和data恢复出厂的,通过网络么? redworlf007 发表于 2021-5-25 08:46
你的imx6,写数据的时候掉电会丢东西么?并口nand么?
并口nand,目前看来不会 redroof 发表于 2021-5-25 08:59
并口nand,目前看来不会
啥原理不丢数据?cpu跑得快? redworlf007 发表于 2021-5-25 09:00
啥原理不丢数据?cpu跑得快?
不知道。或许可以解释为跑的快了碰上那个特定的会丢数据的时间点的概率就小了。
名义上那些flash文件系统都保证任意时候掉电不会坏,实际估计在某些特定的点上是防不住的。所以你的问题就变成了概率性问题。 redworlf007 发表于 2021-5-25 09:00
啥原理不丢数据?cpu跑得快?
之前我测980已经很接近我的通过标准(1万次)了,只差一点点而已。我很怀疑如果运气改变一点点,就被放过了{:titter:}
redroof 发表于 2021-5-25 10:10
之前我测980已经很接近我的通过标准(1万次)了,只差一点点而已。我很怀疑如果运气改变一点点,就被放过 ...
我发现有一批nuc972+并口nand,咋写rcs或者日志掉电都没发现丢东西,最近的一批,开机给rcs写一次ip,平时写日志,出问题的板子rcs要么丢了,要么文件空,概率很大……搞不定了……目前救急的办法,把所有写的操作都关闭,rcs文件不给写权限……我打算搞ramfs+yaffs2了……同一个nand flash,分两个区,异常断电会损坏别的分区么?就是yaffs2分区写日志,异常断电,会损坏ramfs分区么? redworlf007 发表于 2021-5-25 08:48
你好请教下,你的系统rootfs read only,是怎么把app区和data恢复出厂的,通过网络么? ...
只有兩個區:1. 系統; 2. app + data
app + data 出廠不燒錄,只是擦除。
app + data 內容物打成 tar 包放在系統區,系統區開機會掛載 app + data 分區,如果掛載失敗,或者啓動 app 失敗,或者檢測到用戶通過按鍵恢復出廠,就格式化 app + data 分區,然後把 tar 包內容釋放到 app + data 分區。 dukelec 发表于 2021-5-25 11:06
只有兩個區:1. 系統; 2. app + data
app + data 出廠不燒錄,只是擦除。
那你这个系统区就比较大了,我的看门狗只有8秒最长时间,我的系统区不能太大,要保证8s内可以挂载完成启动,然后喂狗,应用程序是用Python写的,我感觉我得把Python解释器、ssh、应用程序备份放到一个单独的分区,应用程序再一个单独的分区,感觉好复杂…… 本帖最后由 dukelec 于 2021-5-25 11:31 编辑
redworlf007 发表于 2021-5-25 11:20
那你这个系统区就比较大了,我的看门狗只有8秒最长时间,我的系统区不能太大,要保证8s内可以挂载完成启 ...
系統區大小和掛載啓動時間又沒關係。
我的板子從上電到 app 啓動,一共 4 秒。
app 是 shell 腳本寫的。python 啓動太慢了。 dukelec 发表于 2021-5-25 11:27
系統區大小和掛載啓動時間又沒關係。
我的板子從上電到 app 啓動,一共 4 秒。
我试了下,yaffa2的文件系统,系统越大,挂载时间越长……ramfs read only我不知道系统越大是不是挂载越慢…… dukelec 发表于 2021-5-25 11:27
系統區大小和掛載啓動時間又沒關係。
我的板子從上電到 app 啓動,一共 4 秒。
你咋样把uboot的启动时间缩短的?你用的啥片子? 本帖最后由 dukelec 于 2021-5-25 12:37 编辑
redworlf007 发表于 2021-5-25 11:42
你咋样把uboot的启动时间缩短的?你用的啥片子?
君正 x1021
君正對啓動速度有優化
君正同事之前最短能 1 秒多點從上電到 shell 環境 ready
我覺得 4 秒啓動到 app 夠用,沒有用他們極度快速版本,自己稍微優化了下啓動速度,最簡單有效的優化是提升串口調試的波特率,我設置到 3Mbps(FT232R 支持的最高波特率),然後是不用的服務刪掉。
uboot 的啓動倒計時關掉,直接啓動。
x1021 主頻 800MHz 左右,試過標準版 python,腳本每次運行時,加載要很久很久,感覺要半分鐘,可能是沒有裁剪的緣故。。。你用的是標準 python3 還是 micro python?
順便一提,ubifs 主流上已經取代 yaffs2 了。你說的分區越大掛載越慢好像是 yaffs2 才有的特性。 dukelec 发表于 2021-5-25 11:50
君正 x1021
君正對啓動速度有優化
Python2.79,从系统上电到应用程序启动,得个一两分钟……我看看新的文件系统。 根文件系统和数据区肯定要分区啊,一般根文件系统都要做成只读的,数据区可读写就行了 dso_2012 发表于 2021-5-29 08:26
根文件系统和数据区肯定要分区啊,一般根文件系统都要做成只读的,数据区可读写就行了 ...
我最近做了新的文件系统,ramfs+yaffs2,ramfs启动后,开始喂狗,然后挂在yaffs2的一个盘,我打算搞两个yaffs2的盘,一个盘里面是备份的系统,一个盘里面是应用程序区。 用python在972上开发,这个片子顶得住吗?用C/C++不香吗 jetchenxg2021 发表于 2021-5-29 23:31
用python在972上开发,这个片子顶得住吗?用C/C++不香吗
勉强能用把,反正启动特别慢,沙雕要这么玩,我有啥办法,ps我是硬件工程师。 redworlf007 发表于 2021-5-29 22:15
我最近做了新的文件系统,ramfs+yaffs2,ramfs启动后,开始喂狗,然后挂在yaffs2的一个盘,我打算搞两个y ...
我的imx6板子,断电测试已经做到几千次了,一切正常。
测试方法: 一秒钟写5条数据库,从系统开机完成之前5秒开始,20秒内随机时间断电。下次上电后读取之前最后一条记录号继续累加。
就一个ubifs分区,系统和数据库都放在一起。硬件有自己的掉电预警信号但并没有使用。看来imx6原厂的默认做法已经足够了。。。 redroof 发表于 2021-5-31 18:27
我的imx6板子,断电测试已经做到几千次了,一切正常。
测试方法: 一秒钟写5条数据库,从系统开机完成之前 ...
估计是imx6的跑的快,丢东西概率小,但是从原理上来说,还是会丢东西的。
972也不是每批的板子都会丢,看批次,不知道啥原因。。。感觉还是得搞个备份区。。。以防万一。。。 本帖最后由 redroof 于 2021-5-31 19:42 编辑
redworlf007 发表于 2021-5-31 19:25
估计是imx6的跑的快,丢东西概率小,但是从原理上来说,还是会丢东西的。
972也不是每批的板子都会丢,看 ...
我又焊了个板子,准备长期放着做掉电测试了,
做个几万次。看能不能见到搞坏文件系统的时候
原则上说,如果文件系统和底层驱动一切都正确,就是不该丢东西。他们设计的是允许任意掉电的。断电时刻正在写的那一条数据算作没写就是了。
文件系统自身做到断电不破坏自身,最多只破坏断电时候正在写的那一点数据。
数据库做到断电时候正在写的那一条数据或者可以在下次上电后重做,或者算作啥也没做 redroof 发表于 2021-5-31 19:28
我又焊了个板子,准备长期放着做掉电测试了,
做个几万次。看能不能见到搞坏文件系统的时候
Flash是先读出一个块,在内存里面修改好,再擦掉一个块,再写入。
擦掉那个块后,没写入,或者写了一半,没电了,不就丢东西,这种物理上的缺陷,啥文件系统也不能弥补吧。 redworlf007 发表于 2021-5-31 21:55
Flash是先读出一个块,在内存里面修改好,再擦掉一个块,再写入。
擦掉那个块后,没写入,或者写了一半 ...
当然能,它们自带这种情况的处理。你看yaffs2或者ubifs的代码分析就知道了。
简单来说,改写已有的数据实际上是新写了另一块数据在逻辑上代替旧的,旧的没擦,所以这个写如果没完成就掉电了,下次上电旧的还在。
不可能实现为先擦旧的再写新的,不然新的旧的都没了,那么你只要是修改文件系统的时候掉电必死。没人那么笨的。
实际上就算是做的不够好的文件系统,也要掉电很多次才能碰上丢一次数据。 redroof 发表于 2021-5-31 23:04
当然能,它们自带这种情况的处理。你看yaffs2或者ubifs的代码分析就知道了。
简单来说,改写已有的数据实 ...
那972丢文件,只能解释为写入的特别频繁,并且每次写的也不少,按你这么说yaffs2不应该丢东西啊。 redworlf007 发表于 2021-6-1 00:05
那972丢文件,只能解释为写入的特别频繁,并且每次写的也不少,按你这么说yaffs2不应该丢东西啊。 ...
谁知道呢。。。
yaffs2的代码本身应该没问题,但他依赖于底层新唐写的flash驱动程序啊,谁知道写flash驱动的人有没有测过所有情况。
上层也可以换ubifs,但底层你没法改。
redworlf007 发表于 2021-6-1 00:05
那972丢文件,只能解释为写入的特别频繁,并且每次写的也不少,按你这么说yaffs2不应该丢东西啊。 ...
文件系统自身的日志只保护自身结构,不保护文件内容。如果你没用数据库日志系统之类的,那么最后一次写的数据会丢。对某些类型的数据文件来说,不完整的数据文件相当于该文件坏掉了。
但是,只要你当时不是在改系统的关键文件,整个系统不该因此而开不了机。我以前测980的时候就是只写我自己的数据库文件,不会去改系统文件,所以最后弄的开不了机了就是没道理的。 window系统直接断电,也有概率损坏系统文件 fengyunyu 发表于 2021-6-1 07:57
window系统直接断电,也有概率损坏系统文件
windows的文件系统不是专门为flash设计的,没有可比性。 redroof 发表于 2021-6-1 07:45
文件系统自身的日志只保护自身结构,不保护文件内容。如果你没用数据库日志系统之类的,那么最后一次写的 ...
我遇到的问题是文件系统里面的rcs文件没了,或者文件里面是空的,还有应用程序的日志文件变成空的了,但是Linux系统能正常启动的。 redworlf007 发表于 2021-6-1 10:42
我遇到的问题是文件系统里面的rcs文件没了,或者文件里面是空的,还有应用程序的日志文件变成空的了,但 ...
rcs文件你写了没?
如果你会写入这个文件,那么掉电的时候这个文件变空是有可能的。比如写这个文件的写法是先把它清空,然后写入新的数据,那么刚执行完清空命令就掉电,当然这个文件就空了
本帖最后由 redroof 于 2021-6-1 11:25 编辑
redworlf007 发表于 2021-6-1 10:42
我遇到的问题是文件系统里面的rcs文件没了,或者文件里面是空的,还有应用程序的日志文件变成空的了,但 ...
其实,你想保证原子化的修改一个文本文件,都不是一件容易的事。即使底层已经替你保证了文件系统自身结构的原子化修改,你只要管文件内容。
所以一般都建议用数据库来存数据,而不是自己写的自定义格式的文件。这样对文件内容的原子化修改就由数据库替你正确的做到了 redroof 发表于 2021-6-1 10:52
rcs文件你写了没?
如果你会写入这个文件,那么掉电的时候这个文件变空是有可能的。比如写这个文件的写法 ...
rcs 软件每次开机写的了一次ip配置,我突然想到新塘972的片子升级型号了,我还用的以前型号上的内核驱动,我感觉新的片子里面驱动是不是改了……因为以前出货两三年的板子,都没这个问题,我升级内核试试。 redroof 发表于 2021-6-1 11:18
其实,你想保证原子化的修改一个文本文件,都不是一件容易的事。即使底层已经替你保证了文件系统自身结构 ...
我现在把所有写rcs和写日志的功能都关闭,应该随便咋断电,丢文件应该就不会丢了吧? redroof 发表于 2021-6-1 11:18
其实,你想保证原子化的修改一个文本文件,都不是一件容易的事。即使底层已经替你保证了文件系统自身结构 ...
昨天我拿回来一个现场故障板子,rcs启动文件里面是空的,我尝试把rcs里面的信息写回去,让系统启动,我发现写上信息后,无法保存。
我df -a查了下flash空间,居然100%,出厂前系统剩余空间大概99M左右。
于是,我开启ssh服务,然后用scp连上,我进入到应用程序目录下,把文件按大小排列,我在Python目录下面,找到一个98.5M的文件,打开以后看到是Python日志文件。
我把这个文件拷贝到电脑上,从板子上删除,然后把rcs里面信息写好,reboot,系统正常启动。
为了复现这个问题:
1、我拿了一块新的板子,烧录好了出厂系统,我把那个98.5M的Python日志文件拷贝到对应的Python目录下面,然后reboot,系统正常启动,应用程序正常启动,运行一会,应用程序报错,Python提示空间不足(Python运行过程中估计要写一些临时文件),然后我reboot,然后奇迹就出现,rcs文件里面变空了,应用程序起不来,我拿了两块板子试,100%复现。
我怀疑是flash空间的满了,系统重启的时候,要给rcs里面写ip地址,Python打开rcs,把rcs清空后,无法写入,然后rcs里面就变空。
我远程了几个正常运行的设备,发现正常运行的设备,flash空间一直和出厂的一样,还不知道具体啥问题。。。
(ps:我是硬件工程师) redworlf007 发表于 2021-6-5 12:40
昨天我拿回来一个现场故障板子,rcs启动文件里面是空的,我尝试把rcs里面的信息写回去,让系统启动,我发 ...
所以问题就找到了呗。就是你的日志占满了flash空间,结果你要修改系统文件写不进去了
这不是文件系统的错误,是你自己使用的错
真正你清空rcs文件到写入新内容中间断电丢失数据的概率应该是非常低的,估计除非你专门做断电试验不然是见不到那种情况的。
我手上那个IMX6的板子断电也够1万次了,还是一切正常。还在继续进行断电试验
重拾信心,哈哈哈 redroof 发表于 2021-6-5 14:06
所以问题就找到了呗。就是你的日志占满了flash空间,结果你要修改系统文件写不进去了
这不是文件系统的错 ...
我排查这个问题很久了,我们软件硬说程序没改过,程序没问题…… redworlf007 发表于 2021-6-5 15:53
我排查这个问题很久了,我们软件硬说程序没改过,程序没问题……
你说系统硬盘不对,如果还能进系统,进去后当然该先看看硬盘空间是不是满了啊。如果硬盘满了肯定会冒岀一大堆怪问题。
我也试过IMX6的硬盘满的情况,这个时候我的sqlite会记入一大堆旧数据。原因未知。但是硬盘重新有空间了能自动恢复,整个数据库文件不会坏 redroof 发表于 2021-6-5 19:23
你说系统硬盘不对,如果还能进系统,进去后当然该先看看硬盘空间是不是满了啊。如果硬盘满了肯定会冒岀一 ...
你把硬盘塞满,然后让系统继续写数据,然后通断电,这样试试看,会不会出问题。 redworlf007 发表于 2021-6-5 22:55
你把硬盘塞满,然后让系统继续写数据,然后通断电,这样试试看,会不会出问题。 ...
我在imx6上试过啊,拷几个大文件把硬盘占满,然后写数据库的程序会报错,但系统本身不会有问题。因为我没事不会改系统文件。多重启两次也没事,那个测试程序一直报错但系统不会坏。
等我把占位置用的几个大文件删了,再重启,就一切正常了,数据库文件不会坏,岀错前记的内容还在,还可以接着往里记。
我对这个结果很满意了,可以放心的写应用程序了 redroof 发表于 2021-6-5 23:27
我在imx6上试过啊,拷几个大文件把硬盘占满,然后写数据库的程序会报错,但系统本身不会有问题。因为我没 ...
明白你的意思了,你的应用程序,没有操作系统文件,所以系统不会有问题。
页:
[1]