On 2010-11-25, at 07:27, Lukas Czerner wrote: >> Walk through allocation groups and trim all free extents. It can be >> invoked through FITRIM ioctl on the file system. The main idea is to >> provide a way to trim the whole file system if needed, since some SSD's >> may suffer from performance loss after the whole device was filled (it >> does not mean that fs is full!). One question I have is why a major change like this is being done in ext3 instead of only in ext4? There are a lot of ext4 features that _could_ be included in ext3 (basically all of them), but the request from the rest of the kernel developers was to leave ext3 with minimal changes (for continued stability), and put all of the major changes into ext4. With the current ext4 code's performance and feature advantages, and widespread use in newer distros, I don't think there is a good reason to make major modifications to ext3. It should remain as the stable legacy filesystem for some number of releases, and then possibly we should just remove one or both of ext2 and ext3 and use the ext4 code for both. Given that Google is running ext4 in no-journal mode (i.e. ext2-like) on many thousands of machines, and getting _much_ better performance than the old ext2 code, it doesn't make sense to continue investing so much maintenance effort into ext2 and ext3. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
