From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: superblock checksum mismatch after crash, cannot mount
Date: Mon, 25 Aug 2014 07:42:38 -0400 [thread overview]
Message-ID: <53FB212E.8070208@gmail.com> (raw)
In-Reply-To: <401C8BD0-BE70-4FDF-A37A-D65D131E8843@colorremedies.com>
[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]
On 2014-08-24 15:48, Chris Murphy wrote:
>
> On Aug 24, 2014, at 10:59 AM, Flash ROM <flashromguru@yandex.com> wrote:
>> While it sounds dumb, this strange thing being done to put partition table in separate erase block, so it never read-modify-written when FAT entries are updated. Should something go wrong, FAR can recover from backup copy. But erased partition table just suxx. Then, FAT tables are aligned in way to fit well around erase block bounds.
>
> I think you seriously overestimate the knowledge of camera manufacturer's about the details of flash storage; and any ability to discover it; and any willingness on the part of the flash manufacturer to reveal such underlying details. The whole point of these cards is to completely abstract the reality of the underlying hardware from the application layer - in this case the camera or mobile device using it.
>
If you really know what you are doing, it is possible to determine erase
block size by looking at device performance timings, with surprisingly
high accuracy (assuming you aren't trying to have software do it for
you). I've actually done this before on several occasions, with nearly
100% success.
> Also, with SDXC exFAT is now specified. And it has only one FAT there isn't a backup FAT. So they're even more difficult to recover data from should things go awry filesystem wise.
>
It's too bad that TFAT didn't catch on, as it would have been great for
SD cards if it could be configured to put each FAT on a different erase
block.
>
>> This said, you can *try* to reformat, BUT no standard OS of firmware formatter will help you with default settings. They can't know geometry of underlying NAND and controller properties. There is no standard, widely accepted way to get such information from card. No matter if you use OS formatter, camera formatter or whatever. YOU WILL RUIN factory format (which is crafted in best possible way) and replace it with another, very likely suboptimal one.
>
> It's recommended by the card manufacturers to reformat it in each camera its inserted into. It's the only recommended way to "erase" the sd card for re-use, they don't recommend selectively deleting images. And it's known that one camera's partition table and formatting can irritate another camera make/model if the card isn't reformatted by that camera.
>
It's not just cameras that have this issue, a lot of other hardware
makes stupid assumptions about the format of media. The first firmware
release for the Nintendo Wii for example, chocked if you tried to use an
SD card with more than one partition on it, and old desktop versions of
Windows won't ever show you anything other than the first partition on
an SD card (or most USB storage devices for that matter).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]
next prev parent reply other threads:[~2014-08-25 11:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-24 16:59 superblock checksum mismatch after crash, cannot mount Flash ROM
2014-08-24 18:41 ` Florian Gamböck
2014-08-24 19:48 ` Chris Murphy
2014-08-25 11:42 ` Austin S Hemmelgarn [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-08-22 22:00 Florian Gamböck
2014-08-22 22:17 ` Florian Gamböck
2014-08-23 5:27 ` Duncan
2014-08-23 8:38 ` Florian Gamböck
2014-08-23 9:34 ` Duncan
2014-08-23 14:14 ` Florian Gamböck
2014-08-24 20:29 ` Chris Murphy
2014-08-23 16:38 ` Zygo Blaxell
2014-08-24 0:56 ` Duncan
2014-08-24 2:57 ` Chris Murphy
2014-08-24 11:08 ` Leen Besselink
2014-08-24 12:49 ` Chris Samuel
2014-08-24 12:59 ` Duncan
2014-08-24 14:09 ` Florian Gamböck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FB212E.8070208@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).