[opensuse] setting up mysql error
Ok, so I used the following procedure https://en.opensuse.org/SDB:LAMP_setup to set up an apache2 web server, then php7, and then the mysql server with mariadb. Following that procedure in the SDB, it ran great, I was able to set up a small database, connect to it and edit it with phpmyadmin, and was pretty happy with it. Of course, there is one problem with that setup, and that is that it installs all the database files in the root partition. The SDB doesn't give any guidelines for how to move the database to my home partition, which is where I want it to be. So, I tried to move things on my own, and I am sure I messed something up. The directory where the database was installed at first was here: /var/lib/mysql And the directory that had the apache2 web server and phpmyadmin was here: /srv/www/htdocs Also, there was a file, /etc/my.cnf, in which you could change the location of the database. So here is what I did - I shutdown thy mysql service with systemctl stop mysql Then I went into /etc/my.cnf and put in this line where it says to in the file: # Remove leading # if you want to store your database elsewhere datadir = /home/george/FaithWiringDB/dbproj/mysql Then I copied the mysql files from /var/lib/mysql over to /home/george/FaithWiringDB/dbproj/mysql at first I changed the permissions to george:users, but that didn't work so I changed them back to root:root Now, when I tried to do systemctl start mysql.service, it won't start. # systemctl start mysql.service Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details. And here is the error I get: # systemctl status -l mysql ● mysql.service - MySQL server Loaded: loaded (/usr/lib/systemd/system/mysql.service; enabled; vendor preset: disabled) Active: activating (start-post) (Result: exit-code) since Tue 2017-01-31 15:45:43 PHT; 26s ago Process: 15402 ExecStart=/usr/lib/mysql/mysql-systemd-helper start (code=exited, status=1/FAILURE) Process: 15388 ExecStartPre=/usr/lib/mysql/mysql-systemd-helper upgrade (code=exited, status=0/SUCCESS) Process: 15375 ExecStartPre=/usr/lib/mysql/mysql-systemd-helper install (code=exited, status=0/SUCCESS) Main PID: 15402 (code=exited, status=1/FAILURE); : 15403 (mysql-systemd-h) Tasks: 2 (limit: 512) CGroup: /system.slice/mysql.service └─control ├─15403 /bin/bash /usr/lib/mysql/mysql-systemd-helper wait └─15488 sleep 1 Jan 31 15:45:43 facofficeeng02 systemd[1]: Starting MySQL server... Jan 31 15:45:44 facofficeeng02 mysql-systemd-helper[15403]: Waiting for MySQL to start Jan 31 15:45:44 facofficeeng02 mysql-systemd-helper[15402]: 170131 15:45:44 [Note] /usr/sbin/mysqld (mysqld 10.0.28-MariaDB) starting as process 15402 ... Jan 31 15:45:44 facofficeeng02 systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE I am really new to mysql, so any help would be appreciated. How do I get mysql up and running again? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
george from the tribe wrote:
Ok, so I used the following procedure https://en.opensuse.org/SDB:LAMP_setup
to set up an apache2 web server, then php7, and then the mysql server with mariadb. Following that procedure in the SDB, it ran great, I was able to set up a small database, connect to it and edit it with phpmyadmin, and was pretty happy with it. Of course, there is one problem with that setup, and that is that it installs all the database files in the root partition. The SDB doesn't give any guidelines for how to move the database to my home partition, which is where I want it to be.
stop mysql move /var/lib/mysql to where you want it to be amend /etc/my.cnf accordingly. start mysql
The directory where the database was installed at first was here: /var/lib/mysql And the directory that had the apache2 web server and phpmyadmin was here: /srv/www/htdocs
right.
Also, there was a file, /etc/my.cnf, in which you could change the location of the database.
So here is what I did - I shutdown thy mysql service with systemctl stop mysql
Then I went into /etc/my.cnf and put in this line where it says to in the file:
# Remove leading # if you want to store your database elsewhere datadir = /home/george/FaithWiringDB/dbproj/mysql
Then I copied the mysql files from /var/lib/mysql over to /home/george/FaithWiringDB/dbproj/mysql
at first I changed the permissions to george:users, but that didn't work so I changed them back to root:root
Uh, mysql.mysql would be correct. Unless you also changed mysql to run with your userid? To begin with, see what the logs in /var/log/mysql have to say. -- Per Jessen, Zürich (5.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-01-31 11:33, Per Jessen wrote:
george from the tribe wrote:
Ok, so I used the following procedure https://en.opensuse.org/SDB:LAMP_setup
to set up an apache2 web server, then php7, and then the mysql server with mariadb. Following that procedure in the SDB, it ran great, I was able to set up a small database, connect to it and edit it with phpmyadmin, and was pretty happy with it. Of course, there is one problem with that setup, and that is that it installs all the database files in the root partition. The SDB doesn't give any guidelines for how to move the database to my home partition, which is where I want it to be.
stop mysql move /var/lib/mysql to where you want it to be amend /etc/my.cnf accordingly. start mysql
Or symlink the directory. Or bind mount it. The later might avoid starting the service unless home is mounted, I think. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 01/31/2017 06:33 PM, Per Jessen wrote:
george from the tribe wrote:
Ok, so I used the following procedure https://en.opensuse.org/SDB:LAMP_setup
to set up an apache2 web server, then php7, and then the mysql server with mariadb. Following that procedure in the SDB, it ran great, I was able to set up a small database, connect to it and edit it with phpmyadmin, and was pretty happy with it. Of course, there is one problem with that setup, and that is that it installs all the database files in the root partition. The SDB doesn't give any guidelines for how to move the database to my home partition, which is where I want it to be.
stop mysql move /var/lib/mysql to where you want it to be amend /etc/my.cnf accordingly. start mysql
The directory where the database was installed at first was here: /var/lib/mysql And the directory that had the apache2 web server and phpmyadmin was here: /srv/www/htdocs
right.
Also, there was a file, /etc/my.cnf, in which you could change the location of the database.
So here is what I did - I shutdown thy mysql service with systemctl stop mysql
Then I went into /etc/my.cnf and put in this line where it says to in the file:
# Remove leading # if you want to store your database elsewhere datadir = /home/george/FaithWiringDB/dbproj/mysql
Then I copied the mysql files from /var/lib/mysql over to /home/george/FaithWiringDB/dbproj/mysql
at first I changed the permissions to george:users, but that didn't work so I changed them back to root:root
Uh, mysql.mysql would be correct. Unless you also changed mysql to run with your userid?
To begin with, see what the logs in /var/log/mysql have to say.
Ok, great, it started up this morning and I can access phpmyadmin. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/31/2017 06:33 PM, Per Jessen wrote:
george from the tribe wrote:
Ok, so I used the following procedure https://en.opensuse.org/SDB:LAMP_setup
to set up an apache2 web server, then php7, and then the mysql server with mariadb. Following that procedure in the SDB, it ran great, I was able to set up a small database, connect to it and edit it with phpmyadmin, and was pretty happy with it. Of course, there is one problem with that setup, and that is that it installs all the database files in the root partition. The SDB doesn't give any guidelines for how to move the database to my home partition, which is where I want it to be.
stop mysql move /var/lib/mysql to where you want it to be amend /etc/my.cnf accordingly. start mysql
strange that when I moved the database files, it didn't actually move them, but only copied them, even though I had already stopped the mysql server. The originals are still in the original directory, but the new files in the new directory are the ones that are being modified, according to the timestamp. Why would it just copy those files and not move them with the mv command? Anyone else ever experience this? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-01 02:41, george from the tribe wrote:
On 01/31/2017 06:33 PM, Per Jessen wrote:
stop mysql move /var/lib/mysql to where you want it to be amend /etc/my.cnf accordingly. start mysql
strange that when I moved the database files, it didn't actually move them, but only copied them, even though I had already stopped the mysql server. The originals are still in the original directory, but the new files in the new directory are the ones that are being modified, according to the timestamp.
Why would it just copy those files and not move them with the mv command? Anyone else ever experience this?
No, the command mv certainly moves, not copies. But if mysql was not stopped it might recreate them. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
george from the tribe wrote:
On 01/31/2017 06:33 PM, Per Jessen wrote:
george from the tribe wrote:
Ok, so I used the following procedure https://en.opensuse.org/SDB:LAMP_setup
to set up an apache2 web server, then php7, and then the mysql server with mariadb. Following that procedure in the SDB, it ran great, I was able to set up a small database, connect to it and edit it with phpmyadmin, and was pretty happy with it. Of course, there is one problem with that setup, and that is that it installs all the database files in the root partition. The SDB doesn't give any guidelines for how to move the database to my home partition, which is where I want it to be.
stop mysql move /var/lib/mysql to where you want it to be amend /etc/my.cnf accordingly. start mysql
strange that when I moved the database files, it didn't actually move them, but only copied them, even though I had already stopped the mysql server. The originals are still in the original directory, but the new files in the new directory are the ones that are being modified, according to the timestamp.
Why would it just copy those files and not move them with the mv command? Anyone else ever experience this?
Nope, 'mv' has always moved files for me. -- Per Jessen, Zürich (6.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 01 Feb 2017 08:00:26 +0100
Per Jessen
george from the tribe wrote:
strange that when I moved the database files, it didn't actually move them, but only copied them, even though I had already stopped the mysql server. The originals are still in the original directory, but the new files in the new directory are the ones that are being modified, according to the timestamp.
Why would it just copy those files and not move them with the mv command? Anyone else ever experience this?
Nope, 'mv' has always moved files for me.
If mv is moving from one filesystem to another, then it can't do a true move and instead does a cp followed by an rm. If it doesn't have appropriate permissions in the source directory then the rm fails. The result is a copy. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Wed, 01 Feb 2017 08:00:26 +0100 Per Jessen
wrote: george from the tribe wrote:
strange that when I moved the database files, it didn't actually move them, but only copied them, even though I had already stopped the mysql server. The originals are still in the original directory, but the new files in the new directory are the ones that are being modified, according to the timestamp.
Why would it just copy those files and not move them with the mv command? Anyone else ever experience this?
Nope, 'mv' has always moved files for me.
If mv is moving from one filesystem to another, then it can't do a true move and instead does a cp followed by an rm. If it doesn't have appropriate permissions in the source directory then the rm fails. The result is a copy.
Ah, thanks! Something was nagging me about a cross filesystem move, but I couldn't put my finger on it. -- Per Jessen, Zürich (9.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-01 13:11, Dave Howorth wrote:
On Wed, 01 Feb 2017 08:00:26 +0100 Per Jessen
wrote: george from the tribe wrote:
Why would it just copy those files and not move them with the mv command? Anyone else ever experience this?
Nope, 'mv' has always moved files for me.
If mv is moving from one filesystem to another, then it can't do a true move and instead does a cp followed by an rm. If it doesn't have appropriate permissions in the source directory then the rm fails. The result is a copy.
AHHH! (I typically use 'mc' for those ops) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 02/01/2017 07:11 AM, Dave Howorth wrote:
On Wed, 01 Feb 2017 08:00:26 +0100 Per Jessen
wrote: george from the tribe wrote:
strange that when I moved the database files, it didn't actually move them, but only copied them, even though I had already stopped the mysql server. The originals are still in the original directory, but the new files in the new directory are the ones that are being modified, according to the timestamp.
Why would it just copy those files and not move them with the mv command? Anyone else ever experience this? Nope, 'mv' has always moved files for me. If mv is moving from one filesystem to another, then it can't do a true move and instead does a cp followed by an rm. If it doesn't have appropriate permissions in the source directory then the rm fails. The result is a copy.
If the move is on the same filesystem the file is not actually moved, the pointer to where the find the file is changed to point to the new location. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/01/2017 09:36 AM, Ken Schneider - openSUSE wrote:
If the move is on the same filesystem the file is not actually moved, the pointer to where the find the file is changed to point to the new location.
What this amount to is * create a hard link for the file's inode in the directory in the new location * remove unlink) the entry in the directory old location This probably uses the RENAME92) system call. As the man page for that says <quote> Any other hard links to the file (as created using link(2)) are unaffected. Open file descriptors for oldpath are also unaffected. </quote> The link/unlink process does give a small window where both file names work. It is very small but might be significant in fringe cases. Since you are manipulating the inodes you near "x" and "w" permission on both directories rather than just "r" permission. Please do check the man page since there are a few caveats. -- 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
On 01/31/2017 02:47 AM, george from the tribe wrote:
# Remove leading # if you want to store your database elsewhere datadir = /home/george/FaithWiringDB/dbproj/mysql
Then I copied the mysql files from /var/lib/mysql over to /home/george/FaithWiringDB/dbproj/mysql
at first I changed the permissions to george:users, but that didn't work so I changed them back to root:root
Bad move all the way down the line! Start by going back and looking at the ownership and permissions on each of: / /var /var/lib/ /var/lib/mysql Because when a processes want to open a file in /var/lib/mysql it has to traverse all the elements in the path, not just the ownership of the file in that directory. If at any stage along the line it can't read the directory or searched then you get a fail. See PATH_RESOLUTION(7). In step 2 it says <quote> Step 2: walk along the path Set the current lookup directory to the starting lookup directory. Now, for each nonfinal component of the path-name, where a component is a substring delimited by '/' characters, this component is looked up in the current lookup directory. If the process does not have search permission on the current lookup directory, an EACCES error is returned ("Permission denied"). </quote> Now go though the same process using the ID of the service, mysql:mysql, for each of the components of: /home/george/FaithWiringDB/dbproj/mysql and see where the a process with id=mysql, gid-mysql would hit a "Permission denied". I do NOT recommend changing all of you path to completely open permission or making it group mysql. All in all I don't think moving the database like this is a good idea. I can understand you not wanting it to be on the ROOT partition. What I don't understnd is why you have, in that case, /var on the root partition. Regular readers will know that I use LVM to avoid the problem of allocation sizing at install time. I also make use of it for more meaningful partitioning. I have the /var on a separate partition anyway. I also have /home and /srv on separate partitions. Some of the larger things under /home/anton such as `/Photographs also have their own partition. I'd recommend having a separate /var partition very strongly. I'm sure that some very heavily trafficked sites, ISPs, even have /srv and /var on their own physical drives. In that situation the argument for have the SSD for data rather than code is much stronger. -- 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
On 02/01/2017 11:44 AM, Anton Aylward wrote:
On 01/31/2017 02:47 AM, george from the tribe wrote:
# Remove leading # if you want to store your database elsewhere datadir = /home/george/FaithWiringDB/dbproj/mysql
Then I copied the mysql files from /var/lib/mysql over to /home/george/FaithWiringDB/dbproj/mysql
at first I changed the permissions to george:users, but that didn't work so I changed them back to root:root
Bad move all the way down the line!
Start by going back and looking at the ownership and permissions on each of:
/ /var /var/lib/ /var/lib/mysql
Because when a processes want to open a file in /var/lib/mysql it has to traverse all the elements in the path, not just the ownership of the file in that directory. If at any stage along the line it can't read the directory or searched then you get a fail.
See PATH_RESOLUTION(7). In step 2 it says
<quote> Step 2: walk along the path Set the current lookup directory to the starting lookup directory. Now, for each nonfinal component of the path-name, where a component is a substring delimited by '/' characters, this component is looked up in the current lookup directory.
If the process does not have search permission on the current lookup directory, an EACCES error is returned ("Permission denied").
</quote>
Now go though the same process using the ID of the service, mysql:mysql, for each of the components of:
/home/george/FaithWiringDB/dbproj/mysql
and see where the a process with id=mysql, gid-mysql would hit a "Permission denied".
I do NOT recommend changing all of you path to completely open permission or making it group mysql.
All in all I don't think moving the database like this is a good idea. I can understand you not wanting it to be on the ROOT partition. What I don't understnd is why you have, in that case, /var on the root partition.
Regular readers will know that I use LVM to avoid the problem of allocation sizing at install time. I also make use of it for more meaningful partitioning. I have the /var on a separate partition anyway. I also have /home and /srv on separate partitions. Some of the larger things under /home/anton such as `/Photographs also have their own partition.
I'd recommend having a separate /var partition very strongly. I'm sure that some very heavily trafficked sites, ISPs, even have /srv and /var on their own physical drives. In that situation the argument for have the SSD for data rather than code is much stronger.
thanks, that definitely sounds like a better, more secure and stable way of setting it up. I am pretty new to setting up any kind of web-based database with hosting, so I am learning as I go. I will have to adjust things like you mentioned here before the final product goes to launch, in order to make it more stable and secure. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/31/2017 11:18 PM, george from the tribe wrote:
thanks, that definitely sounds like a better, more secure and stable way of setting it up. I am pretty new to setting up any kind of web-based database with hosting, so I am learning as I go. I will have to adjust things like you mentioned here before the final product goes to launch, in order to make it more stable and secure.
Going with the defaults, things being where everyone expects them to be, makes life easier. It might make life easier of you have an accident and someone else has to take over from you (which is why I'm obsessive about documentation!). Im my case, I've set things up, had to deal with something else so what I'd done passed out of my short-term memory, and when I returned to it I was glad I had documented everything. Certainly if ths is going to be a step-and-repeat type of installation, standardization and normalization is a great benefit. Your example 'at home' is configured the way everyone else's is, so that makes upgrades and bug hunting easier. -- 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
On 2017-02-01 05:18, george from the tribe wrote:
thanks, that definitely sounds like a better, more secure and stable way of setting it up. I am pretty new to setting up any kind of web-based database with hosting, so I am learning as I go. I will have to adjust things like you mentioned here before the final product goes to launch, in order to make it more stable and secure.
You could have /srv on a different partition, and then bind mount /var/lib/mysql to somewhere on it. Having a separate partition for data also allows easier upgrades, in case you do fresh installs when the time comes. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 01/02/2017 03:44, Anton Aylward wrote:
Because when a processes want to open a file in /var/lib/mysql it has to traverse all the elements in the path, not just the ownership of the file in that directory. If at any stage along the line it can't read the directory or searched then you get a fail. See PATH_RESOLUTION(7). In step 2 it says <quote> Step 2: walk along the path Set the current lookup directory to the starting lookup directory. Now, for each nonfinal component of the path-name, where a component is a substring delimited by '/' characters, this component is looked up in the current lookup directory. If the process does not have search permission on the current lookup directory, an EACCES error is returned ("Permission denied"). </quote>
That's not how I thought it went ... unless I'm misunderstanding. Simply in order to access a directory, as I understand it, you need "x" permission on it - "cd dir" will succeed if you have that. If you don't know what the file you're looking for is called (that's what I understand by "search") you then need "r" on the directory. But if you know what the file is called, you don't.
Now go though the same process using the ID of the service, mysql:mysql, for each of the components of: /home/george/FaithWiringDB/dbproj/mysql and see where the a process with id=mysql, gid-mysql would hit a "Permission denied". I do NOT recommend changing all of you path to completely open permission or making it group mysql.
On each directory in that path, add permissions "other:x". Then you won't get "permission denied" (unless you accidentally deny the wrong user/group). Obviously, within the final directory, you then need more permissions to access the files you're looking for.
All in all I don't think moving the database like this is a good idea. I can understand you not wanting it to be on the ROOT partition. What I don't understnd is why you have, in that case, /var on the root partition. Regular readers will know that I use LVM to avoid the problem of allocation sizing at install time. I also make use of it for more meaningful partitioning. I have the /var on a separate partition anyway. I also have /home and /srv on separate partitions.
I have /, /var, and /home
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.)
I'd recommend having a separate /var partition very strongly. I'm sure that some very heavily trafficked sites, ISPs, even have /srv and /var on their own physical drives. In that situation the argument for have the SSD for data rather than code is much stronger.
Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/01/2017 10:29 AM, Anthonys Lists wrote:
That's not how I thought it went ... unless I'm misunderstanding.
Simply in order to access a directory, as I understand it, you need "x" permission on it - "cd dir" will succeed if you have that. If you don't know what the file you're looking for is called (that's what I understand by "search") you then need "r" on the directory. But if you know what the file is called, you don't.
Yes you need those permissions, but as the man page makes clear you need it all the way from "/" for each segment of the path, NOT JUST THE FINAL ONE. So in this case, /home/george/FaithWiringDB/dbproj/mysql it is not adequate to just have the '/mysql/' segment and the files in it owned by 'mysql'. But see later...
On each directory in that path, add permissions "other:x". Then you won't get "permission denied" (unless you accidentally deny the wrong user/group). Obviously, within the final directory, you then need more permissions to access the files you're looking for.
Not quite. As I recall the kernel code it reads the entries in the directory to find the one to change into. It depends on your interpretation of "search permission" and whether or not the application is is involved in the step-and-repeat. Some applications start off as "root" to change to the operating directory specified in the master config file and then setuid() to the operating UID. IIR X does that, perhaps Apache. Maybe someone can check that. There's no reason there shouldn't be a shell script that is run as root that reads the config file, changes directory, then executes the actual binary. I've seen that done too, but be careful: its easy to set that up as a security violation. But, oh, wait, look, isn't /usr/lib/mysql/mysql-systemd-helper owned by root, and then, as root, executes the actual server daemon but with parameters that tell it to setuid() and group as well. So this is one of those instances. In which case the previously discussed issues about search path become questionable. It *should* be able to work anywhere, provided the config file is set up consistently. -- 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
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
participants (7)
-
Anthonys Lists
-
Anton Aylward
-
Carlos E. R.
-
Dave Howorth
-
george from the tribe
-
Ken Schneider - openSUSE
-
Per Jessen