On 3/28/06, Sergei Organov <[email protected]> wrote:
> "linux-os \(Dick Johnson\)" <[email protected]> writes:
> > Note that the actual block size is usually 64k, not the 512 bytes of a
> > 'sector'. Apparently, some of the data-space on each block is used for
> > relocation and logical-to-physical mapping.
>
> Wrong. AFAIK, first disks had FLASH with 512b blocks, then next
> generation had 16K blocks, and currently most of cards have 128K
> blocks. Besides, each page of a block (64 pages * 2K for 128K block) has
> additional "system" area of 64 bytes. One thing that is in the system
> area is bad block indicator (2 bytes) to mark some blocks as bad on
> factory, and the rest could be used by application[1] the same way the
> rest of the page is used. So physical block size is in fact 64 * (2048 +
> 64) = 135168 bytes.
Doesn't this depend on if we are talking about NOR or NAND memory? It
looks like you are describing some kind of NAND memory. Also I guess
it varies with manufacturer.
When it comes to CF the internal block size doesn't really matter
because the CF controller will hide it for you. The controller will
perform some kind of mapping between the 512 byte based IDE-interface
and it's internal sector size. This together with wear levelling.
The quality of the wear levelling will probably vary, but I guess even
the most primitive brands have something to cope with the fact that
the blocks containing the FAT are often rewritten on FAT filesystems.
/ magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
