diff for duplicates of <1538735635.3702.423.camel@linux.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 56f4159..8e76d10 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -15,9 +15,9 @@ On Thu, 2018-10-04 at 21:57 -0500, Goldwyn Rodrigues wrote: > > > the f_mode bits. > > > > Is there an appropriate low level kernel call for creating a new file -> > descriptor that would be appropriate? dentry_open(), like the call in +> > descriptor that would be appropriate? dentry_open(), like the call in > > file_clone_open(), has a lot of overhead, including the LSM calls. -> > Calculating the file hash always needs to work. +> > Calculating the file hash always needs to work. > > > > Mimi, @@ -41,19 +41,19 @@ On Thu, 2018-10-04 at 21:57 -0500, Goldwyn Rodrigues wrote: > Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com> By "overhead", I didn't mean it from a performance perspective, but -was concerned about the dentry_open() failing. If "dentry_open" fails +was concerned about the dentry_open() failing. If "dentry_open" fails for any reason, the file hash will not be re-calculated, causing -future file opens to fail. Missing is the test for dentry_open() +future file opens to fail. Missing is the test for dentry_open() failure. By removing the "read" check, re-opening the file is now for all -files, not just those opened without "read". From a testing +files, not just those opened without "read". From a testing perspective, it will catch problems faster, but ... I've had a patch queued that removes the O_DIRECT test, but haven't -had a chance to test it on ALL filesystems. I would probably re-open +had a chance to test it on ALL filesystems. I would probably re-open the file with the original flags, plus read, as much as possible. - + Mimi diff --git a/a/content_digest b/N1/content_digest index 9e88e15..0beccfd 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -35,9 +35,9 @@ "> > > the f_mode bits.\n" "> > \n" "> > Is there an appropriate low level kernel call for creating a new file\n" - "> > descriptor that would be appropriate? dentry_open(), like the call in\n" + "> > descriptor that would be appropriate? \302\240dentry_open(), like the call in\n" "> > file_clone_open(), has a lot of overhead, including the LSM calls.\n" - "> > Calculating the file hash always needs to work.\n" + "> > \302\240Calculating the file hash always needs to work.\n" "> > \n" "> \n" "> Mimi,\n" @@ -61,19 +61,19 @@ "> Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>\n" "\n" "By \"overhead\", I didn't mean it from a performance perspective, but\n" - "was concerned about the dentry_open() failing. If \"dentry_open\" fails\n" + "was concerned about the dentry_open() failing. \302\240If \"dentry_open\" fails\n" "for any reason, the file hash will not be re-calculated, causing\n" - "future file opens to fail. Missing is the test for dentry_open()\n" + "future file opens to fail. \302\240Missing is the test for dentry_open()\n" "failure.\n" "\n" "By removing the \"read\" check, re-opening the file is now for all\n" - "files, not just those opened without \"read\". From a testing\n" + "files, not just those opened without \"read\". \302\240From a testing\n" "perspective, it will catch problems faster, but ...\n" "\n" "I've had a patch queued that removes the O_DIRECT test, but haven't\n" - "had a chance to test it on ALL filesystems. I would probably re-open\n" + "had a chance to test it on ALL filesystems. \302\240I would probably re-open\n" "the file with the original flags, plus read, as much as possible.\n" - " \n" + "\302\240\n" "Mimi\n" "\n" "\n" @@ -180,4 +180,4 @@ "> /*\n" > -c2873fc1a45a4494201e3b7023d43e28b1dc3501c484096842f096e852c4c7e1 +cb282fbb3952894a0dd76085a5c133d35e9c68856411c1775aa90fded4158831
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.