Closed adilger closed 3 years ago
It does have something to do with the non-POSIX backends. The extra option isn't needed more as backend-specific options are directly supported now. Now it is possible to specify in api=posix --posix.odirect
Julian commented that the pointer arithmetic probably would not work for non-western languages (i.e., it may not be fully unicode compliant). I am not comfortable approving this until someone can tell me that it will work on multi-character languages OR that no PFS or storage system we could run on allowed multi-character names in paths.
Jay, I suspect that all of the other parsing code has the same problem, so it is unlikely that multi-byte character sets are going to suddenly stop working if this patch is landed.
If this is a concern, which I haven't seen any bug reports for, then it makes sense to have someone test io500 is such an environment, but I don't think multi-byte support should suddenly be a requirement that is introduced the day we are trying to announce the CFS.
PS: filesystems typically do not "support" character sets in pathnames. They just store bytes (excluding '/' and '\0') and return them back to the user, and how they are interpreted is up to userspace. That means it isn't really possible to say that no PFS supports multi-byte pathnames.
Patch series from Julian to improve usage of non-POSIX backends. I refactored it to merge bug fixes into the original patches that add the changes.
Each patch updates the
prepare.sh
file with the version of IOR that it can build against, so that each patch can at least run a basic test.I also enabled the
$PFIND_HASH
usage when runningprepare.sh
, as requested by prepare.sh should checkout specific commit of pfind.