> > iSCSI/nbd(6) > | > filesystem { swap | ext3 ext3 jffs2 > \ | | | / > / \ | dm-crypt->snapshot(5) / > device mapper -| \ \ | / > | partitioning / > | | partitioning(4) > | wear leveling(3) / > | | / > | block concatenation > | | | | | > \ bad block remapping(2) > | | | | > MTD raw block { raw block devices with no smarts(1) > / | \ \ > hardware { NAND NAND NAND NAND
You failed to clearly define what is block until now, then you blame me that I do not understand you. So I see block = eraseblock, lets assume for further conversation. OK. Suppose we have done what you say, although I _do not_ think it is makes a lot of sense. So, now we have a block device, with 128KiB block size. We have LVM, dm-wl or whatever stuff. Fine. Do you realize that 128KiB is _huge_ block size, and performance will suck, and suck a lot if you utilize say, ext2 or whatever block device FS. Do you realize that I may not be satisfied with slow I/O? Do I have right to have faster one? Thanks if yes. To make it faster I have to have a way to do finer grained I/O: read/write to different positions of 128KiB block. Do you realize how much you will abuse all the generic block device infrastructure if you try to add this? Note, all levels up to LVM will need to have this. A believe it is braindead ((c) tglx) to add this feature. Also, in UBI we have the following features: 1. data type hints: you basically may help UBI to pick optimal eraseblock if you specify data life-time - is it long-live data, or short-live/temporary data. 2. Some other ones, do not want to describe now. Do you offer to add this stuff to DM-mapper? So, you approach only makes sense if you are going to work with flash as block device with block size = eraseblock size. No finer grained access at all. It is fine, some users may be ok with this. But please, do not be so naive - the performance will suck a _lot_. Let alone I doubt it will really fit the DM infrastructure. We work on different approach. And in general, the picture which Thomas drew to you makes _much more_ sense. Please, do not be so stuck to your way, it is not bad or good, it is just _different_, and it has obvious limitations which we do not want to have, thus we go other way. -- Best regards, Artem Bityutskiy (Битюцкий Артём) - 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/