Hi Jim, Thanks for your prompt response!
Jim Meyering wrote: > jeff.liu wrote: >> Hi Jim, >> >> I'd like to know if I should still submit new feature patches to here or >> [email protected]. >> >> A few months ago, I found the heads up for the new [email protected] mail >> list, and it mentioned >> only the bugs report/fix should be send to this list. Otherwise, for the >> general discussion and new >> features request should go to the new list, Am I right? >> >> But looks there is little activity in [email protected], I have sent a few >> patches related to cp(1) >> sparse file enhancement through fiemap ioctl(2), but almostly no response >> from the list members in >> about 2 weeks, except Joel I cc-ed. Maybe nobody is interesed. :( >> >> I know you guys are busy with work. Actually, I just want to know if I was >> misunderstood the >> policy? If so, I will submit the patches here. > > Hi Jeff, > > bug-coreutils is definitely the right list, and I confirmed this > morning that you are covered on the copyright front (Oracle has an "ANY" > assignment with the FSF), assuming you're doing this on company time. > If you're doing any of this work on your own time, you should follow > the procedure outlined here: > > http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n327 > Yeah, I did this work on my company time. > Over the last few weeks I've been working on other projects > (pretty must time dedicated to getting grep back into shape), > so coreutils has languished. Sorry for not giving more feedback, > but I have been watching. > > In fact, seeing the use of HAVE_FTRUNCATE that is moved by your patch > is what prompted me to mark the ftruncate module as obsolete and remove > that code from copy.c. > > While I'm writing, here's one high-level question for you. > When would your new --fiemap-sync option be useful, and what change > in semantics will I see between when I use it and when I don't? > > --fiemap-sync sync file data before fiemap\n\ > IMHO, there is no difference from the user's point of view with or without this option. and on the kernel side, if FIEMAP_FLAG_SYNC was specified, it just do the dirty page process regardless of the sync succeeds or failed due to ENOSPC or EIO or other errors. I need to do more investigation to answer this question. > I cannot deduce that from anything I've seen written in your > patch or even in the related kernel sources I've seen so far. > I.e., if you can justify the addition of this option, > then that justification should be obvious from its description > in doc/coreutils.texi. > > Sure, I know what "sync" means, but for a command-line tool > like cp, why provide the option when the user can simply > precede the cp invocation with a use of sync(1). > At first, I think the user could just run `cp --fiemap=[WHEN] --fiemap-sync' in terms of 'sync; cp...' semantics. But actually, just as you said, it is indeed a duplicate option since we can do same thing in a simply way. > I presume you can give an example where cp produces different results > with and without --fiemap-sync. Please demonstrate that. I will try to do more test for the verify check. Best Regards, -Jeff
