Hello, Fedorans!
Why doesn't:
[root@introdesk ~]# shutdown -Fr now
run xfs_repair instead of a check (I'm not shure if it runs xfs_check, it just replays the journal).
How can I schedule a xfs_repair @ next boot?
Renich Bon Ciric wrote:
Hello, Fedorans!
Why doesn't:
[root@introdesk ~]# shutdown -Fr now
run xfs_repair instead of a check (I'm not shure if it runs xfs_check, it just replays the journal).
How can I schedule a xfs_repair @ next boot?
Hello,
As you have noted, xfs tends to repair itself at mount time by replaying the journal.
xfs_check is a tool for fixing more serious low-level issues with xfs. xfs_check is not fsck.
Why do you think you need to run xfs_repair ?
In my experience, the only time xfs_repair has been required is when there have been hardware issues with the controller, storage driver, cabling, or with the physical drive.
Generally speaking, an xfs file system will heal itself without any user intervention, unless there are more sinister things at play.
Regards,
Dan
On Thu, 2008-05-01 at 23:01 +1000, Dan wrote:
Hello,
Hello, Dan. Thank you for your input!
As you have noted, xfs tends to repair itself at mount time by replaying the journal.
Well we would have to diff the "replaying the journal" and "repairing inconsistency" concepts...
xfs_check is a tool for fixing more serious low-level issues with xfs. xfs_check is not fsck.
yes, I realized when I cat /sbin/fsck.xfs ... ;=s
Why do you think you need to run xfs_repair ?
When the power goes off or my PC freezes (check out the firefox freezing thread) I have to do a hard reset. This, sometimes, generates inconsistencies on the fs.
In my experience, the only time xfs_repair has been required is when there have been hardware issues with the controller, storage driver, cabling, or with the physical drive.
For example, once, I had to do an xfs_repair because certain /usr/share/doc directory was inaccessible and was causing all kinds of trouble when yum upgrade -y was run by me.
xfs_repair did the job well. I would like to be able to run it without having to reboot to the rescue cd... Or, maybe, generating a rescue partition would be cool too!
Generally speaking, an xfs file system will heal itself without any user intervention, unless there are more sinister things at play.
Regards,
Dan
Renich Bon Ciric wrote:
Why do you think you need to run xfs_repair ?
When the power goes off or my PC freezes (check out the firefox freezing thread) I have to do a hard reset. This, sometimes, generates inconsistencies on the fs.
Fair enough. I have found xfs to be extremely tolerant of power failures. Indeed, at my previous residence, brief power outages and brown outs would be a monthly occurance.
Have you tried ext3 on this system? Does ext3 get corrupted from power outages and hard resets?
For example, once, I had to do an xfs_repair because certain /usr/share/doc directory was inaccessible and was causing all kinds of trouble when yum upgrade -y was run by me.
A few years ago I had a PCI firewire card in my machine, with an external usb2/firewire drive enclosure. Doing pretty much any kind of I/O would render the drive inaccessable. In the end it turned out that my firewire card was dodgy; when using usb2 there were no such problems.
I needed to use xfs_repair here to recover data several times before i got a clue. Funnily enough, I even formatted the drive with ext3 thinking there was a problem with xfs and firewire, but the corruption continued.
The fireware card behaved the same on a windows machine. Do pretty much any I/O and ntfs would be seriously corrupted.
xfs_repair did the job well. I would like to be able to run it without having to reboot to the rescue cd... Or, maybe, generating a rescue partition would be cool too!
This probably is not much good to you now, more for when you next install Fedora. However, you may wish to partition your drive(s). Put /home /tmp /usr /var on separate partitions. This way, you can boot or switch into runlevel 1 and run xfs_repair against pretty much any fs, but only as long as your root fs is working.
On Fri, 2008-05-02 at 10:19 +1000, Dan wrote:
Renich Bon Ciric wrote:
Why do you think you need to run xfs_repair ?
When the power goes off or my PC freezes (check out the firefox
freezing
thread) I have to do a hard reset. This, sometimes, generates inconsistencies on the fs.
Fair enough. I have found xfs to be extremely tolerant of power failures. Indeed, at my previous residence, brief power outages and brown outs would be a monthly occurance.
Have you tried ext3 on this system? Does ext3 get corrupted from power outages and hard resets?
Well, I used to have ext3 installed... I find xfs faster and better in overall. That's all I have to say.
For example, once, I had to do an xfs_repair because certain /usr/share/doc directory was inaccessible and was causing
all
kinds of trouble when yum upgrade -y was run by me.
A few years ago I had a PCI firewire card in my machine, with an external usb2/firewire drive enclosure. Doing pretty much any kind of I/O would render the drive inaccessable. In the end it turned out that my firewire card was dodgy; when using usb2 there were no such problems.
I needed to use xfs_repair here to recover data several times before i got a clue. Funnily enough, I even formatted the drive with ext3 thinking there was a problem with xfs and firewire, but the corruption continued.
The fireware card behaved the same on a windows machine. Do pretty much any I/O and ntfs would be seriously corrupted.
xfs_repair did the job well. I would like to be able to run it
without
having to reboot to the rescue cd... Or, maybe, generating a rescue partition would be cool too!
This probably is not much good to you now, more for when you next install Fedora. However, you may wish to partition your drive(s). Put /home /tmp /usr /var on separate partitions. This way, you can boot or switch into runlevel 1 and run xfs_repair against pretty much any fs, but only as long as your root fs is working.
Well, usually, my problems are @ the root partition. I do use a separate partition for /home and /boot and that's about it...
Thanks, Dan, for your input, once again.
Renich Bon Ciric wrote:
On Fri, 2008-05-02 at 10:19 +1000, Dan wrote:
Have you tried ext3 on this system? Does ext3 get corrupted from power outages and hard resets?
Well, I used to have ext3 installed... I find xfs faster and better in overall. That's all I have to say.
The point I was trying to make is that if you experienced corruption using ext3 on the same system, you may have a hardware problem somewhere, albeit an obscure one.
I too find xfs is faster and generally superior to ext3.
Cheers,
Dan
Have you tried ext3 on this system? Does ext3 get corrupted from power outages and hard resets?
Well, I used to have ext3 installed... I find xfs faster and better in overall. That's all I have to say.
Did ext3 get the same corruption on your box however - that is really important to understand whether the problem is xfs or your box.
You may also want barriers enabled if you are working with a box that keeps crashing (at least until you sort out why and fix the underlying crashes)
On Fri, 2008-05-02 at 16:47 +0100, Alan Cox wrote:
Did ext3 get the same corruption on your box however - that is really important to understand whether the problem is xfs or your box.
Hello, Alan!
Well, the corruption my HDDs underwent where on another machine... Caused by frequent power loss. fsck took too long. This was one of the many performance factors that made me change to xfs (after reading a bit, of course)
I have a new, all-powerful, machine now. SATA II, AMD X2 processor, and all kinds of cool stuff.
You may also want barriers enabled if you are working with a box that keeps crashing (at least until you sort out why and fix the underlying crashes)
Anyway, what do you mean by "barriers"?
Oh, by the way, the crashes have stoped since I use evince... I'll just wait for a firefox update and see if it gets fixed, else, file a bug...
On Fri, May 02, 2008 at 13:40:27 -0500, Renich Bon Ciric renich@woralelandia.com wrote:
Anyway, what do you mean by "barriers"?
There is a write barriers funcvtion supported by various block devices and file systems. It allows you to guaranty that some data has made it to permanent storage before writing other data. When used with journaling file systems, you should get constistant data when rebooting after a crash.
On Sat, 2008-05-03 at 14:53 -0500, Bruno Wolff III wrote:
On Fri, May 02, 2008 at 13:40:27 -0500, Renich Bon Ciric renich@woralelandia.com wrote:
Anyway, what do you mean by "barriers"?
There is a write barriers funcvtion supported by various block devices and file systems. It allows you to guaranty that some data has made it to permanent storage before writing other data. When used with journaling file systems, you should get constistant data when rebooting after a crash.
Ha! great! thanks a lot!