Page 1 of 6 123 ... LastLast
Results 1 to 10 of 67

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

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,345

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

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

    For the past several days benchmarks have been going on a plethora of ATI Radeon HD 2000/3000/4000 (R600/700 generation) graphics cards as well as some of the older Radeon X1000 (R500) hardware for reference. All of this testing has been done with the current open-source ATI driver stack with Mesa to show where the performance is at for the H1'2010 Linux distributions...

    http://www.phoronix.com/vr.php?view=Nzk0OA

  2. #2
    Join Date
    Mar 2009
    Posts
    141

    Default

    Alright already. We get it. Ext4 sucks. Quitcherbitchin' about it in every other article.

  3. #3
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default reisub

    I can't guarantee that it would have worked in this instance, but way back when I still used to get hard locks with my ati card the alt+sysrq+reisub sequence saved me quite a lot of data, especially the s part.

  4. #4
    Join Date
    Mar 2009
    Posts
    141

    Default

    sucks about the lost tests though. i noticed data loss / corruption problems in the early 2.6.32-rcs, but haven't had a problem since. (of course most likely at the cost of performance.

    Perhaps ext3 will be a better option until btrfs is stabilized.

  5. #5
    Join Date
    Feb 2010
    Posts
    11

    Default

    Actually, it may not be an actual EXT4 bug. I was doing some work a few days ago on a tmpfs (I'm also using .32 kernel) and the whole directory just disappeared, by itself, while I'm using EXT4 for a long time already, and I haven't lost a single file to it. And yes, I've done quiet a few hard reboots through this filesystem's lifetime. (Well, this one may be perhaps unrelated, I'm just saying that it may be a bug elsewhere.)

  6. #6
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    821

    Default

    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.

  7. #7

    Default

    Quote 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.

  8. #8
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    953

    Default

    Quote Originally Posted by Michael View Post
    Or will just build the mentioned support into Phoromatic, much cleaner, easier, and more efficient that way.
    A good idea, or even writing the data to an external drive

  9. #9
    Join Date
    Jul 2007
    Posts
    30

    Default

    Quote 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.
    Absolutely seconded! Why you don't have a NAS box to store all your data on is beyond me. Sure, for individual test runs you want them on a local disk... but core data should be on mirrored and backed up disks.

    Belt and suspenders! But I suspect you know all this, and I'm sure you've already run into some of the problems with Ubuntu Lucid with a NFS home directory. It just sucks...

    John

  10. #10
    Join Date
    Jul 2008
    Posts
    4

    Default

    Sigh...

    Well, personaly i don't post much often here, but i think some people are missing the main point here: A kernel loockup was the origin of all the problem. In case people don't know, ANY filesystem that make use of heavy caching systems (This is: data is read, maintained in RAM, reported as written, but the real write is done when system is free of work most of the time) will lose data in an lockup/panic event at some point and some time. This is unievitable. The problem is known for every OS out there, and there are many solutions to the problem, some better than others. In the EXT4 case, this filesystem is still WAY prone to these events than EXT3, but less than other high performance filesystems. Is the cost of speed: Do you want a faster filesystem??? you have to trade reliability for speed. There's no other way to deal with it. (Do you want a HARD DISK cheaper, then deal with shot life Hard disks, that are more prone to the "Click of Death" problems, for example.)

    In enterprise ambients, you don't use the lastest and greatest: You use the OLDER and SAFER versions of software, since data is critical to many operations. And Backup often, and the most redundantly possible as your resources allows, since NO MEDIUM is free of data corruption.

    Is a pity that the data of the PTS was lost in these events, but since you are testing the lastest and greatest, the bugs that come from such systems are also "greastest". That's how development of software is done in this times: You release something buggy, you fix it later with a patch or service pack, or whatever is called fix. And sadly, this has become the norm in every development area, be open source or closed source.

    Times are changing, somebody says long time ago.

    As usual (well.. not usual here ) my viewpoints are from my experiences and as usual in this funny world: Your Mileage May Vary.

    Best Regards.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •