17

If you're using systemd-nspawn, start up your container with the --capability=CAP_MKNOD command line switch. This will allow you to create device nodes inside your container. Then create a loop device like this: # mknod /dev/loop0 b 7 0 Remember that this loop device is shared with the host and is called /dev/loop0 there as well. And that it is now ...


9

Loop devices are provided by a kernel module. Therefore, you need special privileges to access them. You also need them to be exposed into your container, or you need to manually create the device files. The quick answer docker run --privileged=true ... An alternative sudo losetup /dev/loop0 test.img mount /dev/loop0 /mnt docker run -v /mnt:/mnt ... ...


8

For some reason this has worked losetup /dev/loop0 <vmdk file> kpartx -av /dev/loop0 mount /dev/mapper/loop0p1 /mount/point I have no idea why this worked and not the above method. If you have any explanation, please let me know.


5

The lack of output from losetup -a, and that fact that losetup -f gives you the first free device as /dev/loop0, shows that you haven't yet associated that loopback device with any physical storage. What unused physical partition or LVM volume do you wish to use as the actual storage for your loopback encrypted device? If it's, say, /dev/sd2a, then bind ...


4

Yes, you can use a file for L2ARC. You don't even need the loopback mount: you can simply issue zpool add tank cache <absolute_file_path> That said, L2ARC is only useful in specific circumstances, so it is not granted that it will improve your situation.


3

This is what I've gathered by poking around the source for util-linux-ng 2.17.2, which was included with CentOS 6: On kernels < 2.6.37, Linux requires that an entry be written to /etc/mtab for loop mounted filesystems in order to autoclear the loop device later. If /etc/mtab is not writable at mount time or the entry was removed from /etc/mtab then the ...


3

You might create a gzip compressed ZFS pool based on plain files and store your logs on it. There would be no need to do anything else than writing the logs there. They will, from the outset, only use their compressed size in the ZFS file systems. You will be able to read the data afterwards (grep, find, less, and so on), and even modify, delete them even ...


3

it's ancient topic, I know, but answer may hopefuly be useful for future generation of script programmers I found at least some answer to referred question being in travel: all devices can be displayed with $ losetup -a /dev/loop0: [2065]:25 (/mnt/live/memory/data/slax/01-core.sb) /dev/loop1: [2065]:26 (/mnt/live/memory/data/slax/02-xorg.sb) /dev/loop2: ...


2

I think your assumption about things going into read only mode when the connection to the network drive is lost is correct. I made a simple test with a just a small file on a Samba share and the same thing happens if I yank the network cable. As for a solution to the problem, I would go about it like this: Depending on how you actually do the backup, I ...


2

I know logrotate has been suggested for you here, but if you'd still would like to go forward with the compressed filesystem idea, why wouldn't you create those only after the day is over? Your shell script would then calculate the size of the logging folder, create the loopback device file of needed size, mount the loopback image, move the log files there, ...


2

You should investigate the use of logrotate(8) to help manage your log files. It can be configured to rename your files to a specific date format and compress them automatically. You can also configure it to keep a specified number of logs (and many other things). Once you have it set up like you want you can basically forget about it. Also, take a look at ...


2

TL;DR: it appears not to be a kernel issue, but the mount command not behaving as expected by not setting the loop device's LO_FLAGS_AUTOCLEAR flag. Using a more recent out-of-distribution mount command should probably solve it. Stracing a (recent system's) command mount, led me to loop(4)'s flag LO_FLAGS_AUTOCLEAR: LO_FLAGS_AUTOCLEAR (since Linux 2.6.25) ...


2

You should only disable spanning tree if you do not use Layer2. If all ports on your switch are Layer3 interfaces, you cannot have a loop and your endpoints are routed, each with a private subnet. Otherwise keep it on! Update There is a difference between OFF and not configured, with 2 switches I would leave them unconfigured, in most switches disabling ...


1

Yes, unless you use spanning tree (or a vendor specific equivalent like EAPS) to create a loop free network you will have problems, LACP does in no way help you to prevent loops, it was not designed to do so. You either make one of the paths in the triangle blocking with spanning tree, or perhaps (if your equipment supports this) create a virtual chassis ...


1

The information is available with /sbin/losetup -a.


1

You can disable STP but you shouldn't. Why? When someone connects two switch ports together your network will go down without STP. Leaving it on doesn't hurt a bit.


Only top voted, non community-wiki answers of a minimum length are eligible