On 02/01/2017 10:29 AM, Anthonys Lists wrote:
Some of the larger things under /home/anton such as `/Photographs also have their own partition.
Running a "home server", I actually *don't* keep my photos on a separate partition. I think there are ways round it, but all our photos have their own folder - /home/pictures - and are symlinked into ~/Pictures. But the same photo may be symlinked into multiple ~s. (And they're usually owned root:root 644, so they can't be modified or deleted.)
This is Linux. There are usually "ways round it", but just because you can doesn't mean you should. I believe in the KISS principle, the corollary of which is 'keep it obvious so as to be maintainable'. I'm the only person on my home system and all of the photos are 'editable'. I use Darktable which does not actually edit the source image, but rather constructs a list of the changes to be made, so, in my case, my camera produces a RAW and I can derive multiple jpegs (or even tiffs) from it. And I do. So there is no need to write protect the RAW files and certainly no requirement to make the directories write protected. I do a lot of revisions for a wide variety of reasons. Organizing, especially be date or by project/event is more important. Its a 'use case' issue. And its a LOT of space. I want to be able to back up the rest of ~anton/ separately. Its simpler to have a separate partition and use the "-one-file-system" (don't cross filesystem boundaries) of rsync (and other tools). There's also the issue of optimization. Image files tend to run tens of megabytes, larger on average, than music files but smaller than videos. However the music files and video files are on file systems that have no churn. The photography file systems have a lot of churn as new images are derived and the pertinent databases that list and manage the transformations are updated. <rant> I realist that an ext4FS *could* be tuned for any of this, but it gets back to a matter of provisioning. The ext4FS is stuck in the 1970s concept associated with the old V7 UNIX file system, that there number of inodes and the number of data blocks is determined and fixed at mkfs time. Other modern file systems, XFS, ReiserFS, BtrFS, are all B-tree allocation based and don't suffer this ridiculous, archaic limitation. For some reason that I don't understand, ext4FS uses b-trees for space management, but can't make this cross-over. Much as all three of those three file systems have other limitations and annoyances this one aspect is the killer or me as far as ext4FS goes. </rant> -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org