[opensuse] What is the best practice to install opensuse Leap 42.3 on a SSD with EXT4?
The system: non(!) UEFI, normal BIOS, AMD video and processor. The SSD is an OWC with 60 GB entirely dedicated to the OS, set as first system disk. The /home is separate on a different disc. So it is about /boot or not /boot? The system will host only(!) Linux, no other OS. Question is, were to put best the boot loader, to minimize problems in the future updates / upgrades. My choice for file system on that machine is EXT4 no encrypted. Mainboard is set to AHCI and running with SATA6. Thank you. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-27 12:21, stakanov wrote:
The system: non(!) UEFI, normal BIOS, AMD video and processor. The SSD is an OWC with 60 GB entirely dedicated to the OS, set as first system disk. The /home is separate on a different disc. So it is about /boot or not /boot?
Why? Normally you do not need a separate boot partition. Certainly not if root is ext4. I think you need with XFS. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
In data martedì 27 febbraio 2018 12:56:29 CET, Carlos E. R. ha scritto:
On 2018-02-27 12:21, stakanov wrote:
The system: non(!) UEFI, normal BIOS, AMD video and processor. The SSD is an OWC with 60 GB entirely dedicated to the OS, set as first system disk. The /home is separate on a different disc. So it is about /boot or not /boot?
Why?
Normally you do not need a separate boot partition. Certainly not if root is ext4. I think you need with XFS. Well this is what I thought. But as you know there is a difference between what you "think / belief / consider true" and what you know(!) to be correct ;-)
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2018-02-27 at 13:03 +0100, stakanov wrote:
In data martedì 27 febbraio 2018 12:56:29 CET, Carlos E. R. ha scritto:
On 2018-02-27 12:21, stakanov wrote:
The system: non(!) UEFI, normal BIOS, AMD video and processor. The SSD is an OWC with 60 GB entirely dedicated to the OS, set as first system disk. The /home is separate on a different disc. So it is about /boot or not /boot?
Why?
Normally you do not need a separate boot partition. Certainly not if root is ext4. I think you need with XFS. Well this is what I thought. But as you know there is a difference between what you "think / belief / consider true" and what you know(!) to be correct ;-)
Well, I can tell you that I don't create a separate /boot when installing on ext4 :-) And I can also say that the last time I tried with XFS I failed, unless grub goes to the MBR. I don't use btrfs, but if I did I would not use separate /boot because it breaks rollback features. If I were to install using raid or lvm, then I would have my doubts, meaning I would have to check. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqVT+wACgkQtTMYHG2NR9UuggCgkyC2cDt+rPr83vkMaRzM4ZUm dToAnRtTYvrliKBXAlMJ2cK6gt+Dvs5u =SgTE -----END PGP SIGNATURE-----
On Tue, Feb 27, 2018 at 3:32 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
And I can also say that the last time I tried with XFS I failed, unless grub goes to the MBR.
XFS does not reserve space for partition boot block so it has to go somewhere else. Either on different partition (it need not be /boot, any partition with free sector 0 would do) or into MBR. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 27.02.2018 um 13:32 schrieb Carlos E. R.:
If I were to install using raid or lvm, then I would have my doubts, meaning I would have to check.
Just did a short test: Installed a VM with 2 disks, mirrored with linux md devices, put a LVM volumegroup vg0 on it and cut a LVM volume called "root", put a ext4 filesystem on it. All done during Installation with yast installer. System installs and is able to boot. No extra boot partition needed: # lsblk -sfi NAME FSTYPE LABEL UUID MOUNTPOINT sr0 vg0-root ext4 618e4ba5-3b9e-4e0a-981b-91a09c179b29 / `-md0 LVM2_member Ahxbrf-Sf7d-Sxfw-YPGu-M7je-TPf1-0gaEwj |-sda1 linux_raid_member any:0 445e40e9-fae4-f8cb-59ae-98386f9b4a44 | `-sda `-sdb1 linux_raid_member any:0 445e40e9-fae4-f8cb-59ae-98386f9b4a44 `-sdb I think booting from Raid5/6 and exotic LVM volumes is not supported, but plain LVM and md mirrors are supported.
Le 27/02/2018 à 12:21, stakanov a écrit :
The system: non(!) UEFI, normal BIOS, AMD video and processor. The SSD is an OWC with 60 GB entirely dedicated to the OS, set as first system disk. The /home is separate on a different disc. So it is about /boot or not /boot? The system will host only(!) Linux, no other OS. Question is, were to put best the boot loader, to minimize problems in the future updates / upgrades. My choice for file system on that machine is EXT4 no encrypted. Mainboard is set to AHCI and running with SATA6. Thank you.
nothing special, with ext4 30Gb is more than necessary, so you can keep two partitions just in case you want to test, say, 42.3 *and* tumbleweed (in addition to swap) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/02/18 06:21 AM, stakanov wrote:
My choice for file system on that machine is EXT4 no encrypted.
So what you are NOT asking is .. What is the best FS to use with a SSD? That is something I've always wondered about. I have my own prejudices about ext4, that I've discussed before, but the careening juggernaut seems to be that or BtrFS with only outliers like Linda saying otherwise. In Leamington Spa in England there is a team called the "Leamington Lemmings" and the fans can, quite reasonably, yes "Go! Lemmings, Go!". In other contexts its something I yell with opprobrium. Context is Everything. https://www.telegraph.co.uk/men/thinking-man/leamington-spa-happiest-place-b... -- 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
In data martedì 27 febbraio 2018 14:02:15 CET, Anton Aylward ha scritto:
On 27/02/18 06:21 AM, stakanov wrote:
My choice for file system on that machine is EXT4 no encrypted.
So what you are NOT asking is ..
What is the best FS to use with a SSD?
That is something I've always wondered about. I have my own prejudices about ext4, that I've discussed before, but the careening juggernaut seems to be that or BtrFS with only outliers like Linda saying otherwise.
In Leamington Spa in England there is a team called the "Leamington Lemmings" and the fans can, quite reasonably, yes "Go! Lemmings, Go!". In other contexts its something I yell with opprobrium. Context is Everything. https://www.telegraph.co.uk/men/thinking-man/leamington-spa-happiest-place-b ritain/ > Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon? No, I am not, because: a) I tried btrfs and xfs (like the default). Sorry for giving Richard a bad time, but I experienced: a very complicated system of partitions that in case is making repairs not really handy. b) expecially with xfs I had (after crashes that - to the countrary to what one may expect - were not so rare as they should be) always repairs to do with manual steps to be done, with EXT4 never any problem. c) I did not experience any(!) performance problem with any of the FS, so substantially with my experience and my hardware I do not have particular advantage in this point. d) I am particular conservative on that machine, run leap and do not experiment. It has amd and not nvidia (that is you do not need the rollback every 5 minutes because the industry fucked it up another time. e) am am not aware of any "better" file system for ssd. I you know you can suggest, but by my performance pattern I do not even see a problem havin a swap on my machine (which will be used anyway only for suspend).
So? _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/02/18 08:16 AM, stakanov wrote:
In data martedì 27 febbraio 2018 14:02:15 CET, Anton Aylward ha scritto:
On 27/02/18 06:21 AM, stakanov wrote:
My choice for file system on that machine is EXT4 no encrypted.
So what you are NOT asking is ..
What is the best FS to use with a SSD?
No, I am not, because:
a) I tried btrfs and xfs (like the default). Sorry for giving Richard a bad time, but I experienced: a very complicated system of partitions that in case is making repairs not really handy.
Agreed. Similar experiences with rotating rust.
b) expecially with xfs I had (after crashes that - to the countrary to what one may expect - were not so rare as they should be) always repairs to do with manual steps to be done, with EXT4 never any problem.
I've had one bad experience with XFS but the user group was helpful. Never the less for what it takes, I don't care for XFS compared to others. But the 'others' don't lead me to ext4.
c) I did not experience any(!) performance problem with any of the FS, so substantially with my experience and my hardware I do not have particular advantage in this point.
The problems I have with ext4 are the same I had with UNIX V7's Fs back in the 1970, with the Berkeley FastFileSystem in the 1980s, and so on down the line through SCO, Convergent and others and earlier versions of Linux. There is a fixed division between inodes and data, and you have to specify that at mkfs time. It is softened if you have a huge disk, but it hasn't gone away. The thing is that the B-tree technology that gets around this problem has been with us for a long time: XFS, JFS, ReiserFS. All decades old, older then ext4, and don't have that problem. I've used JFS and ReiserFS extensively and they are *VERY* reliable. "Age does not wither" - to paraphrase the Bard. Performance? Performance at WHAT? The FS perform differently ,very differently under different types of tests. I've also tried running big-name database system on raw partitions rather than file systems to compare, and that gives a notable edge. By comparison, XFS works just great with BIG files, like movies (I have none under 1Meg and most are over 1000Meg) or music (typically 5Meg but a couple of soundtracks out at 33Meg). Then there's photos. I shoot RAW for the bulk of my unprocessed images are either 16Meg or 24Meg and JPGs ranging from a few hundred kb up to as much 50G for a stitched together panorama.
d) I am particular conservative on that machine, run leap and do not experiment. It has amd and not nvidia (that is you do not need the rollback every 5 minutes because the industry fucked it up another time.
Granted. I'm obsessive about stability and reliability on production machines, which is one reason I use Reiser and JFS rather than ext4. See above. Once I ran out of inodes under ext4 when there was quite ample data space. It puzzled the users and the then sysadmin. NEVER AGAIN! NEVER!
e) am am not aware of any "better" file system for ssd. I you know you can suggest, but by my performance pattern I do not even see a problem havin a swap on my machine (which will be used anyway only for suspend).
There have been file systems specifically designed for SSD by concerned vendors. Samsung designed F2FS specifically for NAND gate technology. The reasoning is: why find a file system that plays nice with an SSD when there is one specifically built for it? Another FS built specifically for SSD is IotaFS. I've no notes on that other than the original design paper. As far as I can gather that is based on the Minix2FS and has the same inode/data separation problems as the V7FS and ext4. Of course such matters as alignment, journalling, blocking factor, span sizes, and possibly other factors will severely affect the performance of a a file system, and as such might be more noticeable in percentage terms with a SSD. -- 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
In data martedì 27 febbraio 2018 17:53:26 CET, Anton Aylward ha scritto:
On 27/02/18 08:16 AM, stakanov wrote:
In data martedì 27 febbraio 2018 14:02:15 CET, Anton Aylward ha scritto:
On 27/02/18 06:21 AM, stakanov wrote:
My choice for file system on that machine is EXT4 no encrypted.
So what you are NOT asking is ..
What is the best FS to use with a SSD?
No, I am not, because:
a) I tried btrfs and xfs (like the default). Sorry for giving Richard a bad time, but I experienced: a very complicated system of partitions that in case is making repairs not really handy.
Agreed. Similar experiences with rotating rust.
b) expecially with xfs I had (after crashes that - to the countrary to what one may expect - were not so rare as they should be) always repairs to do with manual steps to be done, with EXT4 never any problem.
I've had one bad experience with XFS but the user group was helpful. Never the less for what it takes, I don't care for XFS compared to others.
But the 'others' don't lead me to ext4.
c) I did not experience any(!) performance problem with any of the FS, so substantially with my experience and my hardware I do not have particular advantage in this point.
The problems I have with ext4 are the same I had with UNIX V7's Fs back in the 1970, with the Berkeley FastFileSystem in the 1980s, and so on down the line through SCO, Convergent and others and earlier versions of Linux.
There is a fixed division between inodes and data, and you have to specify that at mkfs time. It is softened if you have a huge disk, but it hasn't gone away.
The thing is that the B-tree technology that gets around this problem has been with us for a long time: XFS, JFS, ReiserFS. All decades old, older then ext4, and don't have that problem.
I've used JFS and ReiserFS extensively and they are *VERY* reliable. "Age does not wither" - to paraphrase the Bard.
Performance? Performance at WHAT? The FS perform differently ,very differently under different types of tests. I've also tried running big-name database system on raw partitions rather than file systems to compare, and that gives a notable edge. By comparison, XFS works just great with BIG files, like movies (I have none under 1Meg and most are over 1000Meg) or music (typically 5Meg but a couple of soundtracks out at 33Meg). Then there's photos. I shoot RAW for the bulk of my unprocessed images are either 16Meg or 24Meg and JPGs ranging from a few hundred kb up to as much 50G for a stitched together panorama.
d) I am particular conservative on that machine, run leap and do not experiment. It has amd and not nvidia (that is you do not need the rollback every 5 minutes because the industry fucked it up another time.
Granted. I'm obsessive about stability and reliability on production machines, which is one reason I use Reiser and JFS rather than ext4. See above. Once I ran out of inodes under ext4 when there was quite ample data space. It puzzled the users and the then sysadmin.
NEVER AGAIN! NEVER!
e) am am not aware of any "better" file system for ssd. I you know you can suggest, but by my performance pattern I do not even see a problem havin a swap on my machine (which will be used anyway only for suspend).
There have been file systems specifically designed for SSD by concerned vendors.
Samsung designed F2FS specifically for NAND gate technology. The reasoning is: why find a file system that plays nice with an SSD when there is one specifically built for it?
Another FS built specifically for SSD is IotaFS. I've no notes on that other than the original design paper. As far as I can gather that is based on the Minix2FS and has the same inode/data separation problems as the V7FS and ext4.
Of course such matters as alignment, journalling, blocking factor, span sizes, and possibly other factors will severely affect the performance of a a file system, and as such might be more noticeable in percentage terms with a SSD. > Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
Well, before Reiser FS got "out of fashion", I was very happy with it. I never really understood why the development stopped on it (unless it was a one man show, then the reason was a dead wife. Sorry for the black humor, I am aware it was not funny for the wife). F2FS I was not aware opensuse offered it...does it? I do understand your issue with I inodes, but I am dead sure it will not happen to me ever with my uses cases. Finally I did the install with grub written to / and the whole as standard swap and ext4. Seems to run well. Thank you for all the info, will have a look at the future of F2FS. Samsung seems quite active with OSS recently...... _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/02/18 01:31 AM, stakanov wrote:
Well, before Reiser FS got "out of fashion", I was very happy with it. I never really understood why the development stopped on it (unless it was a one man show, then the reason was a dead wife. Sorry for the black humor, I am aware it was not funny for the wife).
Hans was the designer; it was coded by a team. The members of the team are still around and it is being supported and even Reiser4 is having work done on it. But it's no longer corporate; no-one is paying them and they get a lot of anguish from people saying what you're saying. HOWEVER it turns out that Hans was one of those brilliant people who was crazy-brilliant. As in "insanely brilliant" with the emphasis on insane, insane enough to be a murderer. But the design of ReiserFS is brilliant and unlike BtrFS and other file systems "he got it right the first time". Compared to other FS ReiserFS has had little work done on it because it never needed it. Hans got it right the first time. The real problem with ReiserFS is that even though Resiser4FS is pretty damn good, probably better than BtrFS or ext4, there isn't the commitment/popularity and it's really a one-man show and it hasn't the 'pressure' to be accepted into the kernel and so it's never going to see popular support. Chicken and egg in reverse.
F2FS I was not aware opensuse offered it...does it?
Take a look in /lib/modules/$(uname -r)/kernel/fs I'm running a late model kernel out of the kernel_stable repository and F2FS is there. And others. The real downside of current ReiserFS is that it is single threaded. It was designed before multi-core CPUS were common and before there were muti-terabte drives with lots-a-lot file systems for PCs. Reiser4 was to address that. I'm managing my terabyte drives with LVM and partition geared to make backup on 5G DVD easy. Comparatively speaking. So each terabyte drive has a minimum of 25 file systems, maybe as many as 40. And of course more get created as LVM snapshots for during backup. Let's not even talk about thin provisioning. It got the point where lack of multi threading was limiting. So I'm converting my ReiserFS to JFS. I'm pleased with the results so far.
I do understand your issue with I inodes, but I am dead sure it will not happen to me ever with my uses cases.
After years of running UNIX V7 ... SYSIII ... SYSV ... SCO ... ext2 I never though it would happen to me, either. The I got hit by ext4.
Finally I did the install with grub written to / and the whole as standard swap and ext4. Seems to run well.
That's nice. I think you mean /boot. Where's your MBR?
Thank you for all the info, will have a look at the future of F2FS. Samsung seems quite active with OSS recently......
Solid state devices are, for the most part log-structured mechanisms at heart, so 'log structured' files system that make use of this have an edge. See also https://en.wikipedia.org/wiki/JFFS2 which is in the kernel and which refers to https://en.wikipedia.org/wiki/YAFFS https://en.wikipedia.org/wiki/UBIFS - which performs better than JFFS2 on larger devices and https://en.wikipedia.org/wiki/LogFS that aren't. LogFS worked, was in the kernel, but attracted not enough users to warrant staying there. There's also the pretty advanced https://en.wikipedia.org/wiki/NILFS though sometimes I wonder if its too advanced for the current user base., so much of it is 64-bit. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2018-02-28 at 02:18 -0500, Anton Aylward wrote:
On 28/02/18 01:31 AM, stakanov wrote:
Well, before Reiser FS got "out of fashion", I was very happy with it. I never really understood why the development stopped on it (unless it was a one man show, then the reason was a dead wife. Sorry for the black humor, I am aware it was not funny for the wife).
Hans was the designer; it was coded by a team. The members of the team are still around and it is being supported and even Reiser4 is having work done on it. But it's no longer corporate; no-one is paying them and they get a lot of anguish from people saying what you're saying.
HOWEVER it turns out that Hans was one of those brilliant people who was crazy-brilliant. As in "insanely brilliant" with the emphasis on insane, insane enough to be a murderer. But the design of ReiserFS is brilliant and unlike BtrFS and other file systems "he got it right the first time". Compared to other FS ReiserFS has had little work done on it because it never needed it. Hans got it right the first time.
The real problem with ReiserFS is that even though Resiser4FS is pretty damn good, probably better than BtrFS or ext4, there isn't the commitment/popularity and it's really a one-man show and it hasn't the 'pressure' to be accepted into the kernel and so it's never going to see popular support. Chicken and egg in reverse.
Right...
F2FS I was not aware opensuse offered it...does it?
Take a look in /lib/modules/$(uname -r)/kernel/fs I'm running a late model kernel out of the kernel_stable repository and F2FS is there. And others.
The real downside of current ReiserFS is that it is single threaded. It was designed before multi-core CPUS were common and before there were muti-terabte drives with lots-a-lot file systems for PCs. Reiser4 was to address that.
I joined all my reiserfs partitions into a single one, and mounted bind the old mountpoints. For the moment.
I'm managing my terabyte drives with LVM and partition geared to make backup on 5G DVD easy. Comparatively speaking. So each terabyte drive has a minimum of 25 file systems, maybe as many as 40. And of course more get created as LVM snapshots for during backup. Let's not even talk about thin provisioning.
It got the point where lack of multi threading was limiting. So I'm converting my ReiserFS to JFS. I'm pleased with the results so far.
How does JFS compare to ReiserFS? Specially regarding small files. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqWjksACgkQtTMYHG2NR9XsmACff3GioUDuYr+7VnMP2qx9SnwY UicAnROlUAs9TFNoFW3/NKgNbSxRhxdc =5vXY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
How does JFS compare to ReiserFS?
It's still very much alive.
Specially regarding small files.
It handles small files very well :-) -- Per Jessen, Zürich (-5.2°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 28/02/18 06:11 AM, Carlos E. R. wrote:
How does JFS compare to ReiserFS?
It handles multi-threading extremely well. I have a thread running on each of my CPU cores. As far as I can make out they are 'pooled' in that the threading is really multi-tasking and not dedicated to one FS.
Specially regarding small files.
Well, it doesn't pack them the way that ReiserFS does so it isn't as space efficient. But in terms of access, it seems to handle them damn well. I'm using it initially on my on-line photo 'archives', a partition/FS per year, and as I edit using Darktable the original RAW files are left unchanged and the list of edits stored in a sidecar file. So I have the huge 1Meg or 25Meg RAW files and a smaller sidecar file that may vary between about 1K and less than 10k, typically less than 4k. I'm not sure that ReiserFS will aggressively pack the 1.5k ... 2K files into the 4K blocks. So there doesn't seem to be much difference in space consumption. The difference I do see is in crash recovery. Both ReiserFS and JFS seem pretty indestructible! However on rebooting after a powerout crash I see delays as the ReiserFS does its FSCK stuff. No worries; that's reassuring, isn't it? But JFS has the journal and structure is preserved damn well, so it recovers FAST! (I don't know yes about having the journal on a separate device, but that consideration applies to other FS that use journals as well.) In both cases I'm not worried about loosing open files. As I said, this is photo stuff and the way Darktable works is that RAW file is left along and the changes/edits are in the sidebar file. I can't loose either of those on a crash, only the in-memory changes, unless the crash occurs at the instance I'm updating the sidecar file. But the 'create new/delete old' sequence means I still have the 'old'. Reliability by Design -- even on the layer above the FS. Would that more applications observed that kind of 'defensive programming'! Compression? "If and when"! Yes, but I'm not planning on using it. It doesn't offer much when it comes to RAW photo images or JPGs The conclusion is that I'm quite satisfied with JFS a an alternative to ReiserFS. https://en.wikipedia.org/wiki/Journaling_file_system https://en.wikipedia.org/wiki/JFS_(file_system) in particular see "Dynamic Inode Allocation" <quote> According to reviews[which?] and benchmarks[which?] of the available filesystems for Linux, JFS is fast and reliable, with consistently good performance under different kinds of load, contrary to other filesystems that seem to perform better under particular usage patterns, for instance with small or large files. Another characteristic often mentioned, is that it is light and efficient with available system resources and even heavy disk activity is realized with low CPU usage. </quote> http://jfs.sourceforge.net/project/pub/jfs.pdf http://jfs.sourceforge.net/project/pub/jfslayout.pdf - more than you need -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2018-02-28 at 10:55 -0500, Anton Aylward wrote:
On 28/02/18 06:11 AM, Carlos E. R. wrote:
How does JFS compare to ReiserFS?
It handles multi-threading extremely well. I have a thread running on each of my CPU cores. As far as I can make out they are 'pooled' in that the threading is really multi-tasking and not dedicated to one FS.
Specially regarding small files.
Well, it doesn't pack them the way that ReiserFS does so it isn't as space efficient. But in terms of access, it seems to handle them damn well.
Ok.
Reliability by Design -- even on the layer above the FS. Would that more applications observed that kind of 'defensive programming'!
Compression? "If and when"! Yes, but I'm not planning on using it. It doesn't offer much when it comes to RAW photo images or JPGs
Does it support compression? It does make a difference for email. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqXCVQACgkQtTMYHG2NR9Ws6ACfUzDVwKFEsG2go4x+4LTruqSA qtYAmwfNc1Q90j44dqiy90xXvtwh3hCy =6Kng -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2018-02-27 at 11:53 -0500, Anton Aylward wrote:
b) expecially with xfs I had (after crashes that - to the countrary to what one may expect - were not so rare as they should be) always repairs to do with manual steps to be done, with EXT4 never any problem.
I've had one bad experience with XFS but the user group was helpful. Never the less for what it takes, I don't care for XFS compared to others.
But the 'others' don't lead me to ext4.
I use XFS on all my data partitions and I'm happy. Yes, I did experience some problems, but the developer community is fast at curing them. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqWjrQACgkQtTMYHG2NR9VSLgCfXte/tGTJFB8+XS/VnF3VFrgu tw4Anj2tpS0/rq95/tcu43X8daD/a9QL =n68G -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 27 Feb 2018 08:02:15 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
What is the best FS to use with a SSD?
Controversial opinion. Not official SUSE advice despite my email address! I use ext2 for new installs on ssd (and USB keys), and then set "noatime" in /etc/fstab, in order to minimise disk writes. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2018-02-27 at 14:35 +0100, Liam Proven wrote:
On Tue, 27 Feb 2018 08:02:15 -0500 Anton Aylward <> wrote:
What is the best FS to use with a SSD?
Controversial opinion. Not official SUSE advice despite my email address!
I use ext2 for new installs on ssd (and USB keys), and then set "noatime" in /etc/fstab, in order to minimise disk writes.
You could use ext4 (because it has "extents"), made this way: mke2fs -t ext4 -O ^has_journal /dev/device or tune2fs -O ^has_journal <ext3/4-device> Without extents requires more accesses to read/write large files to the disk. (info from <http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick>) Also, you could use "lazytime" instead of "noatime". - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqVZoQACgkQtTMYHG2NR9XTQACeJ3LXU+B++/Mq1GsnliD/fHz2 79EAoJDapQOtfuV70gKFBxMCfEG1IsyJ =lAuZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/02/18 09:09 AM, Carlos E. R. wrote:
Also, you could use "lazytime" instead of "noatime".
Yes, that and eliminating the journal reduces the number of times the disk gets 'hit'. But from an integrity POV removing the journal on a production device worries me. The reference you give for the USB stick, well, yes, OK. -- 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 Tue, 27 Feb 2018 17:31:25 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
Yes, that and eliminating the journal reduces the number of times the disk gets 'hit'.
Exactly. That's the point of the exercise.
But from an integrity POV removing the journal on a production device worries me. The reference you give for the USB stick, well, yes, OK.
I am not 100% certain of this, but in my fairly limited experience of Flash device failure, the failure mode is significantly different from that of spinning HDs. HDs degrade slowly and blocks can become unreadable or writable. A journal can help you to survive this. Flash devices tend to fail suddenly and completely and journalling is no help -- everything is gone. So I have an unsubstantiated suspicion that in real life a journalling FS won't help you with a failing SSD, but the existence of the journal may bring about that failure quicker. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2018-02-28 at 10:54 +0100, Liam Proven wrote:
On Tue, 27 Feb 2018 17:31:25 -0500 Anton Aylward <> wrote:
Yes, that and eliminating the journal reduces the number of times the disk gets 'hit'.
Exactly. That's the point of the exercise.
But from an integrity POV removing the journal on a production device worries me. The reference you give for the USB stick, well, yes, OK.
I am not 100% certain of this, but in my fairly limited experience of Flash device failure, the failure mode is significantly different from that of spinning HDs.
HDs degrade slowly and blocks can become unreadable or writable. A journal can help you to survive this.
Flash devices tend to fail suddenly and completely and journalling is no help -- everything is gone.
So I have an unsubstantiated suspicion that in real life a journalling FS won't help you with a failing SSD, but the existence of the journal may bring about that failure quicker.
A journal helps in the case of normal filesystem crash, like a power failure. Recovery is certainly faster, and perhaps (this is where I have doubts) more complete. In the case of an SSD random access is very fast, so it would compensate the lack of journal. Would still some actions be missing? I don't know. In the case of USB stick it is worth it (they don't resist that many writings), but in the case of SSD I have gone for "normal" settings. I don't know what the life of the device will be, I expect several years. In any case, at least on the desktop machine, a cron job does a backup to rust, just in case. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqWjDQACgkQtTMYHG2NR9Xr2wCcD8pDsydNC5c5ThZAjeGJbIH1 8OIAn0ZTMrr0ghV8UtcIu8nLc9iIpS+r =e1+d -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 27 Feb 2018 15:09:00 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
You could use ext4 (because it has "extents"), made this way:
mke2fs -t ext4 -O ^has_journal /dev/device
or
tune2fs -O ^has_journal <ext3/4-device>#
Yes, I have tried that on some machines when migrating an installation from HD to SSD.
Without extents requires more accesses to read/write large files to the disk.
A fair point, but I suspect that I personally seldom use large files. I often use tmpfs for /tmp meaning that I can't have temporary files bigger than RAM, and the single time I hit a problem was burning a DVD on a machine with only 4GB RAM.
Also, you could use "lazytime" instead of "noatime".
That's a new one on me. Thanks for that. I don't use maildir and that's the only thing I know that needs atimes, so none at all seems simpler. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
stakanov wrote:
The system: non(!) UEFI, normal BIOS, AMD video and processor. The SSD is an OWC with 60 GB entirely dedicated to the OS, set as first system disk. The /home is separate on a different disc.
Sounds much like my test desktop - 80Gb SSD, but /home on the same disk.
So it is about /boot or not /boot? The system will host only(!) Linux, no other OS. Question is, were to put best the boot loader, to minimize problems in the future updates / upgrades. My choice for file system on that machine is EXT4 no encrypted.
I use jfs and no separate separate partition for /boot. -- Per Jessen, Zürich (-5.7°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
participants (8)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Florian Gleixner -
jdd＠dodin.org -
Liam Proven -
Per Jessen -
stakanov