[opensuse-factory] Fwd: observed significant performance improvement in XFS a real-world application
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice. It continually bests other file systems in optimized configuration performance tests and these new improvements sound like they only add more speed to the equation. For nearly all systems, disk speed is the bottle neck, so using the best solution possible should be strongly considered the default choice for all users -- regardless of 'political' concerns (which seem to often over-rule practicality, unfortunately). Linda p.s. I am not part of the xfs project. I've just used it with open suse (or previously, Suse) since ~ 2002 and have never regretted it. Current filesystem read rates using XFS are about 1GB/second on sustained multi-gigabyte reads. Using 1Gbit ethernet, Samba gets 97MB/s read from disk to 115 MB/s read from memory and 125MB/s writes to memory or disk. -------- Original Message -------- Subject: observed significant performance improvement using "delaylog" in a real-world application Date: Tue, 10 Aug 2010 18:01:33 +0200 From: Peter Niemayer <niemayer@isg.de> To: linux-xfs@oss.sgi.com Hi all, we use XFS for a very I/O-intensive, in-house developed real-time database application, and whenever we see new or significantly changed file-systems becoming available, we run a benchmark using this application on a conserved, fixed real-world data set. I'm pleased to state that using the experimental "delaylog" mount option (in vanilla linux-2.6.35) we measured a 17% performance increase for our benchmark scenario. (Other mount-options in use both before and after the "delaylog" option: noatime,nodiratime,nobarrier) That's a lot given that XFS was the fastest performing file-system for this application already. It's also a promising result regarding stability, as several other tests (using e.g. reiser4 or ceph) in the past led to crashes in the same benchmark scenario. So thanks to all contributing developers for this significant optimization! Regards, Peter Niemayer _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh <suse@tlinx.org> wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
Linda, In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns. Since desktops/laptops tend to have these much more than servers, I would not have wanted it to be the default at all during those times. Has its' resiliency greatly increased? If not, I don't think it is a good choice for the openSUSE default fs. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Unfortunately, my machines have been run through through the ringer, going for prolonged periods of time of having problems, including unclean shutdowns (too many things on plate to address issues that only happened at shutdown, with uptimes often measured in months. The only non-user-error dataloss I've ever experienced has been attributable to 2 areas, neither was XFS. 1st was software raid under 11.1: 2/4 volumes unreadable after an unclean shutdown (fortunately it was a backup volume). and 2nd area was during use of the LSM volume manager -- most recently under 11.2 when I upgraded the kernel and volume snaps broke. I did have a data corruption issue involving XFS with some volume snaps that went bad under 11.2, but they haven't been reproducible on non-LFM volumes nor on volumes where volume snaps had not become full (and self-corrupt). I've been using xfs since the early 2.4 timeframe and was lucky enough to have a stable system then, on a UPS, so that may have prevented some of the issues you are referring to, but UPS, hasn't saved my system stability since upgrading to SuSE 11.0, when stability took a downturn. However, in that time frame, even with instability, XFS hasn't caused any noticeable problems, but honestly, in the 8 years of use, if it had, I also keep daily backups of all data + metadata using xfsdump/restore, and have only had to resort to them for the problems mentioned above and cockpit error. Greg Freemyer wrote:
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh <suse@tlinx.org> wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
Linda,
In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns.
Since desktops/laptops tend to have these much more than servers, I would not have wanted it to be the default at all during those times.
Has its' resiliency greatly increased? If not, I don't think it is a good choice for the openSUSE default fs.
Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2010-08-14 T 20:41 -0400 Greg Freemyer wrote:
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns.
I am afraid, this sounds a bit vague: please check, if in those cases the storage backends had been configured correctly: every journaling filesystem will suffer from data corruption, if there are any caches (such as disk write cache) inbetween the write and the disk. This is, where barriers come in, and for consistency and data safety I strongly recommend to not switch off barriers, even if this might have a small performance penalty with it!
Since desktops/laptops tend to have these much more than servers, I would not have wanted it to be the default at all during those times.
As said, this claim does not hold for well configured storage and filesystems. There are many people out there (including me:-) who store all their most valuable data on XFS for many years already. And Novell recommends XFS for (non clustered) data storage in the Enterprise Products (SUSE Linux Enterprise Server/Desktop). Considering the capabilities of current filesystems and current development, XFS will keep and possibly extend its position for large and super large storage for the next years. Looking around in the Linux (Kernel) community and also in the community of Linux distributions it seems though that btrfs has capabilities (copy on write, data integrity, snapshots, volume management integration), which make btrfs more suitable as the _default_ filesystem for future Linux distributions¹. If btrfs should be considered as the default filesystem for openSUSE 11.4 -- this certainly depends on its maturity and its maturation over the next 5-6 months. I personally would enjoy to see btrfs to be default sooner than later:-) so long - MgE ¹ This includes future SUSE Linux Enterprise versions; you may read my recent blog about this topic at: http://www.novell.com/communities/node/11736/data-customers-gold -- Matthias G. Eckermann Senior Product Manager - SUSE® Linux Enterprise - Server Product Line SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Matthias G. Eckermann schrieb:
If btrfs should be considered as the default filesystem for openSUSE 11.4 -- this certainly depends on its maturity and its maturation over the next 5-6 months. I personally would enjoy to see btrfs to be default sooner than later:-)
Me as well, but right now, i.e. as of kernel 2.6.35's current state of btrfs, it would be a bad idea, I have seen issues here that cause dataloss and on-disk corruption that needs a reformat to fix it, as btrfsck can only diagnose the problem but not repair it, not even with losing the affected data. In my case, I'm running btrfs on a partition that does heavy ccache-backed compile runs (Mozilla applications) and rsync it daily to a partition on a different disk with a more stable fs, and if corruption happens, it's almost exclusively in the ccache dir, which can be nuked without thinking twice, so I haven't actually lost data. I know this is still experimental, after all. But from what I've seen, I can't recommend it for important data yet - I surely hope we'll get there, though! Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 15/08/10 14:24, KaiRo - Robert Kaiser wrote:
Matthias G. Eckermann schrieb:
If btrfs should be considered as the default filesystem for openSUSE 11.4 -- this certainly depends on its maturity and its maturation over the next 5-6 months. I personally would enjoy to see btrfs to be default sooner than later:-)
Me as well, but right now, i.e. as of kernel 2.6.35's current state of btrfs, it would be a bad idea, I have seen issues here that cause dataloss and on-disk corruption that needs a reformat to fix it, as btrfsck can only diagnose the problem but not repair it, not even with losing the affected data. In my case, I'm running btrfs on a partition that does heavy ccache-backed compile runs (Mozilla applications) and rsync it daily to a partition on a different disk with a more stable fs, and if corruption happens, it's almost exclusively in the ccache dir, which can be nuked without thinking twice, so I haven't actually lost data. I know this is still experimental, after all. But from what I've seen, I can't recommend it for important data yet - I surely hope we'll get there, though!
Robert Kaiser
And me 3? I have had no issues with XFS ever since I switched when reiserfs seemed heading for the scrap heap. Btrfs I've used as a backup of critical data for all my systems, though some stuff is backed up elsewhere. I have read that Btrfs has been acknowledged by ext4 folk as the successor. Also read that Linus uses it for his root filesystem. My only data loss problems ever, back to the days when the Minix filesystem was used by Linux have been due to broken hardware - hard drives and IDE controllers. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 15/08/2010 14:30, Matthias G. Eckermann a écrit :
you may read my recent blog about this topic at: http://www.novell.com/communities/node/11736/data-customers-gold
xfs was said, some years ago, to be brillant on very heavy load and random in other. I have no idea what it is now. I see ext4 very deprecated in your blog. So why was it choosen as default for openSUSE (against ext3)? Do you have links on the room used by btrfs (~= journal size). I know reiser was at least 50Mo, so not good for small partitions (for /boot, for example). xfs uses less room what about btrfs? looks like btrfs is more a disk manager than a filesystem manager what is the *windows* situation about btrfs? Having a native windows driver for our file system (like ext3ifs for ext3) is very important relative as default install, often dualboot for rendom user thanks jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/15/2010 09:37 AM, jdd wrote:
Le 15/08/2010 14:30, Matthias G. Eckermann a écrit :
you may read my recent blog about this topic at: http://www.novell.com/communities/node/11736/data-customers-gold
xfs was said, some years ago, to be brillant on very heavy load and random in other. I have no idea what it is now.
I see ext4 very deprecated in your blog. So why was it choosen as default for openSUSE (against ext3)?
The short answer is release schedules. SLES11 is based on openSUSE 11.1, where ext3 was the default. The kernel used was 2.6.27, released in Oct 2008. We could have changed the default for SLE11 since it was released several months after openSUSE 11.1, but I wasn't yet convinced that it was stable enough. openSUSE 11.2 was based on 2.6.31, released 11 months later, which gave ext4 an opportunity to prove itself a little more. Even then, there were expected quirks, like how fsync was needed more frequently, that surprised users. SLES 11 SP1 is based on 2.6.32, so ext4 is pretty stable. The interesting bit here is that between the release of SLES 11 and SLES 11 SP1, btrfs was accepted into the mainline kernel, making it the clear choice for the future. We already support ext3, XFS, reiserfs, and a number of other file systems. The feature gap that ext4 filled was already filled in SLES by XFS for a number of years already, so we chose not to support it.
Do you have links on the room used by btrfs (~= journal size). I know reiser was at least 50Mo, so not good for small partitions (for /boot, for example). xfs uses less room what about btrfs? looks like btrfs is more a disk manager than a filesystem manager
Btrfs doesn't use a journal at all. The overhead of a brand new btrfs file system is quite small. The bit that complicates things is that it is a log based file system (different than journal!) and operates by being copy-on-write to the core. New writes are written and then linked into the tree atomically. With the exception of the superblock (I think), there are no places in btrfs where a block contains data that must be continually updated. This also means, ironically, that you need free space to delete things.
what is the *windows* situation about btrfs? Having a native windows driver for our file system (like ext3ifs for ext3) is very important relative as default install, often dualboot for rendom user
AFAIK there is no Windows support at all. I'd hazard a guess that the number of users sharing data between Linux and Windows *and* are using a Linux-based file system to do it are probably a very small minority. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxomGMACgkQLPWxlyuTD7KI2QCdEf2+MZo1aZ/DOz42iZ8DmWjD odUAn0zUPhQvzaNXvpx4m4ksV9gJjimG =UM1i -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2010 03:46, Jeff Mahoney a écrit :
I see ext4 very deprecated in your blog. So why was it choosen as default for openSUSE (against ext3)?
The short answer is release schedules.
thanks. So we can expect to have btrfs default for openSUSE 11.4 jdd -- Jean-Daniel Dodin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/16/2010 04:02 AM, Jean-Daniel Dodin wrote:
Le 16/08/2010 03:46, Jeff Mahoney a écrit :
I see ext4 very deprecated in your blog. So why was it choosen as default for openSUSE (against ext3)?
The short answer is release schedules.
thanks. So we can expect to have btrfs default for openSUSE 11.4
Probably not. OpenSUSE 11.4 is tentatively scheduled to come out in March, which is only 7 months away. I use btrfs for my data partition and users who can tolerate a bit of uncertainty are welcome to test it. I wouldn't yet recommend it as the default yet since there are at least two major issues left to resolve. The first is that the balancing algorithm needs to be fixed to avoid a situation where unfilled tree entries populate the metadata tree. That ends up causing the file system to be more than 50% populated by metadata - so your 20 GB file system only has 10 GB usable for data. Not a good scene. The second is that most error conditions are still "handled" by crashing. This is how reiserfs was for a long time and I'd prefer not to relive that experience. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxpUjAACgkQLPWxlyuTD7IOewCfeJlmWb+Hy+onv3nZc11qtLiQ XSgAoI9la0TJVxRMzsXifsyS2ng7pMGP =7nQ4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Aug 15, 2010 at 8:30 AM, Matthias G. Eckermann <mge@novell.com> wrote:
On 2010-08-14 T 20:41 -0400 Greg Freemyer wrote:
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns.
I am afraid, this sounds a bit vague: please check, if in those cases the storage backends had been configured correctly: every journaling filesystem will suffer from data corruption, if there are any caches (such as disk write cache) inbetween the write and the disk.
It was very well known and accepted in the 2002-2005 timeframe that xfs on linux often would replace the content of files with nulls. ANd I mean exclusively nulls. Thus many people that had the poor luck to use xfs for their home directory had the kde config files turned into null filled files due to a power outage. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Greg Freemyer wrote:
On Sun, Aug 15, 2010 at 8:30 AM, Matthias G. Eckermann <mge@novell.com> wrote:
On 2010-08-14 T 20:41 -0400 Greg Freemyer wrote:
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice. In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns. I am afraid, this sounds a bit vague: please check, if in those cases the storage backends had been configured correctly: every journaling filesystem will suffer from data corruption, if there are any caches (such as disk write cache) inbetween the write and the disk.
It was very well known and accepted in the 2002-2005 timeframe that xfs on linux often would replace the content of files with nulls. ANd I mean exclusively nulls.
That is because that area of the file was RECORDED in the journal, as having been written to. The plug was pulled, before the data could be written. It's a violation of security policy and practice to NOT zero the data in such a case. XFS was also charted to handle a basic requirement of security, in that if a process has written to an object, the old data is guaranteed to be zeroed or reinitialized.
Thus many people that had the poor luck to use xfs for their home directory had the kde config files turned into null filled files due to a power outage.
---- That's because they overwrote them, then pulled the plug before the new data could be written. In my experience, it's very rare, but if someone has tweaked params to only have dirty data flushed to disk every 30-60 seconds, then they are asking for problems -- such was, and is still given as standard advice to save power. The problem with a journaled file system, is that the operations are recorded before the data is written, on the normal assumption that writing the list of what was done, 'operations', is faster than writing out all the data. Thus your file system maintains its integrity. If you write data before updating the disk, you end up with WRONG content -- which for a KDE text config, might not be so troublesome, but it's a binary file of almost any sort, having it NOT detected, could more easily be catastrophic. Having it zeroed makes it clear that information was in the process of being written to it. It didn't complete. Someone pulled the plug or the OS crashed. Not alot a fs can do about that. But the alternative is to have random garbage (which may look like reasonable text to a human eye, or may resync on an end-of-line if it is a text file), but would cause bad results if it was a program or binary financial information. Zeroing it the only safe thing to do. It may be inconvenient, but unplanned shutdowns many seconds of unflushed data in them is a bad situation no matter what. XFS didn't cause those files to be zeroed. Their programs wrote to those areas. That those areas no longer contained useful data was recorded in the journal. It's not until the data is flushed that the data in those files would be valid again. So really -- you may not like it, but zeroing it is the safest thing to do (besides being a security requirement). In other words -- other files systems leave those files in a corrupt and undefined state. Are you saying this is preferable? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 15 Aug 2010 15:33:28 -0700 Linda Walsh <suse@tlinx.org> wrote:
So really -- you may not like it, but zeroing it is the safest thing to do (besides being a security requirement).
In other words -- other files systems leave those files in a corrupt and undefined state. Are you saying this is preferable?
Of course - if it allows me to recover my config file :-P Really, I was sometimes happy that old reiserfsck --rebuild-tree basically dug up all the stuff that ever was written to a disk, after an accidental rm ;-) But to put some constructive things onto the discussion: I think that ext3 (or maybe nowadays ext4) is still a reasonable default file system for the root and boot partitions. For data partitions, I also use XFS, and am happy with its performance. Until I want to delete a large kernel source tree. Then I'm always annoyed ;-) Besides, you cannot install a boot record onto XFS, so you always need a second partition anyway (Might not be 100% technically correct. You cannot install grub into it at least). -- Stefan Seyfried "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." -- Linus Torvalds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/16/2010 03:16 AM, Stefan Seyfried wrote:
On Sun, 15 Aug 2010 15:33:28 -0700 Linda Walsh <suse@tlinx.org> wrote:
So really -- you may not like it, but zeroing it is the safest thing to do (besides being a security requirement).
In other words -- other files systems leave those files in a corrupt and undefined state. Are you saying this is preferable?
Of course - if it allows me to recover my config file :-P
Haha, yeah, except that it could also allow someone else to recover your mail cache instead. - -Jeff
Really, I was sometimes happy that old reiserfsck --rebuild-tree basically dug up all the stuff that ever was written to a disk, after an accidental rm ;-)
But to put some constructive things onto the discussion: I think that ext3 (or maybe nowadays ext4) is still a reasonable default file system for the root and boot partitions. For data partitions, I also use XFS, and am happy with its performance. Until I want to delete a large kernel source tree. Then I'm always annoyed ;-)
Besides, you cannot install a boot record onto XFS, so you always need a second partition anyway (Might not be 100% technically correct. You cannot install grub into it at least).
- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxpU1cACgkQLPWxlyuTD7L4WwCfbCOqYpkKv1h94k2WNM1+ZIDx sJkAoI1lNgrCZ0Eezq+Glt4H+Gel1lhg =Wy4b -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 16 Aug 2010 11:03:51 -0400 Jeff Mahoney <jeffm@suse.com> wrote:
Of course - if it allows me to recover my config file :-P
Haha, yeah, except that it could also allow someone else to recover your mail cache instead.
Not if I safely deleted it before ;-) Anyway, XFS and ext4 seem to be fixed wrt. those problems. If Three Letter Agencies are after me and try to get at my mail from the filesystem, this is my least problem ;-) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/16/2010 12:14 PM, Stefan Seyfried wrote:
On Mon, 16 Aug 2010 11:03:51 -0400 Jeff Mahoney <jeffm@suse.com> wrote:
Of course - if it allows me to recover my config file :-P
Haha, yeah, except that it could also allow someone else to recover your mail cache instead.
Not if I safely deleted it before ;-)
Anyway, XFS and ext4 seem to be fixed wrt. those problems.
If Three Letter Agencies are after me and try to get at my mail from the filesystem, this is my least problem ;-)
Well it's more about another user seeing old data from another file that could be potentially sensitive than someone scouring the disk looking for your secrets. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxpdQYACgkQLPWxlyuTD7JZwgCglIFqO32HTeTLeCo81NdreZbu YkIAnjBYTWGdj4UI7oq5ggQBl5/NHgC8 =fv3Z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-16 18:14, Stefan Seyfried wrote:
On Mon, 16 Aug 2010 11:03:51 -0400 Jeff Mahoney <jeffm@suse.com> wrote:
Of course - if it allows me to recover my config file :-P
Haha, yeah, except that it could also allow someone else to recover your mail cache instead.
Not if I safely deleted it before ;-)
Not really. On a similar situation, on an xfs filesystem you'd get zeroes, and in others, random data (with random results).
Anyway, XFS and ext4 seem to be fixed wrt. those problems.
Not really. Rather, programmers have to use "flush" more. It is not a filesystem fault. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqcykACgkQU92UU+smfQUXkgCfa5hfPGngyXtpm1LfSdEgUUTR NMYAnjc5nFw4iXRbf+StuKWsaSjFO0gP =pSCd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, 17 Aug 2010 13:31:54 +0200 "Carlos E. R." <robin.listas@gmail.com> wrote:
Not if I safely deleted it before ;-)
Not really. On a similar situation, on an xfs filesystem you'd get zeroes, and in others, random data (with random results).
But before that 2007 fix, you'd very often get zeroes on XFS, when on other filesystems you yould get valid data. IIUC.
Anyway, XFS and ext4 seem to be fixed wrt. those problems.
Not really. Rather, programmers have to use "flush" more.
The mentioned 2007 XFS fix apparently helped a lot, without changes to applications. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-17 16:33, Stefan Seyfried wrote:
On Tue, 17 Aug 2010 13:31:54 +0200 "Carlos E. R." <> wrote:
Not if I safely deleted it before ;-)
Not really. On a similar situation, on an xfs filesystem you'd get zeroes, and in others, random data (with random results).
But before that 2007 fix, you'd very often get zeroes on XFS, when on other filesystems you yould get valid data. IIUC.
No, data that sometimes happened to be valid, or came from the old version of the file. Not what the file should really contain. Not guaranteed correct data. In that circumstance, zeroes is the only valid data to have.
Anyway, XFS and ext4 seem to be fixed wrt. those problems.
Not really. Rather, programmers have to use "flush" more.
The mentioned 2007 XFS fix apparently helped a lot, without changes to applications.
Yes, I just read about it. I'm probably mixing two issues (the .new/.bak rename issue). - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqrJQACgkQU92UU+smfQWaIgCfbP4EGU/KbXtbd4DWiw7zbE3P 6PAAnjqjVwNlaDRa/9Ve6rZcOBAoNY5I =zBrG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/17/2010 07:31 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2010-08-16 18:14, Stefan Seyfried wrote:
On Mon, 16 Aug 2010 11:03:51 -0400 Jeff Mahoney <jeffm@suse.com> wrote:
Of course - if it allows me to recover my config file :-P
Haha, yeah, except that it could also allow someone else to recover your mail cache instead.
Not if I safely deleted it before ;-)
Not really. On a similar situation, on an xfs filesystem you'd get zeroes, and in others, random data (with random results).
Anyway, XFS and ext4 seem to be fixed wrt. those problems.
Not really. Rather, programmers have to use "flush" more.
It is not a filesystem fault.
These are different issues. Getting zeroes means you extended the file and didn't flush. Getting "random" data isn't random. It's the file contents that used to occupy a specific block and is a security issue. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqoTkACgkQLPWxlyuTD7JFyQCaA3so8PNGA9MF+icR/tf/mDdl LEwAn3zfViqqgqTJGDHI1ZrtdHSqJedv =AO5s -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-17 16:48, Jeff Mahoney wrote:
On 08/17/2010 07:31 AM, Carlos E. R. wrote:
These are different issues. Getting zeroes means you extended the file and didn't flush. Getting "random" data isn't random. It's the file contents that used to occupy a specific block and is a security issue.
Yes, that's it. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqq4kACgkQU92UU+smfQVUYQCfYhigoJvBg/yBsp3R1C9+kGjO G4QAn2RiuxZ1OShEynB/ICzu7aTHAsB9 =Nldi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition anyway (Might not be 100% technically correct. You cannot install grub into it at least).
Some have had this problem. I have never had this issue. My root (and boot) partition are xfs. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-20 06:16, Linda Walsh wrote:
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition anyway (Might not be 100% technically correct. You cannot install grub into it at least).
Some have had this problem.
I have never had this issue. My root (and boot) partition are xfs.
It is a documented and known problem. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxuAmsACgkQU92UU+smfQW1/QCgjRdpVFhXCbZui5lKV5FElh8X fhkAoIvOEpalQLXPXk5IYIkvMA2kqtI6 =dcHt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Carlos E. R. wrote:
On 2010-08-20 06:16, Linda Walsh wrote:
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition
Some have had this problem. I have never had this issue. My root (and boot) partition are xfs.
It is a documented and known problem.
Yes -- a documented problem in Grub. Not in XFS. SuSE maintainers thought GRUB was more important than the ability to use 1 file system for all your file systems. Personally, I disagree, since it is GRUB that is doing things, that were documented as being problematic, since before GRUB was even conceived. -l -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 12:26 AM, Linda Walsh wrote:
Carlos E. R. wrote:
On 2010-08-20 06:16, Linda Walsh wrote:
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition
Some have had this problem. I have never had this issue. My root (and boot) partition are xfs.
It is a documented and known problem.
Yes -- a documented problem in Grub. Not in XFS. SuSE maintainers thought GRUB was more important than the ability to use 1 file system for all your file systems.
Personally, I disagree, since it is GRUB that is doing things, that were documented as being problematic, since before GRUB was even conceived.
Personally I don't miss the days of forgetting to run lilo after every kernel update and being greeted with LILILILILILI or whatever it was. Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxugdQACgkQLPWxlyuTD7JfdACfc1vKcMHpq1JFpCGY564cZNDb E0IAoJS1f50KsyYBb0xW2nJYQkb4gMyU =NbPR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----
On 8/20/2010 at 06:53 PM, Jeff Mahoney <jeffm@suse.com> wrote: BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 12:26 AM, Linda Walsh wrote:
Carlos E. R. wrote:
On 2010-08-20 06:16, Linda Walsh wrote:
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition
Some have had this problem. I have never had this issue. My root (and boot) partition are xfs.
It is a documented and known problem.
Yes -- a documented problem in Grub. Not in XFS. SuSE maintainers thought GRUB was more important than the ability to use 1 file system for all your file systems.
Personally, I disagree, since it is GRUB that is doing things, that were documented as being problematic, since before GRUB was even conceived.
Personally I don't miss the days of forgetting to run lilo after every kernel update and being greeted with LILILILILILI or whatever it was.
But as long as one runs lilo...
Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs.
I thought LILO is file-system agnostic? And LILO is the only possible way to use a brand-new file-system, whenever a new file-system comes out, till GRUB learns the format?! Thanks Nikanth -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 09:53 AM, Nikanth Karthikesan wrote:
-----
On 8/20/2010 at 06:53 PM, Jeff Mahoney <jeffm@suse.com> wrote: BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 12:26 AM, Linda Walsh wrote:
Carlos E. R. wrote:
On 2010-08-20 06:16, Linda Walsh wrote:
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition
Some have had this problem. I have never had this issue. My root (and boot) partition are xfs.
It is a documented and known problem.
Yes -- a documented problem in Grub. Not in XFS. SuSE maintainers thought GRUB was more important than the ability to use 1 file system for all your file systems.
Personally, I disagree, since it is GRUB that is doing things, that were documented as being problematic, since before GRUB was even conceived.
Personally I don't miss the days of forgetting to run lilo after every kernel update and being greeted with LILILILILILI or whatever it was.
But as long as one runs lilo...
Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs.
I thought LILO is file-system agnostic?
And LILO is the only possible way to use a brand-new file-system, whenever a new file-system comes out, till GRUB learns the format?!
More specifically, LILO works directly with maps of blocks instead of interpreting the file system. That becomes dangerous when the file system governing those blocks makes no promises about that map remaining static. That promise can be broken easily by a copy-on-write file system, file systems that aren't absolutely block based[1], and also by anything running a defrag tool, which are becoming more common. The solution should *not* be to teach the defrag tools about LILO. The solution should be to fix any remaining bugs in GRUB. - -Jeff [1] yes, reiserfs has an ioctl for lilo to call to ensure that the tail of a kernel image or initrd isn't packed so lilo can use it. That is a hack too. - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxuiiYACgkQLPWxlyuTD7KWxACgot9kbPgh9zTXz0BuIvjeZTMZ iVUAn3nHPFakYcv2y5r4fmaAAN/RarW5 =PJCz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----
On 8/20/2010 at 07:29 PM, Jeff Mahoney <jeffm@suse.com> wrote: BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 09:53 AM, Nikanth Karthikesan wrote:
-----
On 8/20/2010 at 06:53 PM, Jeff Mahoney <jeffm@suse.com> wrote: BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 12:26 AM, Linda Walsh wrote:
Carlos E. R. wrote:
On 2010-08-20 06:16, Linda Walsh wrote:
Stefan Seyfried wrote: > Besides, you cannot install a boot record onto XFS, so you always > need a > second partition ---- Some have had this problem. I have never had this issue. My root (and boot) partition are xfs.
It is a documented and known problem.
Yes -- a documented problem in Grub. Not in XFS. SuSE maintainers thought GRUB was more important than the ability to use 1 file system for all your file systems.
Personally, I disagree, since it is GRUB that is doing things, that were documented as being problematic, since before GRUB was even conceived.
Personally I don't miss the days of forgetting to run lilo after every kernel update and being greeted with LILILILILILI or whatever it was.
But as long as one runs lilo...
Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs.
I thought LILO is file-system agnostic?
And LILO is the only possible way to use a brand-new file-system, whenever a new file-system comes out, till GRUB learns the format?!
More specifically, LILO works directly with maps of blocks instead of interpreting the file system. That becomes dangerous when the file system governing those blocks makes no promises about that map remaining static. That promise can be broken easily by a copy-on-write file system, file systems that aren't absolutely block based[1], and also by anything running a defrag tool, which are becoming more common.
Ah, that explains. I assumed, it copies the actual data. Never thought that it just notes the bmaps. Thanks.
The solution should *not* be to teach the defrag tools about LILO. The solution should be to fix any remaining bugs in GRUB.
Agree.
- -Jeff
[1] yes, reiserfs has an ioctl for lilo to call to ensure that the tail of a kernel image or initrd isn't packed so lilo can use it. That is a hack too.
Wow! Thanks Nikanth
- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkxuiiYACgkQLPWxlyuTD7KWxACgot9kbPgh9zTXz0BuIvjeZTMZ iVUAn3nHPFakYcv2y5r4fmaAAN/RarW5 =PJCz -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-20 15:59, Jeff Mahoney wrote:
The solution should *not* be to teach the defrag tools about LILO. The solution should be to fix any remaining bugs in GRUB.
Right.
-Jeff
[1] yes, reiserfs has an ioctl for lilo to call to ensure that the tail of a kernel image or initrd isn't packed so lilo can use it. That is a hack too.
Curious! Another method would be to mark those "unmovable" files with a special attribute (MsDos has it), so that they are treated specially by the kernel and all tools that could touch them. By the way, one of those bugs is that grub doesn't handle reiserfs well, it is broken (and reported). (re s2disk, re booting on a stale filesystem: log has to re-played in memory, and it does so in minutes, not seconds.) - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxu52YACgkQU92UU+smfQX8ZQCeKzzs33awzz3tII1j5Z2e1sFU 40MAn0HyM5IXcmDwM0BkynSMgG2tKHQ1 =Zxlo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 04:36 PM, Carlos E. R. wrote:
On 2010-08-20 15:59, Jeff Mahoney wrote:
The solution should *not* be to teach the defrag tools about LILO. The solution should be to fix any remaining bugs in GRUB.
Right.
-Jeff
[1] yes, reiserfs has an ioctl for lilo to call to ensure that the tail of a kernel image or initrd isn't packed so lilo can use it. That is a hack too.
Curious!
Another method would be to mark those "unmovable" files with a special attribute (MsDos has it), so that they are treated specially by the kernel and all tools that could touch them.
By the way, one of those bugs is that grub doesn't handle reiserfs well, it is broken (and reported).
(re s2disk, re booting on a stale filesystem: log has to re-played in memory, and it does so in minutes, not seconds.)
Yeah, I started working on a fix for that and probably have it lying around somewhere. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxu564ACgkQLPWxlyuTD7KhTQCfYjKJPNzDGC+CNmT+iDca6lLa o00An345uwCST3xgfqCCZcPaSwcPgNgr =L1c5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-20 22:38, Jeff Mahoney wrote:
On 08/20/2010 04:36 PM, Carlos E. R. wrote:
By the way, one of those bugs is that grub doesn't handle reiserfs well, it is broken (and reported).
(re s2disk, re booting on a stale filesystem: log has to re-played in memory, and it does so in minutes, not seconds.)
Yeah, I started working on a fix for that and probably have it lying around somewhere.
That's nice! :-) Although to me it is not important now, as all the systems I have with a reiserfs root filesystem also have an ext2 /boot partition. I had to add them. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxu6h8ACgkQU92UU+smfQXZeQCeLmJg+TgqJQw1SvKe2ktf5Q3N rcUAn3DRL/lSSrmfb9Hi1h+zUvrt9RwT =pimh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 20/08/2010 15:23, Jeff Mahoney a écrit :
Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs.
my hosting provider uses lilo on his openSUSE installs, and no grub setup works on his machines :-( jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 01:19 PM, jdd wrote:
Le 20/08/2010 15:23, Jeff Mahoney a écrit :
Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs.
my hosting provider uses lilo on his openSUSE installs, and no grub setup works on his machines :-(
Do you have a bugzilla number for that? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxuudwACgkQLPWxlyuTD7J8bACeNU3x/BKuCeIpShYbWU8i6Oic B9MAnRzpKuHSVglpWgJ5XW0JdYI+A0Nx =K29z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 20/08/2010 19:22, Jeff Mahoney a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 01:19 PM, jdd wrote:
Le 20/08/2010 15:23, Jeff Mahoney a écrit :
Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs.
my hosting provider uses lilo on his openSUSE installs, and no grub setup works on his machines :-(
Do you have a bugzilla number for that?
no, as I said it's a hosting provider. He gives my a box from his own stock, an openSUSE working default install, and I manage the box. I don't know why this box don't works with grub, but making tests is extremely boring, when the box don't start I have to log on a recovery boot (after claiming a special pass). Not ideal for tracking bugs. As this provider also gives patched kernel images to boot with (netboot), having lilo is not really a problem. I have no idea of what he will do if extX become obsolete, but for now I have only 250Gb disk :-) that said, if I can give you some hint from a running server, I ready to do (but not to reboot the server twice a day :-)) jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jeff Mahoney wrote:
Lilo should be taken out back and shot. This is even more true as more file systems are developed that lilo can't possibly ever work with, like btrfs.
That's a nice goal that I would have subscribed to for years. But then I got a workstation that doesn't boot with grub. No error messages, no action after BIOS setup, nothing. (grub has been installed in MBR, as usual.) /boot is an own partition, at the start of the disk, ext3. Thus, standard setup, but grub won't work. After several hours of hair pulling -- and I've got already a grey beard and very few hair :-) :-) -- I tried LILO. Well, what should I say -- it worked from the start and without a hitch. Having had no problems on this systems 'till then. OK; I have to update lilo.conf manually at each kernel update, but that's seldom enough not to be a complete nuisance. `Manually' means `I wrote a script to do it', of course. Still reminds me of my time with 0.99.4, when I started to use Linux... :-) I always thought that I should try to pin down the actual problem, maybe see if grub 2 takes care of this hardware constellation; but tracking this kind of problem is very time intensive, and that didn't work out. So, there's still a place for LILO, for the old-timers of us who know how to use it and when it saves our back in dure times. Joachim [using Linux since 1993 or so, and being used to LILO for decades] PS: FWIW, Disks are Seagate ST3750330AS on SATA, workstation is from a German manufacturer named Transtec. Since I won't buy from Transtec any more after they stopped supporting Linux on their workstations, the problem is mood, anyhow. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-11-21 at 03:38 +0100, Joachim Schrod wrote:
But then I got a workstation that doesn't boot with grub. No error messages, no action after BIOS setup, nothing. (grub has been installed in MBR, as usual.) /boot is an own partition, at the start of the disk, ext3. Thus, standard setup, but grub won't work.
After several hours of hair pulling -- and I've got already a grey beard and very few hair :-) :-) -- I tried LILO. Well, what should I say -- it worked from the start and without a hitch. Having had no problems on this systems 'till then. OK;
Wow.
So, there's still a place for LILO, for the old-timers of us who know how to use it and when it saves our back in dure times.
Hah. May write a bugzilla and have "them" figure it out >:-)) - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkzojGkACgkQtTMYHG2NR9VCRwCeJOiaZuwlfgGPDPT07FKa+tTl 6AMAoJhd50D4bFwlde7Yp5rG5E4Fh4Jd =ntP5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Joachim Schrod wrote:
So, there's still a place for LILO, for the old-timers of us who know how to use it and when it saves our back in dure times.
Joachim [using Linux since 1993 or so, and being used to LILO for decades]
Same here, I've just never had reason to climb the grub learning curve. -- Per Jessen, Zürich (3.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 20 August 2010 06:19:55 Carlos E. R. wrote:
On 2010-08-20 06:16, Linda Walsh wrote:
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition anyway (Might not be 100% technically correct. You cannot install grub into it at least).
----
Some have had this problem.
I have never had this issue. My root (and boot) partition are xfs.
It is a documented and known problem.
It was a problem. Since at least grub version 0.97 it isn't anymore Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-20 07:16, Anders Johansson wrote:
On Friday 20 August 2010 06:19:55 Carlos E. R. wrote:
It is a documented and known problem.
It was a problem. Since at least grub version 0.97 it isn't anymore
We have 0.97 precisely. Then we aren't affected? - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxudsMACgkQU92UU+smfQV1mwCfc1TfgZWTmPEKCA7YCPwyTU9P k/4AnAi6Q6aFahmq7CBuOLWNEif6yqar =9lbz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
looking through old messages, I saw this one dropped through the cracks, as it seems this was the last issue as to why XFS was not used as a default file system. I've no experience or statistics with brfs, so I have no comparison there. Though whatever it's condition, it certainly doesn't have an established track record as corporate file system. Certainly, _at least_, XFS should be fully supported as a boot & root file system now... Yes? Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2010-08-20 07:16, Anders Johansson wrote:
On Friday 20 August 2010 06:19:55 Carlos E. R. wrote:
It is a documented and known problem. It was a problem. Since at least grub version 0.97 it isn't anymore
We have 0.97 precisely. Then we aren't affected?
- -- Cheers / Saludos,
Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkxudsMACgkQU92UU+smfQV1mwCfc1TfgZWTmPEKCA7YCPwyTU9P k/4AnAi6Q6aFahmq7CBuOLWNEif6yqar =9lbz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Linda Walsh wrote:
Stefan Seyfried wrote:
Besides, you cannot install a boot record onto XFS, so you always need a second partition anyway (Might not be 100% technically correct. You cannot install grub into it at least).
Some have had this problem.
I have never had this issue. My root (and boot) partition are xfs.---
Hit send too fast...dang. Should have mentioned, that this is not an XFS problem but is a in the GRUB bootloader which insists in trying to write to a mounted, live file system. For some reason, the fact that GRUB couldn't do this to XFS was considered a problem with XFS, rather than in GRUB. Half my systems use lilo when they are correctly configured. They boot in about half the time (not using a ram disk). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2010 00:33, Linda Walsh a écrit :
That's because they overwrote them, then pulled the plug before the new data could be written.
but a journaled file system is specially made to make this harmless. and at the boot ntime, lost operations are "replayed" to correct things. i'm pretty sure xfs do this also. my first demo of reiserfs, somebody managed to remove the plug from the wall during the demo. atm ext2 was launching fsck and reboot took ages, with reiser, only some seconds. the demo was impressive, I could have made this on purpose nif it wouldn't have been an accident :-) jdd NB I remember time when fsck'ing a 20Gb HDD could take one hour :-( -- Jean-Daniel Dodin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 8/16/2010 at 07:11 PM, Jean-Daniel Dodin <jdd@dodin.org> wrote:
Le 16/08/2010 00:33, Linda Walsh a écrit :
That's because they overwrote them, then pulled the plug before the new data could be written.
but a journaled file system is specially made to make this harmless. and at the boot ntime, lost operations are "replayed" to correct things. i'm pretty sure xfs do this also.
XFS only journals metadata, not regular user data inside files. But anyway, the "NULL files" problem was fixed about three years ago: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... See also: http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_... Regards, Tim -- Tim Serong <tserong@novell.com> Senior Clustering Engineer, OPS Engineering, Novell Inc. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (17)
-
Anders Johansson -
Carlos E. R. -
Carlos E. R. -
Carlos E. R. -
Greg Freemyer -
jdd -
Jean-Daniel Dodin
-
Jeff Mahoney -
Joachim Schrod -
KaiRo - Robert Kaiser -
Linda Walsh -
Matthias G. Eckermann -
Nikanth Karthikesan -
Per Jessen -
Sid Boyce -
Stefan Seyfried -
Tim Serong