On Sunday, August 09, 2015 9:31:37 AM meino.cra...@gmx.de wrote:
> Fernando Rodriguez <frodriguez.develo...@outlook.com> [15-08-08 05:42]:
> > On Friday, August 07, 2015 7:01:29 PM Mick wrote:
> > > On Friday 07 Aug 2015 04:27:15 Fernando Rodriguez wrote:
> > > > On Thursday, August 06, 2015 6:18:59 PM meino.cra...@gmx.de wrote:
> > > > > Hi,
> > > > >
> > > > > for my tablet PC I used a used 32GB FAT32 formatted SDcard. The
> > > > > formatting was already done by the manufacturer.
> > > > > Then I screwed it up and had to do the partioning and formatting
> > > > > myself again. "No big deal", I thought -- and was wrong.
> > > > > Yes, the "thing" I got could be read and written. But it was
> > > > > DAMN slow in comparison to the original formatting.
> > > > >
> > > > > I googled and found a description, which described exactly,
> > > > > what I wanted: An optimal formatting for one big FAT32 partion.
> > > > > I did it again ;) and: TADA! The speed was back.
> > > > > LINK:http://zero1-st.blogspot.de/2012/05/formatting-fat32-volumes-larger->
> > > > > > than.html
> > > > >
> > > > > Now I need the something identical but explained in a way
> > > > > that it can be successfully applied to any partion layout
> > > > > and any SDcard size.
> > > > > Currently the new SDcard has 64GB (yes, the tablet eats that size
> > > > > well :) and needs at least two partions: One FAT32 and one ext4.
> > > > > May be that I need a different layout later.
> > > > >
> > > > > To what aspect and "logic" do I have to keep my eyes on, when
> > > > > it comes partioning/formatting any SDcard size with any partion
> > > > > layout and any filesystem?
> > > > >
> > > > > Thank you very much in advance for any help!
> > > > > Best regards,
> > > > > Meino
> > > >
> > > > I wrote a long reply to this and it appears to have been swallowed by
> > > > /dev/null.
> > > >
> > > > SD cards don't have 128K blocks. Except for the very early ones
(standard
> > > > capacity), they are divided in allocation units (AU) that are 1MB to
4MB
> > > > for SDHC and even larger for SDXC. The only way to get that value is
by
> > > > reading a register in the card (so you can't do it in usermode on
linux).
> > > >
> > > > The AUs are divided into Recording Units (RUs). The size of these can
be
> > > > deduced from the card speed class (that's the number inside the C on
the
> > > > label), and the card capacity. For class 2 and 4 if the card is less
than
> > > > 1GB it's 16KB, otherwise it's 32KB. For class 6 it is 64KB, and for
class
> > > > 10 it's 512KB.
> > > >
> > > > After an AU is erased you can write to any of the free RUs in any
order in
> > > > blocks of 512 bytes sequentially (the block size is configurable by the
> > > > driver but 512 is the most common). But if you write to a nonfree RU
then
> > > > all non- free RU get copied to a new AU. So the performance hit
depends on
> > > > how many non-free RUs are in the AU when this happens.
> > > >
> > > > So to get the best performance you need to align the first FAT cluster
on
> > > > an AU boundary and that the RUs used by the reserved sectors after the
FAT
> > > > are free. This is not so easy from usermode because you can't get the
AU
> > > > size and you can't erase the AU to make sure reserved sectors are
free.
> > > > The Windows 7 and later format utility will do it if you don't
partition
> > > > the card. The next best thing is to align it to an RU which should be
> > > > pretty easy.
> > > >
> > > > You could guess the AU size by writting blocks of RU size from the
start
> > of
> > > > the card and timing it. Every time you hit the AU boundary there will
be a
> > > > longer delay.
> > > >
> > > > For more details see the SD specification (chapter 4.13).
> > > >
> > > > https://www.sdcard.org/downloads/pls/
> > > >
> > > > They also have formatter tools for Windows and OSX. I tried the
Windows
> > > > version years ago but had problems with it (can't remember what).
> > >
> > > Excellent information Fernando, thank you!
> > >
> > > So there is no tool for me to use to read the AU/RU on the chip?
> > >
> > >
> >
> > The RU can be calculated from the card size and speed class, that's the
number
> > printed on the card label inside the C. I don't know of any tools to get
the
> > AU and it looks like it's not exported to userspace so any such tool would
> > have to guess it. However, if you want to hack your kernel all it takes is
one
> > line on /usr/src/linux/drivers/mmc/core/debugfs.c. Add the following
towards
> > the end of mmc_ios_show before the return statement:
> >
> > seq_printf(s, "au (sectors):\t%u\n", host->card->ssr.au);
> >
> > then you can do:
> >
> > cat /sys/kernel/debug/mmc0/ios
> >
> > Multiply the value by 512 to get the size in bytes. It can be up to 64MB.
> >
> >
> >
>
>
> Hi Fernando,
>
> I looked into the kernel ... but ... hmmmm ...
> for me it seems this is only for onboard mmc flash...
> which is often found on embedded linux boards.
> Or am I wrong?
> I am using a micro sdcard in a sdcard-reader plugged
> into an USB port of my Linux PC.
> (Later it will be inserted into the sdcard slot of
> my tablet PC...)
> I am asking just to prevent to make things screwed up.
>
> Have a nice sunday! :)
> Best regards,
> Meino
They use the same driver. The first SD cards where just MMC with a different
form factor. The SD specification added optional password protection and I
think DRM extensions to MMC (it stands for Secure Digital) but few cards ever
implemented those.
Does your card gets detected as mmcblkX? If it's detected as something else
then maybe the card reader that you're using presents the card to the OS as a
USB Mass Storage Device, If that's the case you'll need to use a different
reader. It may also skew your flashbench results.
You should actually make it:
if (host && host->card && host->card->ssr)
seq_printf(s, "au (sectors):\t%u\n", host->card->ssr.au);
So that you don't get an error if you try to run the cat command while the
card is not inserted (the cat process would get killed).
--
Fernando Rodriguez
