You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mostly the changes should be to the data recipe [1]
I have some code in another context that does this:
@fab.roles('node')
@fab.parallel
def _clean_devices():
for i in range(DEVICE_COUNT):
fab.run('dmsetup remove dev%s || true' % i)
fab.run('losetup -d /dev/loop%s || true' % i)
fab.run('rm /var/dev%s.block || true' % i)
fab.run('udevadm settle')
@fab.roles('node')
@fab.parallel
def _create_devices():
for i in range(DEVICE_COUNT):
fab.run('dd if=/dev/zero of=/var/dev%s.block bs=1M count=3000' % i)
for i in range(DEVICE_COUNT):
fab.run('losetup /dev/loop{0} /var/dev{0}.block'.format(i))
for i in range(DEVICE_COUNT):
sectors = fab.run('blockdev --getsize /dev/loop%s' % i)
fab.run('dmsetup create dev{0} --table '
'"0 {1} linear /dev/loop{0} 0"'.format(i, sectors))
@fab.task
@fab.runs_once
def setup_devices():
"""
Add Device Mapper block devices to Nodes
"""
fab.execute(_clean_devices)
fab.execute(_create_devices)
... but I think that strategy could be improved further because vsaio's can potentially want many more swift devices than /dev/loop* entries ...
I might just create a single sparse file and loopback that onto /dev/loop0 (like the recipe already does), but then break that up into <sectors> / <DEVICE_COUNT> "chunks" and then use dmsetup to create dev<N> device tables like 0 <chunks> linear /dev/loop0 <N * chunks> [2]
probably need to double check that, I think the syntax is <start-of-table-entry> <size-of-table-entry> linear <source-device> <source-device-offset> - since we only create one table entry per device, and always use the same loop device - I think it's always 0 <size-of-each-dev-in-sectors> linear /dev/loop0 <start-sector-offset-of-loop-device> - https://www.kernel.org/doc/Documentation/device-mapper/linear.txt
The text was updated successfully, but these errors were encountered:
Previously, we would create one loopback device with some subdirs
to represent "drives" and symlink them into place under /srv/node*
Now, use N loopback devices. Note that you may want to crank down
LOOPBACK_GB as it applies to each sparse file and the default may
allow you to fill your VM's root disk.
Two side benefits (beyond getting closer to "real" system behavior):
we can now enable mount_check, and we can have per-node-and-service
rsync modules.
Addresses #43.
Mostly the changes should be to the data recipe [1]
I have some code in another context that does this:
... but I think that strategy could be improved further because vsaio's can potentially want many more swift devices than
/dev/loop*
entries ...I might just create a single sparse file and loopback that onto
/dev/loop0
(like the recipe already does), but then break that up into<sectors> / <DEVICE_COUNT>
"chunks" and then usedmsetup
to createdev<N>
device tables like0 <chunks> linear /dev/loop0 <N * chunks>
[2]<start-of-table-entry> <size-of-table-entry> linear <source-device> <source-device-offset>
- since we only create one table entry per device, and always use the same loop device - I think it's always0 <size-of-each-dev-in-sectors> linear /dev/loop0 <start-sector-offset-of-loop-device>
- https://www.kernel.org/doc/Documentation/device-mapper/linear.txtThe text was updated successfully, but these errors were encountered: