Dear Mr.Matthew and other fs developers: I'm very sorry.My gmail maybe be blocked for reasons I don't know.I have to change my email domain. > So, my proposal is that filesystems tell the page cache that their minimu= m > folio size is the compression block size. That seems to be around 64k, > so not an unreasonable minimum allocation size. Excuse me,but could you please clarify the meaning of "compression block si= ze"? If you mean the minimum buffer window size that a filesystem requires to perform one whole compress write/decompress read io(also we can call it the granularity),which,in f2fs context we can interpret as the cluster size.Then that means for compress files,we could not fallback to 0 order folio in memory pressure case when setting folio's minmium order to "compression block size"?
If that is the case,then when f2fs' cluster size was configured,the minium order was determined(and may beyond 64KiB.Depending on how we set the cluster size).If the cluster size was set to a large number,we will encounter much more risk when in memory pressure case. Well,as for the 64Kib minimum granularity,because Android now switchs page size to 16Kib so for current f2fs compress implementation the minimum possible granularity indeed just exactly equals 64Kib.But I do hold a opinion that may not be a very good point for f2fs. Because just as I know,there are lots of small random write on Android.So instead of having a minimum granularity in 64Kib,I appreciate future f2fs's compression's implementation should support smaller cluster size for compression. As far as I know,storage engineers from vivo is experimenting a dynamic cluster compression implementation.It can adjust the cluster size within a file adaptively.(Maybe larger in some part and smaller in other part) They didn't publish the code now.But this design maybe more suitable for cooperating with folios for its vary-order feature. > It means we don't attempt to track dirtiness at a sub-folio granularity > > (there's no point, we have to write back the entire compressed bock > at once). That DO has point for f2fs.Because we cannot control the order of folio that readahead gave us if we don't set maximum order.A large folio can cross multi clusters in f2fs as I have mentioned. Since f2fs has no buffered head or a concept of subpage as we have discussed previously, It must rely on iomap_folio_state or a similar per folio struct to distinguish which cluster range of this folio is dirty. And it must distinguish a partialy dirted cluster to avoid compress write. Besides,l do think larger folio can cross multi compressed extent in btrfs too if I didn't misunderstand.May I ask how do btrfs deal with the possible write amplification? _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
