To be fair, I don't think anybody has been trying to guess track boundaries for a decade. It's been well known that the number of sectors per track varies because of constant data density and larger surface area at the outer rim of the disc.
Because somebody has to do the write equalization on today's flash, I in fact prefer it to be hardware because there's less chance that changes in software get to break it. If it's all software, you presumably have some kind of data partition exposed over especially rewrite-durable media that tracks the info about flash block write cycles per erase cell, and which must never be overwritten during disk formats for instance. (If not, then I guess you use the same flash chips for wear-leveling information as the filesystem itself, which sounds like another kind of headache. Not sure how these things work.)
It's interesting that modern android phones appear to be using ext4 over hardware remapping layers too. I guess NAND-level chip access sounds better in theory than in practice.
Posted Jun 9, 2012 13:49 UTC (Sat) by drag (subscriber, #31333)
[Link]
> It's interesting that modern android phones appear to be using ext4 over hardware remapping layers too
File systems for block devices is a proven technology and is very mature. FTL firmwares and techniques is a widely known and proven technology, also.. since it has been a basic requirement for generations of consumer flash devices in order to be compatible with Windows.
So I am guessing that phone manufacturers, which are mostly integrators and not developers, are more interested in getting products out the door rather then working with chipset manufacturers to develop interfaces for theoretical large file system design.
So while I doubt having multiple layers of abstraction been the kernel and the storage device is optimal performance and reliability wise, it is certainly the most cost effective approach for today's consumer electronics.
:)
Chris Mason leaving Oracle
Posted Jun 10, 2012 17:46 UTC (Sun) by linusw (subscriber, #40300)
[Link]
> So I am guessing that phone manufacturers, which are mostly integrators and not developers, are more interested in getting products out the door rather then working with chipset manufacturers to develop interfaces for theoretical large file system design.
From this we are discussing alterations needed to the file system, VFS etc.
In Linaro we had Samsung, SanDisk and Micron visiting us to discuss these issues at the latest Linaro connect meeting in Hong Kong.
Chris Mason leaving Oracle
Posted Jun 11, 2012 8:50 UTC (Mon) by etienne (subscriber, #25256)
[Link]
> trying to guess track boundaries for a decade
On a rotating hard disk with two physical heads, there should be two areas which shall be accessible within a very short time (< 1ms) while it is long (>6 ms) to go from the beginning of one of those area to its end.
I didn't measure it myself, but some optimisation could probably be done there, even if it means some initial run-time testing to find those areas, and few failed optimisations when a sector is re-allocated.
Maybe that "stripping" is already done in hardware, I do not know.
Chris Mason leaving Oracle
Posted Jun 11, 2012 11:07 UTC (Mon) by ttonino (subscriber, #4073)
[Link]
When one head is tracking correctly, the other most likely is not, with thermal expansion and what not.
Tracking is highly dynamic. Even writing and reading with the same head needs slightly offset tracking. It is probably better to use just a single head, as the seek behaviour can be more predictable.
Also, sequential throughput is not the limiting factor. Seek time is.
Chris Mason leaving Oracle
Posted Jun 11, 2012 11:59 UTC (Mon) by etienne (subscriber, #25256)
[Link]
Yes, seek time is the limiting factor, at least by a factor of 6, so there are cases where it is better to read from another head nearby where it is currently located, instead of seeking the current head to the other side of the disk.
For instance, in a read mostly situation, if you have files organized in an increasing LBA order on one head and same files (RAID 1) in decreasing LBA order on the second head you should be able to access all files with half the disk seek time.
Or find a clever way to write the data of the file on one head and its meta-data (file descriptor, inode table, journal) in the other head at approximately the same physical location.
On the other side, if stripping is done by the disk firmware, disk partitions should be aligned to the stripping size.
Chris Mason leaving Oracle
Posted Jun 14, 2012 6:35 UTC (Thu) by nhippi (subscriber, #34640)
[Link]
> It's interesting that modern android phones appear to be using ext4 over hardware remapping layers too. I guess NAND-level chip access sounds better in theory than in practice.
It is more a market thing. 32GB eMMC chips (without raw access) are easily available on the markets - the interface is standard and shares infrastructure with SD card manufacturing. Meanwhile there is no real standard for "raw" NAND interface, therefor finding a NAND chip that is both big and is compatible with your SoC is tricky and often more expensive..