Announcement

Collapse
No announcement yet.

EXT4 Lets Us Down, There Goes Our R600/700 Mesa Tests

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Adarion
    replied
    Sad to hear all that work is gone. Well, at least you can file a bug report.

    But: there is an ooold rule.

    Backups.

    Do them on physically separate data carriers.

    I learned that about 8 years ago during a HW failure. And I was happy that I had at least 50% of my data off that drive. I was in a backup process when it fubared

    And: Don't use unfinished file systems. I keep away from any of the new ones, may they have performace better, I do not care. Data safety is much more important. One can use them when they're ready.
    I just find it hilarious the see the many bugs and problems ext4 causes while it was announced to be the greatest since readily cut bread. Wasn't it iirc some of the devs of etx4 that were agains the ?ber-Filesystem reiser4 to go into kernel? And that's some years ago.

    Anyway.
    Hope you'll find the time to redo the benchmarks.

    Leave a comment:


  • jwilliams
    replied
    The cat ate my homework, heh. Blame ext4, that's the ticket.

    Leave a comment:


  • Michael
    replied
    Originally posted by [Knuckles] View Post
    Couldn't edit my previous post: the limit for editing is now 1 minute? Geez.
    http://www.phoronix.com/forums/showt...041#post110041

    Leave a comment:


  • [Knuckles]
    replied
    Originally posted by [Knuckles] View Post
    If you haven't yet overwritten the fs, you might want to take a look at these
    And one more link from my ext recovery bookmark archive:
    http://www.linux.com/archive/feature/141074

    Couldn't edit my previous post: the limit for editing is now 1 minute? Geez.

    Leave a comment:


  • [Knuckles]
    replied
    If you haven't yet overwritten the fs, you might want to take a look at these:
    http://extundelete.sourceforge.net/
    http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html
    http://groups.google.com/group/ext3grep

    Unlike what many people think, it *is* possible to recover deleted and thought-lost files on ext2/3/4 filesystems.

    Loosing data sucks. The other day I blew up a HDD due to a badly-designed cable that switched 5V with 12V, and more recently due to a crash and corruption in zfs-fuse. And, as I have learned, the great ZFS (TM) unlike other fs's, doesn't have *any* real option to try and recover files, because it is so great (TM) that problems just doesn't happen (or you should have used raid, because every normal user should run all of his systems on raid). But I digress...

    Leave a comment:


  • Kazade
    replied
    This is why I use Ext3 for /home and Ext4 for /

    I don't need the extra speed when accessing my documents, but I need reliability. Likewise, I can take a hit on reliability, for a faster boot time.

    Don't trust Ext4.

    Leave a comment:


  • Michael
    replied
    Originally posted by chithanh View Post
    Next time store test results remotely, eg. on NFS. That way a software or hardware failure on the test box will not cause loss of the test data.
    Or will just build the mentioned support into Phoromatic, much cleaner, easier, and more efficient that way.

    Leave a comment:


  • Michael
    replied
    Originally posted by Smorg View Post
    BTW: that has to be a pain swapping out all those cards. Are they hotswappable or something, or you use the kernel soft reboots?
    Just been turning it off, swapping the card, cleanly powering the system back up.

    Leave a comment:


  • chithanh
    replied
    Next time store test results remotely, eg. on NFS. That way a software or hardware failure on the test box will not cause loss of the test data.

    Leave a comment:


  • Smorg
    replied
    Originally posted by RobbieAB View Post
    *cough* back-ups *cough*

    Sorry, as a Hell-Desk worker, I can't find much sympathy with any techie loosing more than a days data.
    Yeah any testing that involves likely and repeated crashing and hard restarts means backups and fscks are mandatory IMO. I'd do it over a network and just write the results directly over NFS or rsync or something.

    If I'm bisecting a panic-inducing kernel commit, or testing unstable overclock settings with mprime i always backup beforehand. Same would apply to testing a boatload of video cards likely to cause an X lockup, though you can sometimes ssh in and reboot 'gracefully' from those.

    BTW: that has to be a pain swapping out all those cards. Are they hotswappable or something, or you use the kernel soft reboots?

    Leave a comment:

Working...
X