On 05/14/2013 07:07 AM, Jiri Hoogeveen wrote: > I did not tried it. But it is possible. > Create a disk image in /dev/shm > > dd if=/dev/urandom of=/dev/shm/disk.img bs=1M count=100 > losetup /dev/shm/disk.img /dev/loop0 I set up bricks on ramdisks all of the time when I want to isolate network/CPU bottlenecks on systems where all of that would otherwise be hidden behind the slowness of disks. A couple of tweaks to the above: (1) It's a little quicker to use /dev/zero instead of /dev/urandom. It's a minimal calculation per byte, but all of those bytes add up. (2) You'll need to do a mkfs before mounting. Make sure e.g. to set an inode size of 512 or greater (just as we also recommend for normal filesystems). (3) You can skip losetup if you use "mount -o loop". If you're doing this for a high-performance scratch area, I also suggest setting up multiple bricks (so long as they're not so small that you run into ENOSPC when manipulating large files). The loopback driver is sadly single-threaded per device (historical note: it used to have more internal parallelism but then regressed) so the throughput will be noticeably limited by the speed of memory copies on a single core. > > > Now is /dev/loop0 your ram based disk :) > > Grtz, Jiri > On May 14, 2013, at 1:00 PM, Isak Nuhić <isak.nuhic@xxxxxxx> wrote: > >> Hi, >> >> is it possible to use ram-disks as bricks for building volumes in GlusterFS? I found an answer that it is not possible because ram-disk doesn't support extended attributes. Is there any way around it? I am trying to make a distributed volume with two ram-disk partitions as bricks but it doesn't work. >> >> Thank you all in advance. >> >> Isak >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxx >> https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > https://lists.nongnu.org/mailman/listinfo/gluster-devel >
