On Mon, 2014-01-20 at 11:52 +0100, Andreas Rohner wrote: > Hi Vyacheslav, > > On 2014-01-20 11:14, Vyacheslav Dubeyko wrote: > > On Sun, 2014-01-19 at 15:01 +0100, Andreas Rohner wrote: > > > > It is expected "From: <author name and name>" and "Subject: <subject>" > > in the begin of patch. > > Are you sure? I don't see that in other patches and I think this > information is already contained in the email headers. I used "git > send-email" to submit the patch. > It is requirement for kernel patches. You can see it in kernel documentations. > >> With this option the user can specify the minimal number of free/dead > >> blocks, which is a threshold for the GC. If there are less free blocks > >> to gain from cleaning a segment than the specified number, the GC will > >> abort and try again with a different segment. > >> > > > > What will be under stress? I mean situation when we processed all > > segments that it is valuable for cleaning on threshold basis. Then we > > need to clean segments for space allocation but all "dirty" segments not > > reasonable choice for cleaning because of threshold. > > You have a point here. I could add another option that is used when the > file system is under stress. Just like with cleaning_interval and > mc_cleaning_interval. By setting the mc-option to 0 you could disable > the threshold under stress. > I suppose that it should be made by nilfs_cleanerd by itself but not an user. > > What will we have in situation when an user selects not proper value of > > threshold? > > Well that's the users problem. You could also ask what will happen if > the user selects an improper min_clean_segments value ;) > I don't think that it is good approach not to defend an user from mistaken decision. > > I worried about situation of skipping sibling segments from cleaning. Is > > NILFS2 driver really ready for this? Did you think about efficiency of > > free space allocation after such cleaning and about file system > > consistency? Are you sure that all will be good after such approach of > > cleaning? I simply want to be sure that you have analyzed this. > > I tested it extensively and I am quite sure, that there are no problems > with that on the driver side. > I want to listen the approach at whole and arguments how it works for the NILFS2 at whole. Such words as "I tested it and it works" is dangerous. Did you check your file system by fsck? I suppose that you don't. So, we need some reasonable description of concept that it prove your vision. Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
