On Thu, Sep 08, 2016 at 02:40:38PM +0100, Mark Dixon wrote: > On Thu, 8 Sep 2016, William Hay wrote: > ... > >At present we're using a huge swap partition and TMPFS instead of btrfs. > >You could probably do this with a volume manager and creating a > >regular filesystem as well but it would be slower. > ... > > Hi William, > > I always liked your idea for handling scratch space, apart from the > contention with RAM that using tmpfs would cause. But I thought you > considered that a feature, not a bug? Your btrfs variation sounds much > better on that score :)
We always added a fudge factor so the swap was a fair bit larger than the maximum size of the tmpfs filesystems which should prevent most interference by the filesystem with processes. Remember tmpfs is not a ramdisk but the linux VFS layer without an attempt to provide real file system guarantees. It shouldn't be cached any more agressively than other filesystems under normal circumstances. Most of the arguments against it seem to be along the lines of "tmpfs uses swap therefore it must cause swapping" which doesn't seem to be the case. swap "a place for the kernel to store objects without a permanent home that need to survive for now but which it has no imminent use for." swapping (the bad sort at least) is where objects are pushed out to swap or a filesystem and then quickly brought back in to memory repeatedly. You'll get swapping if there are more objects needed in memory imminently than will fit or if the kernel is guessing wrong about which objects will be needed imminently. Using tmpfs vs another file system shouldn't alter the kernel's ability to guess which objects are likely to be used imminently just where the objects get pushed out to. Our planned switch to btrfs is motivated more by a switch to SSDs than any issues with swapping. > > It's just occurred to me that you might also be able to do this on more > stable^W^Wless advanced filesystems, by assigning a group quota on the GID > that gridengine allocated to the job and using some chmod g+s trickery. I > guess it could be circumvented by the determined using chgrp. What do you > think? In general I'm fairly comfortable with using btrfs for data that doesn't need to be preserved in the long term (ie working storage or data that can be easily recreated) and it has some neat features. I use other filesystems for data that would take work to recreate or is worth backing up/restoring. Not sure if you can chgrp a file to a group that doesn't have a quota on a filesystem with group quotas enabled. Being able to do so would make group quotas a pain to administer. However ,if you can, I'd be more worried about innocent subversion than malicious. Anything that did a copy from another filesystem or archive while attempting to preserve permissions could potentially break it. William
signature.asc
Description: Digital signature
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
