| |||||||||||||
Unioning file systems: Architecture, features, and design choicesUnioning file systems: Architecture, features, and design choicesPosted Mar 19, 2009 18:04 UTC (Thu) by foom (subscriber, #14868)Parent article: Unioning file systems: Architecture, features, and design choices
> An important case is one in which you delete many files; with a unioning file system this will
> decrease the space needed to store differences. With a COW block device, used space will > increase.
It doesn't actually *have* to be the case. When linux adds the hooks needed by Flash drives to
If I were a kernel developer I'd be very wary of the endless-tarpit of unionfs issues when a way to
(Log in to post comments)
Unioning file systems: Architecture, features, and design choices Posted Mar 20, 2009 6:01 UTC (Fri) by vaurora (guest, #38407) [Link]
Good point! I believe that TRIM support of some form will be integrated in the near future (in file system terms - that is, several years) and that will make COW block devices more tenable. However, even with TRIM support, you run into the problem where the logical file systems are equivalent, but the same logical data is stored in different locations between the two images. The metadata is very likely to be different too at the block level.
COW block devices are a part of the solution space, they just don't completely replace unioning file systems.
|
|||||||||||||