We've reconsidered this feature and decided to get just runtime info of them, not persistent on disk. I am re-writing it.
Thanks, 2021년 3월 10일 (수) 오전 10:31, Chao Yu <yuch...@huawei.com>님이 작성: > > On 2021/3/9 21:00, Daeho Jeong wrote: > > 2021년 3월 9일 (화) 오후 6:22, Chao Yu <yuch...@huawei.com>님이 작성: > >> > >> On 2021/3/5 10:24, Daeho Jeong wrote: > >>> From: Daeho Jeong <daehoje...@google.com> > >>> > >>> Added acc_compr_inodes to show accumulated compressed inode count and > >>> acc_compr_blocks to show accumulated secured block count with > >> > >> I noticed that these stat numbers are recorded in extra reserved area in > >> hot node curseg journal, the journal will be persisted only for umount > >> or fastboot checkpoint, so the numbers are not so accurate... does this > >> satisfy your requirement? > >> > > > > Yes, we are satisfied with just getting rough number of them. But, it > > Alright, > > > would be better if you suggest more accurate way. :) > > I think this is the cheapest way to store rough number, otherwise it needs to > change > f2fs_checkpoint structure layout or add a new inner inode to persist these > stat > numbers if we want more accurate one. > > > > >>> compression in sysfs. These can be re-initialized to "0" by writing "0" > >>> value in one of both. > >> > >> Why do we allow reset the stat numbers? > >> > > > > Actually, I want to have a way to clear any stale number of them, but > > I agree we don't need this. > > > >> Why not covering all code with macro CONFIG_F2FS_FS_COMPRESSION, since > >> these > >> numbers are only be updated when we enable compression. > >> > > > > I wanted to keep the info even in the kernel with doesn't support > > per-file compression if those had been written once. What do you > > think? > > Sure, if so it's fine to me. :) > > Thanks, > > > > >> Thanks, > > . > >