Hi again, To Ogawa Hirofumi, Do you still object to merge this feature for .40? As I said the batched discard design is out-of-scope of this patch. It's implemented at other batched discard, ext4, xfs and so on. I hope fat is also support the batched discard. Any opinions? Thank you, Kyungmin Park On Thu, Mar 31, 2011 at 12:06 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Wednesday 30 March 2011, Kyungmin Park wrote: >> On Wed, Mar 30, 2011 at 11:20 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> >> > If you just pass the minimum length, the file system could end up >> >> > erasing a 4 MB section that spans two half erase blocks, or it >> >> > could span a few clusters of the following erase block, both of >> >> > which is not desirable from a performance point of view. >> >> >> >> Does those cards export such information correctly ? >> > >> > Most of the time, they export the erase block size correctly, but >> > sometimes they lie. In fact, all of the cards I've seen report >> > 4 MB erase blocks, but some cards in fact use 1.5 MB, 2 MB or 8 MB >> > instead. I'm sure we will see 3 MB, 6 MB, 12 MB and 16 MB soon. >> > >> > SD cards do not export the page size, but most of them today use >> > 16 KB. See my list at >> > >> > https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey >> >> Thank you for your effort. but think it the original purpose of >> batched discard feature. >> Do you want to run the batched discard for SD card. I mean usually in >> our environment SD card is optional. >> and my goal is used for eMMC. and you know, eMMC and SD card internal >> algorithm is different. > > I've done only a few measurements on eMMC, but for all I know, they > use the same fundamental principles, just with a slightly different > command set and physical interface. A number of manufacturers advertise > controller chips that can be integrated on either MMC or SD packages, > presumably using a different firmware. > >> The goal of SD card is performance but eMMC is different. it should >> consider the reliability also. e.g., Sudden Power Off Recovery. > > I would have guessed the opposite, that sudden power off is much > more important on SD cards that can simply be removed while writing. > > In practice, I would expect very little effort getting put into > reliability on either of the two. > > Note that there was a patch on the mmc mailing list very recently > to support the reliable write mode of eMMC. > > Also, when you want reliablility, you probably shouldn't use the > FAT file system, since it lacks transactional writes. If you target > eMMC media, there is usually no advantage in using FAT because the > data does not get accessed by other operating systems. > >> > Good SSDs can deal with remapping 4k blocks, while cheap ones >> > (SD cards, USB sticks, or low-end ATA SSDs) can only do operations >> > on full blocks. >> It really depends on devices. To increase the performance we have to >> increase the channel and the way unit at internally. >> Most NAND devices are similar there's no way except increase the >> interleaving unit. and it affects the price. >> >> That's reason I like the batched discard. it's not easy to guess the >> erase block at system level. so it's helpful scan the unused blocks >> and try to trim at once. > > I'm absolutely in favor of batched discard, I just think we should > apply some stricter rules to what blocks can get batched. > >> Please remember that the discard is just hint. If we write the flash >> sequentially then we maybe don't need to trim it. > > With the current trends in NAND technology, the number of erase cycles > keep going down, so I'd assume that we increasingly rely on discard > in order to keep the wear levelling working, at least for the media > that only do dynamic wear levelling. When you have a drive that supports > static wear levelling, discard becomes more a performance optimization > than a reliability requirement. > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
