[opensuse-factory] Can you explain some of the changes in 13.2 for an article?
I noticed the YaST installer is far faster. One explanation I got was that it was making less mkinitrd calls. Could you elaborate? I know that SLED is using XFS for it's home and that is part of why we are using it. Why this choice? Why not EXT4 as in the past or btrfs like root? I've heard reasons why it's better but could someone elaborate on the underlying mechanisms leading to the superiority of XFS for the home partition? On my previous Tumbleweed installation, it had GNOME 3.12 like the beta. However on the beta it is much much more responsive in regards to searches as well as the animations being many factors smoother. Can you give some reasons? Security: when desktop logs in, the keyring needs authentication complaining it wasn't unlocked on log in. Is this deliberate? In order to add a new WiFi connection, administrative authentication is needed, is this intentional as it had been in the past (when Linus Torvalds cussed us out)? YaST2/AppArmor module hasn't been fixed for the new rule types. Will this be fixed for release or shortly after? https://bugzilla.novell.com/show_bug.cgi?id=900013 Thank you for your time. I want to drive up some excitement to get more people tinkering on the beta. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Oct 7, 2014 at 2:40 PM, Roger Luedecke <roger.luedecke@gmail.com> wrote:
I noticed the YaST installer is far faster. One explanation I got was that it was making less mkinitrd calls. Could you elaborate?
I know that SLED is using XFS for it's home and that is part of why we are using it. Why this choice? Why not EXT4 as in the past or btrfs like root? I've heard reasons why it's better but could someone elaborate on the underlying mechanisms leading to the superiority of XFS for the home partition?
https://www.suse.com/communities/conversations/xfs-the-file-system-of-choice... https://www.suse.com/communities/conversations/ext4-still-not-there-yet-and-...
On my previous Tumbleweed installation, it had GNOME 3.12 like the beta. However on the beta it is much much more responsive in regards to searches as well as the animations being many factors smoother. Can you give some reasons?
Security: when desktop logs in, the keyring needs authentication complaining it wasn't unlocked on log in. Is this deliberate? In order to add a new WiFi connection, administrative authentication is needed, is this intentional as it had been in the past (when Linus Torvalds cussed us out)? YaST2/AppArmor module hasn't been fixed for the new rule types. Will this be fixed for release or shortly after? https://bugzilla.novell.com/show_bug.cgi?id=900013
Thank you for your time. I want to drive up some excitement to get more people tinkering on the beta.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 07/10/14 a las #4, Roger Luedecke escribió:
I noticed the YaST installer is far faster. One explanation I got was that it was making less mkinitrd calls. Could you elaborate?
IN the past, mkinitrd was ran every time a package requested to do so ..this causes one mkinitrd call for each package with initrd hooks (lvm, device-mapper, kernel, multipath-tools, etc..etc..). For example on systems with SSD drives and/or really fast internet access, the constant recreation of the initrd consumed most of the overall time of the package installation process. In the current codestream mkinitrd should be ran only once at the end of the transaction. Buggy packages still exist and need fixing but the overall situation as improved dramatically.
I know that SLED is using XFS for it's home and that is part of why we are using it. Why this choice?
You will have to ask filesystem people..I have no clue about this.
On my previous Tumbleweed installation, it had GNOME 3.12 like the beta. However on the beta it is much much more responsive in regards to searches as well as the animations being many factors smoother. Can you give some reasons?
Security: when desktop logs in, the keyring needs authentication complaining it wasn't unlocked on log in. Is this deliberate? In order to add a new WiFi connection, administrative authentication is needed, is this intentional as it had been in the past (when Linus Torvalds cussed us out)? YaST2/AppArmor module hasn't been fixed for the new rule types. Will this be fixed for release or shortly after? https://bugzilla.novell.com/show_bug.cgi?id=900013
Thank you for your time. I want to drive up some excitement to get more people tinkering on the beta.
Same here, those are questions gnome people have the answer.. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2014-10-07 at 15:58 -0300, Cristian Rodríguez wrote:
I noticed the YaST installer is far faster. One explanation I got was that it was making less mkinitrd calls. Could you elaborate?
IN the past, mkinitrd was ran every time a package requested to do so ..this causes one mkinitrd call for each package with initrd hooks (lvm, device-mapper, kernel, multipath-tools, etc..etc..).
For example on systems with SSD drives and/or really fast internet access, the constant recreation of the initrd consumed most of the overall time of the package installation process.
In the current codestream mkinitrd should be ran only once at the end of the transaction. Buggy packages still exist and need fixing but the overall situation as improved dramatically. I noticed too though, that just going from page to page and such in the installer was massively faster. Is that simply due to the Ruby implimentation?
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 07/10/14 a las #4, Roger Luedecke escribió:
I noticed too though, that just going from page to page and such in the installer was massively faster. Is that simply due to the Ruby implimentation?
That's not very likely. Something else other than the particular language used for the implementation is the cause of the speed up.. it may actually even be a bug :-) . The most likely cause is re-factoring/rewriting of the code in question which was quite old already. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Oct 7, 2014 at 2:40 PM, Roger Luedecke <roger.luedecke@gmail.com> wrote:
I know that SLED is using XFS for it's home and that is part of why we are using it. Why this choice? Why not EXT4 as in the past or btrfs like root? I've heard reasons why it's better but could someone elaborate on the underlying mechanisms leading to the superiority of XFS for the home partition?
-- I think I have this right. Listen to that video link to confirm, or just post to the XFS mailing list and ask Dave Chinner to review the below text: ============= XFS was designed for high-end systems including supercomputers. The design is 20 years old, so many of the features it incorporates work well on current multi-core laptops and PCs. During the decade from 2000-2010, XFS had a well deserved reputation of working very inefficiently with small files. In the 2010/2011 timeframe XFS received major improvements related to metadata handling. This had a huge positive impact on how well XFS works with small files. The key concept is that journal is now maintained initially in RAM. Prior to streaming a large junk of journal information to the disk journal, it is now elevator sorted. That means when the actual on disk updates are done by applying the journal, the disk head will follow a series of disk seeks all in the same direction. This drastically cut down on long disk head seeks when working applying the journal. The end result was drastically faster speeds when working with small files on rotating media. ext4 on the other hand was designed for previoius generation computers. Although it can scale to the sizes needed today, it simply was not designed to handle that heavy workloads and massive scaling that modern laptops and desktops can demand. As such, ext4 is rapidly approaching end of life. The envisioned replacement for ext4 for the last several years has been btrfs. Unfortunately, btrfs has not yet achieved the performance levels needed to take on heavy workloads. ============ All of the above is from my memory of the video. I watched it a year or more ago, so those with more current knowledge please correct as appropriate. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Greg, I think the text is mostly fine, but... Am 07.10.2014 um 20:58 schrieb Greg Freemyer:
XFS was designed for high-end systems including supercomputers. The design is 20 years old, so many of the features it incorporates work well on current multi-core laptops and PCs.
...I cannot really get from "designed 20 years ago" to "so it works well on current PCs" :-) But that's really a minor nit in your well written description of the current state of ext4 vs xfs. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Oct 14, 2014 at 1:21 PM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Hi Greg,
I think the text is mostly fine, but...
Am 07.10.2014 um 20:58 schrieb Greg Freemyer:
XFS was designed for high-end systems including supercomputers. The design is 20 years old, so many of the features it incorporates work well on current multi-core laptops and PCs.
...I cannot really get from "designed 20 years ago" to "so it works well on current PCs" :-)
How's this: == Having been designed for supercomputers from the mid-90's, XFS is able to leverage the advanced CPU, RAM and RAID feature sets common in today's laptops, desktops, and servers. The key features ext4 does not leverage well include multi-core CPUs, large amounts of RAM and dedicated RAID hardware. == The RAID part may be misleading. I'm not sure how ext4 handles that. XFS will try to assemble an entire RAID5 or RAID6 stripe and write in one whack. That eliminates the typical read / modify / write sequence needed when working with parity raid. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El Martes, 14 de octubre de 2014 15:46:19 Greg Freemyer escribió:
On Tue, Oct 14, 2014 at 1:21 PM, Stefan Seyfried
<stefan.seyfried@googlemail.com> wrote:
Hi Greg,
I think the text is mostly fine, but...
Am 07.10.2014 um 20:58 schrieb Greg Freemyer:
XFS was designed for high-end systems including supercomputers. The design is 20 years old, so many of the features it incorporates work well on current multi-core laptops and PCs.
...I cannot really get from "designed 20 years ago" to "so it works well on current PCs" :-)
How's this:
== Having been designed for supercomputers from the mid-90's, XFS is able to leverage the advanced CPU, RAM and RAID feature sets common in today's laptops, desktops, and servers. The key features ext4 does not leverage well include multi-core CPUs, large amounts of RAM and dedicated RAID hardware. ==
The RAID part may be misleading. I'm not sure how ext4 handles that. XFS will try to assemble an entire RAID5 or RAID6 stripe and write in one whack. That eliminates the typical read / modify / write sequence needed when working with parity raid.
Greg
Hi. Support for multi-core CPUs is transparent or it needs a mount option? Last time I used XFS was slow deleting files, has it been improved? Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Oct 14, 2014 at 4:08 PM, jcsl <trcs@gmx.com> wrote:
El Martes, 14 de octubre de 2014 15:46:19 Greg Freemyer escribió:
On Tue, Oct 14, 2014 at 1:21 PM, Stefan Seyfried
<stefan.seyfried@googlemail.com> wrote:
Hi Greg,
I think the text is mostly fine, but...
Am 07.10.2014 um 20:58 schrieb Greg Freemyer:
XFS was designed for high-end systems including supercomputers. The design is 20 years old, so many of the features it incorporates work well on current multi-core laptops and PCs.
...I cannot really get from "designed 20 years ago" to "so it works well on current PCs" :-)
How's this:
== Having been designed for supercomputers from the mid-90's, XFS is able to leverage the advanced CPU, RAM and RAID feature sets common in today's laptops, desktops, and servers. The key features ext4 does not leverage well include multi-core CPUs, large amounts of RAM and dedicated RAID hardware. ==
The RAID part may be misleading. I'm not sure how ext4 handles that. XFS will try to assemble an entire RAID5 or RAID6 stripe and write in one whack. That eliminates the typical read / modify / write sequence needed when working with parity raid.
Greg
Hi.
Support for multi-core CPUs is transparent or it needs a mount option?
Transparent. XFS uses numerous internal kernel threads to handle the workload. Those threads can be on different CPUs.
Last time I used XFS was slow deleting files, has it been improved?
Yes, greatly a couple years ago. (2010 was the main year of work IIRC).
Greetings.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 14/10/14 a las #4, Greg Freemyer escribió:
Last time I used XFS was slow deleting files, has it been improved?
Yes, greatly a couple years ago. (2010 was the main year of work IIRC).
I have only one concern..last time I used it (many years ago) It zeroed files on unclean shutdowns or crashes.. does it still do that ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/14/2014 01:44 PM, Cristian Rodríguez wrote:
El 14/10/14 a las #4, Greg Freemyer escribió:
Last time I used XFS was slow deleting files, has it been improved? Yes, greatly a couple years ago. (2010 was the main year of work IIRC). I have only one concern..last time I used it (many years ago) It zeroed files on unclean shutdowns or crashes.. does it still do that ?
I haven't experienced any issues with XFS, and I've been using it for years on dozens of desktops and server-class machines. The servers typically have hardware RAID controllers with battery backup, but still, I can't recall any missing/zeroed files on any machine with XFS. None have UPS main power backup. YMMV of course... Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Oct 14, 2014 at 4:44 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 14/10/14 a las #4, Greg Freemyer escribió:
Last time I used XFS was slow deleting files, has it been improved?
Yes, greatly a couple years ago. (2010 was the main year of work IIRC).
I have only one concern..last time I used it (many years ago) It zeroed files on unclean shutdowns or crashes.. does it still do that ?
That was a major complaint before 2007. I never see complaints of that sort on the xfs mailing list these days. Per the FAQ at http://www.xfs.org/index.php?title=XFS_FAQ&redirect=no#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F -- Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1. -- Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Cristian Rodríguez -
Darin Perusich -
Greg Freemyer -
jcsl -
Lew Wolfgang -
Roger Luedecke -
Stefan Seyfried