lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Feb 2015 10:09:45 -0500 (EST)
From:	Rodrigo Freire <rfreire@...hat.com>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	Jörn Engel <joern@...fs.org>,
	linux-mtd@...ts.infradead.org, Felix Fietkau <nbd@...nwrt.org>,
	dwmw2@...radead.org, linux-kernel@...r.kernel.org,
	Herton Krzesinski <hkrzesin@...hat.com>
Subject: Re: [PATCH V2] mtd: block2mtd: Present block2mtd timely on boot
 time

From: "Brian Norris" <computersforpeace@...il.com> 
Sent: Wednesday, November 26, 2014 1:33:04 AM 
Subject: Re: [PATCH V2] mtd: block2mtd: Present block2mtd timely on boot time 

> On Sun, Nov 09, 2014 at 07:18:05AM -0500, Rodrigo Freire wrote: 
> > > From: "Brian Norris" <computersforpeace@...il.com> 
> > > Sent: Wednesday, November 5, 2014 6:23:03 PM 
> > 
> > > This still seems like a bad idea (using a block device + block2mtd + 
> > > JFFS2). Why are you doing this? See comments here: 
> > > http://www.linux-mtd.infradead.org/faq/jffs2.html#L_hdd_jffs2 
> > 
> > As Felix stated on a previous message to the thread, I am using JFFS2 over 
> > block2mtd where regular filesystems failed to do so well. There are several
> > [1] threads pointing this issue, and JFFS2 over block2mtd works like a 
> > charm 
> > on more harsh scenarios. 
> [...] 
> > [1] - http://bit.ly/1smGvwa 

> OK, so there are definitely problems with cheap SD card power cut 
> tolerance. That's not news. But that doesn't mean block2mtd + JFFS2 is a 
> good solution. In fact, when I add 'jffs2' to your Google search query 
> of 'raspberry pi corrupt sd card', the only mentions I see are those who 
> agree that this is not the right choice. 

> But anyway, we can look at supporting block2mtd (since you provided the 
> patches), even if we don't agree how it should be used. And in fact, I 
> might argue there are no good (production) uses for block2mtd, so I 
> suppose I don't have much stake in it :) 

Hi there Brian, 

This patchset primarily aims to fix a block2mtd behavior, and not introduce
new features (well, the device name and a timeout option are indeed new
options, but they're actually enhancements). block2mtd already exists, works
 nicely as boot root device on several architectures, but fails on BCM2835
arch. Our patchset only aims to get it fixed. We just want to block2mtd work
on BCM2835 the way it works on different architectures. So, this is a fix. 

As a side note, WRT the SD card corruption; it also happens on good quality
SD cards too. The main culprit for the corruption is bad mains / power supply
issues / abrupt poweroff. And there's also the wear leveling...

Thanks for the thorough review. 

Looking forward for the ACK ;-) 

My best regards, 

- RF. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ