jamesbond wrote:NBD is there mostly for performance reasons. Problems with NBD is similar NFS - it has no security. And to make it worse, it can only export one block device per service - thus if you want to server 10 different users, you need 10 instances of NBD server. If the server is light-weight enough, this probably isn't a problem.
Old thread/post I know, stumbled across it whilst looking where to post a x-ref for
http://murga-linux.com/puppy/viewtopic. ... 78#1039578
You can have multiple clients served from a single nbd server instance - provided you're content to use copy on write, where each user sees the same unchanging base set of files, but can individually edit those files and the changes are stored in separate diff files (copy on write). Like a sfs layered setup where the changes are lost at shutdown/disconnect and each user/client only sees their changes.
Yes the server would have to have a instance for each user if changes were desired to be saved back onto the server system. But if changes were stored locally then the server can be just a single instance.
Consider for example where I create a sfs of a documents folder on my server box 192.168.1.5
cd /mnt/sda1
mksquashfs docs docs.sfs -b 4096
Using a block size of 4K here as that's the minimum for mksquashfs whilst its the maximum for nbd.
I then serve that up using nbd
nbd-server 9000 /mnt/sda1/docs.sfs -c -C /dev/null
On a client I use nbd-client to link that server process to a device
nbd-client 192.168.1.5 9000 /dev/nbd0
and then mount that sfs
mkdir /tmp/sfs
mount /dev/nbd0 /tmp/sfs
and create a aufs structure for that so changes can be recorded
mkdir /root/changes
mkdir /tmp/top
mount -t aufs -o br=/root/changes:/tmp/sfs none /tmp/top
So when I open rox on /tmp/top and make changes to files there (sfs content), the changes are stored in /root/changes (which here I assume remains persistent, so prior changes remain available after reboot).
When done, I umount /tmp/top and /tmp/sfs ... and if later I re-establish that then the prior changes will still be available in /root/changes i.e. all changes are being recorded on the local system. Multiple users can use a similar arrangement on their box, all sharing the single core sfs, but each user having their own changes stored locally.
Only if I want those changes being stored back on the server would instead another nbd-server port be required, one for each user, in order to store the changes folder content on the server. But equally that could be via a sftp, scp or other transfer method.
In practice, there's not much point in actually serving up a main sfs on the server, the only benefit is that being compressed files will be quicker to read across the LAN. If a actual volume, or file filesystem is served along with copy-on-write, then that's the same as being read only anyway. And a file filesystem or actual volume is easier to update compared to having to unsquashfs, make the changes and mksquashfs a new version of sfs in order to update it. Whichever is used, the main core documents will be safe from the likes of being wiped out or modified by ransomware as they're read only and on a another box, only the changes (such as /root/changes folder content) might be destroyed/encrypted/changed, but so equally might those changes be destroyed/encrypted/changed if they were being stored in a rw folder on the server.