* Question about mtd_blktrans_ops interface
@ 2009-05-18 1:52 HyoGi Sim
0 siblings, 0 replies; only message in thread
From: HyoGi Sim @ 2009-05-18 1:52 UTC (permalink / raw)
To: linux-mtd
Hi,
I about to write a FTL for a large (2KB or 4KB page size) NAND flash
devices.
MTD has a interface, mtd_blktrans_ops, for FTL. mtd_blktrans_ops has two
access interface; readsect and writesect.
Since readsect and writesect in mtd_blktrans_ops takes single sector #
for its argument, underlying FTL cannot handle multiple sectors at once
even if above block IO layer requested multiple, logically consecutive,
sectors in a request.
Here is a situation:
Let's say that flash device consists of 2 KB pages, and FTL registers
itself with 512B sector size.
If a filesystem lying on the FTL device uses 2KB blocks, mtd_blkdevs
always takes request whose size is multiple of 2 KB.
Let's assume that 2 KB request comes. Since current mtd_blktrans_ops
splits the request into four 512B pieces, the request incurrs four 512B
IOs in the FTL. Especillay for write requests, the splitted requests may
degrade performance since the FTL should write four times for
programming one 2KB page. Of course, although there can be a solution to
avoid the problem such as internal page buffering, it may be complicated
due to synchronization issues.
Here is my questions:
1. I think if the FTL device uses 2KB sector size, we can avoid the
splitted I/O problem. Am I correct?
2. I think it will be more general if mtd_blktrans_ops offers access
interfaces that take (starting sector#, # of sectors) like block IO
layer do. Any problems with that?
Thanks.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2009-05-18 1:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-18 1:52 Question about mtd_blktrans_ops interface HyoGi Sim
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).