search

IO500 / io500

IO500 Storage Benchmark source code
MIT License
97 stars 31 forks source link

Fix backend #4

Closed adilger closed 3 years ago

adilger commented 3 years ago

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 running prepare.sh, as requested by prepare.sh should checkout specific commit of pfind.

JulianKunkel commented 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

gflofst commented 3 years ago

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.

adilger commented 3 years ago

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.

adilger commented 3 years ago

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.