On Mon, Feb 04, 2008 at 07:38:40PM +0300, Michael Tokarev wrote:
Eric Sandeen wrote:
[]
http://oss.sgi.com/projects/xfs/faq.html#nulls
and note that recent fixes have been made in this area (also noted in
the faq)
Also - the above all assumes that when a drive says it's written/flushed
data,
Michael Tokarev wrote:
note that with some workloads, write caching in
the drive actually makes write speed worse, not better - namely,
in case of massive writes.
With write barriers enabled, I did a quick test of
a large copy from one backup filesystem to another.
I'm
Michael Tokarev wrote:
Unfortunately an UPS does not *really* help here. Because unless
it has control program which properly shuts system down on the loss
of input power, and the battery really has the capacity to power the
system while it's shutting down (anyone tested this?
Linda Walsh wrote:
Michael Tokarev wrote:
Unfortunately an UPS does not *really* help here. Because unless
it has control program which properly shuts system down on the loss
of input power, and the battery really has the capacity to power the
system while it's shutting down (anyone tested
Moshe Yudkowsky wrote:
[]
But that's *exactly* what I have -- well, 5GB -- and which failed. I've
modified /etc/fstab system to use data=journal (even on root, which I
thought wasn't supposed to work without a grub option!) and I can
power-cycle the system and bring it up reliably afterwards.
Michael Tokarev wrote:
Moshe Yudkowsky wrote:
[]
But that's *exactly* what I have -- well, 5GB -- and which failed. I've
modified /etc/fstab system to use data=journal (even on root, which I
thought wasn't supposed to work without a grub option!) and I can
power-cycle the system and bring it up
Robin, thanks for the explanation. I have a further question.
Robin Hill wrote:
Once the file system is mounted then hdX,Y maps according to the
device.map file (which may actually bear no resemblance to the drive
order at boot - I've had issues with this before). At boot time it maps
to the
Moshe Yudkowsky wrote:
[]
If I'm reading the man pages, Wikis, READMEs and mailing lists correctly
-- not necessarily the case -- the ext3 file system uses the equivalent
of data=journal as a default.
ext3 defaults to data=ordered, not data=journal. ext2 doesn't have
journal at all.
The
Eric,
Thanks very much for your note. I'm becoming very leery of resiserfs at
the moment... I'm about to run another series of crash tests.
Eric Sandeen wrote:
Justin Piszcz wrote:
Why avoid XFS entirely?
esandeen, any comments here?
Heh; well, it's the meme.
Well, yeah...
Note also
Eric Sandeen wrote:
Moshe Yudkowsky wrote:
So if I understand you correctly, you're stating that current the most
reliable fs in its default configuration, in terms of protection against
power-loss scenarios, is XFS?
I wouldn't go that far without some real-world poweroff testing, because
Michael Tokarev wrote:
Unfortunately an UPS does not *really* help here. Because unless
it has control program which properly shuts system down on the loss
of input power, and the battery really has the capacity to power the
system while it's shutting down (anyone tested this? With new UPS?
Moshe Yudkowsky wrote:
So if I understand you correctly, you're stating that current the most
reliable fs in its default configuration, in terms of protection against
power-loss scenarios, is XFS?
I wouldn't go that far without some real-world poweroff testing, because
various fs's are
On Mon Feb 04, 2008 at 05:06:09AM -0600, Moshe Yudkowsky wrote:
Robin, thanks for the explanation. I have a further question.
Robin Hill wrote:
Once the file system is mounted then hdX,Y maps according to the
device.map file (which may actually bear no resemblance to the drive
order at
On Mon, 4 Feb 2008, Michael Tokarev wrote:
Moshe Yudkowsky wrote:
[]
If I'm reading the man pages, Wikis, READMEs and mailing lists correctly
-- not necessarily the case -- the ext3 file system uses the equivalent
of data=journal as a default.
ext3 defaults to data=ordered, not
Eric Sandeen wrote:
[]
http://oss.sgi.com/projects/xfs/faq.html#nulls
and note that recent fixes have been made in this area (also noted in
the faq)
Also - the above all assumes that when a drive says it's written/flushed
data, that it truly has. Modern write-caching drives can wreak
Eric Sandeen wrote:
Justin Piszcz wrote:
Why avoid XFS entirely?
esandeen, any comments here?
Heh; well, it's the meme.
see:
http://oss.sgi.com/projects/xfs/faq.html#nulls
and note that recent fixes have been made in this area (also noted in
the faq)
Actually, continue reading
Justin Piszcz wrote:
Why avoid XFS entirely?
esandeen, any comments here?
Heh; well, it's the meme.
see:
http://oss.sgi.com/projects/xfs/faq.html#nulls
and note that recent fixes have been made in this area (also noted in
the faq)
Also - the above all assumes that when a drive says it's
On Mon, 4 Feb 2008, Michael Tokarev wrote:
Eric Sandeen wrote:
[]
http://oss.sgi.com/projects/xfs/faq.html#nulls
and note that recent fixes have been made in this area (also noted in
the faq)
Also - the above all assumes that when a drive says it's written/flushed
data, that it truly has.
I've been reading the draft and checking it against my experience.
Because of local power fluctuations, I've just accidentally checked my
system: My system does *not* survive a power hit. This has happened
twice already today.
I've got /boot and a few other pieces in a 4-disk RAID 1 (three
On Sun Feb 03, 2008 at 01:15:10PM -0600, Moshe Yudkowsky wrote:
I've been reading the draft and checking it against my experience. Because
of local power fluctuations, I've just accidentally checked my system: My
system does *not* survive a power hit. This has happened twice already
Moshe Yudkowsky wrote:
I've been reading the draft and checking it against my experience.
Because of local power fluctuations, I've just accidentally checked my
system: My system does *not* survive a power hit. This has happened
twice already today.
I've got /boot and a few other pieces in
Robin Hill wrote:
This is wrong - the disk you boot from will always be hd0 (no matter
what the map file says - that's only used after the system's booted).
You need to remap the hd0 device for each disk:
grub --no-floppy EOF
root (hd0,1)
setup (hd0)
device (hd0) /dev/sdb
root (hd0,1)
setup
Michael Tokarev wrote:
Speaking of repairs. As I already mentioned, I always use small
(256M..1G) raid1 array for my root partition, including /boot,
/bin, /etc, /sbin, /lib and so on (/usr, /home, /var are on
their own filesystems). And I had the following scenarios
happened already:
But
Moshe Yudkowsky wrote:
Michael Tokarev wrote:
Speaking of repairs. As I already mentioned, I always use small
(256M..1G) raid1 array for my root partition, including /boot,
/bin, /etc, /sbin, /lib and so on (/usr, /home, /var are on
their own filesystems). And I had the following
On Sun Feb 03, 2008 at 02:46:54PM -0600, Moshe Yudkowsky wrote:
Robin Hill wrote:
This is wrong - the disk you boot from will always be hd0 (no matter
what the map file says - that's only used after the system's booted).
You need to remap the hd0 device for each disk:
grub --no-floppy EOF
25 matches
Mail list logo
