On May 14, 2013, at 2:12 PM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote: > 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. True, I use this mostly for encrypted disks, that why I use /dev/urandom for almost everything :) > > (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". Also true, old habits. > > 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. Thanks for this information, did not know this limit. > >> >> >> 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 >> > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > https://lists.nongnu.org/mailman/listinfo/gluster-devel