I'm using Fedora 15 and I ran hugeadm --create-user-mounts=luto (and created a pool). The result is:
$ cat /proc/self/mounts |grep huge systemd-1 /dev/hugepages autofs rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0 none /var/lib/hugetlbfs/user/luto/pagesize-2MB hugetlbfs rw,seclabel,relatime,pagesize=2097152 0 0 $ ls -ld /dev/hugepages drwxr-xr-x. 2 root root 0 Oct 11 10:12 /dev/hugepages $ ls -ld /var/lib/hugetlbfs/user/luto/pagesize-2MB drwx------. 2 luto root 0 Oct 13 10:07 /var/lib/hugetlbfs/user/luto/pagesize-2MB [luto@midnight ~]$ hugectl --force-preload --heap sleep 1 So hugectl should work. But it doesn't: $ hugectl --force-preload --text true libhugetlbfs: ERROR: mkstemp() failed: Permission denied libhugetlbfs: WARNING: Failed to setup hugetlbfs file for segment 0 oops. This works around it: $ HUGETLB_PATH=/var/lib/hugetlbfs/user/luto/pagesize-2MB/ hugectl --force-preload --text true Presumably something in add_hugetlbfs_mount should check that the current user has write access to the mount before selecting it. --Andy ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel