path: root/hurd/libfuse.mdwn
diff options
authorThomas Schwinge <>2013-07-10 23:39:29 +0200
committerThomas Schwinge <>2013-07-10 23:39:29 +0200
commit9667351422dec0ca40a784a08dec7ce128482aba (patch)
tree190b5d17cb81366ae66efcf551d9491df194b877 /hurd/libfuse.mdwn
parentb8f6fb64171e205c9d4b4a5394e6af0baaf802dc (diff)
Diffstat (limited to 'hurd/libfuse.mdwn')
1 files changed, 20 insertions, 0 deletions
diff --git a/hurd/libfuse.mdwn b/hurd/libfuse.mdwn
index 45ff97ec..78e96022 100644
--- a/hurd/libfuse.mdwn
+++ b/hurd/libfuse.mdwn
@@ -29,6 +29,26 @@ etc.
* File I/O is quite slow.
+## IRC, freenode, #hurd, 2013-05-31
+ <zacts> well the reason I'm asking, is I'm wonder about the eventual
+ possibility of zfs on hurd
+ <pinotree> no, zfs surely not
+ <zacts> *wondering
+ <zacts> pinotree: would that be because of license incompatabilities, or
+ technical reasons?
+ <pinotree> the latter
+ <taylanub> It's just a matter of someone sitting down and implementing it
+ though, not ?
+ <pinotree> possibly
+ <braunr> zacts: the main problem seems to be the interactions between the
+ fuse file system and virtual memory (including caching)
+ <braunr> something the hurd doesn't excel at
+ <braunr> it *may* be possible to find existing userspace implementations
+ that don't use the system cache (e.g. implement their own)
+ <braunr> and they could almost readily use our libfuse version
# Source
[[source_repositories/incubator]], libfuse/master.