Moving your Lightroom image library to a NAS
Lightrooms data files can roughly be put into two categories: The catalog file(s), which contain meta data about your images such as their location and the actual image files.
Lightroom does not permit having the catalog files on network attached storage, so you will have to keep those on your workstation. However, you can choose to have Lightroom backup your catalog files to the NAS so they are stored together with your images. This can be configured by going into Edit > Catalog Settings in Lightroom.
The following steps explain how to move your images from your workstation to a location on the NAS.
- Locate your catalog file (you can find it in Edit > Catalog Settings) and make a backup of it. Just as a safety precaution.
- Locate the folder containing your images and copy it to the NAS
- Rename the local image folder to something like ‘images_OLD’
- Open Lightroom
- In Library mode, there should now be question marks on the folders, since we renamed the image folder to images_OLD
- Right click on each folder and select its new location on the NAS
- Once all folders have been resolved, do a quick check, that all images are there
If something goes wrong you can always replace the catalog file with the backup from step 1 and rename the images_OLD back to using your local image folder.
As to be expected, there is a slight performance drop, by having the images on a network share instead of a local harddisk. In order to quantify the difference I picked 10 test photos (RAW) and measured the the time it took to zoom in on the image in Library mode. Zooming in on an image forces the actual image to be loaded into memory instead of just showing a preview.
- Avg. zoom time Local: 6 seconds
- Avg. zoom time NAS: 6.9 seconds
Not much of a difference and hardly noticable. I have not timed any other operations, but it appears, that the main loading happens only once. I.e., there is no lag when cropping or fixing white balance, since the image has already been loaded into memory.
It is possible to configure the harddisks to spin down after a period of inactivity, but if one or more processes keep reading and writing from the disks, that will prevent them from entering standby mode.
To find out which processes are causing disk activity, the following script is very useful:
The script works like this:
- A standby signal is sent to the disk.
- Wait until a process wakes up the disk and then prints out name of that process.
The following link contains a list of daemons and configurations known to cause random disk activity: Standby Mode FAQ
Older versions of Squeezebox Server caused lots of disk activity, but fortunately that has been resolved in version 7.5.1.
What is jdb2 and flush?
Sometimes the processes “jbd2” and “flush” are waking up the harddisk. As I understand, these processes are responsible for doing delayed writes to the disk in order to optimize performance. In other words, they are writing to the disk on behalf of other processes which makes it difficult to find the culprit(s). In my case, it was the samba daemon accessing the disk. As long as a PC or media streamer on your network has an open view on any of your samba shares, it will cause the disks to wake up.
Plug the USB stick into the Qnap. Then in a terminal, as root, do an lsusb to confirm that the USB drive has been recognised.
To find out what device name it has been assigned, do a dmesg | tail. This will print the latest lines from the kernel log, which should contain information about the inserted USB drive:
fdisk -l, which shows all connected drives, can also be used to find the right device name. The USB drive can be recognised by its size. In this case, it is a 2 GB one:
If the USB drive is already formatted with e.g. NTFS, it has probably been mounted automatically, in which case it should be unmounted. You can check this with the df command:
Once we know the name of the drive and it is unmounted, we can create a new linux partition using fdisk:
- If for example the device is sdv1, do an fdisk /dev/sdv1
- type d to delete any existing partitions.
- Type n to create a new partition.
- Make it primary and first
- Go with the defaults when prompted for start and end cylinder
- Press t to change the filesystem to linux (number 83)
- Type w to write the changes to the disk and exit
Finally, format the partition with the ext3 filesystem:
mke2fs -j /dev/sdv1
Now the partion is formatted and it can be mounted again:
The USB drive is now ready for use 🙂
Daemon services, or just daemons, are started at boot time. They are roughly equivalent to services in the Windows world.
To see which daemons are available on a system, do an
ls -l /etc/init.d/
Every script in that directory represents a daemon, which can be started, restarted and stopped manually using the following syntax:
/etc/init.d/<daemon name> start | restart | stop
If, for example, I wanted to restart an nzb-get daemon due to changes in its configuration files, I would type
After issuing the command, the daemon will usually print some lines to the terminal indicating what it is doing, e.g.: “Starting NZB-Get Daemon” or “Shutting Down“.
If you want to make sure whether a daemon is running or not, you can grep for its name in the list of running processes. If I wanted to see if the nzb-get daemon was really started, I could do the following grep:
ps -aux | grep nzb
If the daemon is running, this will produce a result like:
8148 admin 2456 S /opt/bin/nzbget --daemon
8355 admin 564 S grep nzb
The first line is the daemon. Notice the “–daemon” at the end of the line. The second line is the grep process we just ran to find the daemon.
Based on the guide on the QNap wiki. This guide specifically shows how to install a subversion server on port 4000 for multiple repositories on the QNAP TS-239 Pro II.
- Install svnserve:
# ipkg update
# ipkg install svn
- Create a directory for the repositories:
# mkdir /share/HDA_DATA/subversion
- To create a new repository for a project, do the following:
# svnadmin create /share/HDA_DATA/subversion/repos1
NB: To delete a repository, just delete the directory itself.
- Access to the repositories is set up in the repos1/conf/svnserve.conf, repos1/conf/passwd and repos1/conf/authz files. The following is a basic configuration.
anon-access = read
auth-access = write
password-db = passwd
svnuser = rw
- To start the svnserve daemon on startup, we must add a command to autorun.sh.
This file is located on the configuration ram block, sdx6, which must first be mounted. This is done in the following way on the TS-239 Pro II (for other models, see Running Your Own Application at Startup)
# mount -t ext2 /dev/sdx6 /tmp/config
Open autorun.sh in an editor:
# nano /tmp/config/autorun.sh
Add the following line, which will make sure svnserve is executed only when opt/bin has been loaded:
(while test ! -x "/opt/bin/svnserve"; do sleep 5; done; /opt/bin/svnserve -d --listen-port=4000)&
Finally, make sure autorun.sh is executable and unmount sdx6:
# chmod +x /tmp/config/autorun.sh
# umount /tmp/config
- You can test the subversion server by doing a checkout using your favourite subversion client (e.g. TortoiseSVN). The url to check out will be something like this:
UPDATE 10/6 2019
After a QNap update, the Subversion server would no longer start. It appears that the “opt” dir symlink no longer points to the right place. The following fixed it.
In the autorun.sh file, just add the following instead of the above:
(while test ! -x "/share/HDA_DATA/.qpkg/Optware/bin/svnserve"; do sleep 5; done; /share/HDA_DATA/.qpkg/Optware/bin/svnserve -d --listen-port=4000)&
Having recently upgraded my home network to Gigabit speeds, I still had my old devices and cables around. Most of these were specced at 100Mbps, so now I had the perfect opportunity to do a head to head benchmark showing if the upgrade was worth the effort. I expected a significant performance improvement by replacing the old 100 Mbps router from my ISP, which acted as the hub for every wired and wireless device on my network, with a brand new Gigabit switch. As benchmark, I transferred a 2.3 GB file from my PC to a QNap TS-239 NAS 3 times over the router and switch respectively.
These are the average speeds.
||Speed in MB/s
||Total Tx Time
|NetGear VVG2000 Router
A significant improvement: The transfer is almost 5 times as fast over the Gigabit switch. The measured transfer speed through the NetGear router corresponds well with its specified maximum of 100 Mbps (~12MB/s). With the Gigabit switch, the harddisks of the PC and NAS become the bottlenecks, since we are nowhere near the theoretical maximum of a Gigabit network (120 MB/s).
As a part of the upgrade, I also bought new Cat-6 cables. The oldest cable I still had in use was a Cat-5 and crimbed together by myself about 10 years ago. Since Cat-5 is generally not recommended for Gigabit networks, I thought it would be interesting to see just how much using these old cables would affect transfer speed.
||Speed in MB/s
||Total Tx Time
|Cat-6, 7m, Round
|Cat-6, 10 m, UltraFlat
|Cat-5, 5 m, round
To my surprise, the old Cat-5 cable was on par with the new Cat-6 cables! Luckily, there was not much of the Cat-5 cable to replace, so I won’t be beating myself up over making a useless investment…
I also tested some “UltraFlat” Cat-6 cable, which I was worried would be susceptible to crosstalk, but as the table clearly shows, the performance of the “UltraFlat” cables are equal to that of the regular, round ones.
So, the morale of story is: Don’t be affraid to use UltraFlat cables in your Gigabit network and if you have some old Cat-5 cable buried under your floor or in the wall: Test it with some Gigabit devices before going out of your way to replace it.
This page details my QNap NAS setup and is primarily a reminder to myself of how to install and configure the applications running on it.
Applications installed through QPKG
Applications installed through IPKG
Applications on the PC
Not installed anymore