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

  • Naib
    replied
    Originally posted by Michael View Post
    Usually it serves its purpose fine and worked well back when the problem with EXT4 was the empty files on crashes.
    Thats funny my home server is on ext4 (and has been for over a year) and last night I had two power cuts. No PSU so bam power loss YET I ain lost any files.

    nice std mount options for /<root> and /home as well
    ...


    But saying that my "backup" actually revolves around critical data mirrored on my desktop as well as every 3months burnt to DVD's

    but keeping the data in the same folder, on the same partition, on the same drive, in the same machine sounds a much better backup scheme. I shall be employing such a scheme immediately

    Leave a comment:


  • xeros
    replied
    Do you have any R300 an R400 cards to test them in these Mesa tests, too?

    Leave a comment:


  • dmbtech
    replied
    Originally posted by figvam View Post
    It's suspicious that the whole directory was purged. Could it be your testing software bug?
    Have you checked the lost+found directory? Have you checked the fsck output in the boot log?
    Oh yeah, and tons of left overs were in lost+found, obviously useless (some binary, some ascii, no filenames)

    Leave a comment:


  • dmbtech
    replied
    I'v had similar problems. Did a fresh install, upgraded the kernel to 2.6.32, tried some experimental radeon thing that hard locks, and had many files in many directories get screwed(including entire folders), along with an unbootable system. FSCK was going crazy, basically repeatedly fixing thousands of things (probably breaking it more). I don't understand how something like that passes QA testing. I was using a fakeraid setup, do not know if that makes it related or not.

    Leave a comment:


  • figvam
    replied
    It's suspicious that the whole directory was purged. Could it be your testing software bug?
    Have you checked the lost+found directory? Have you checked the fsck output in the boot log?

    Leave a comment:


  • lithorus
    replied
    It's becoming more tempting to switch to XFS, fall-back to EXT3, or just eagerly await the stabilization of Btrfs.
    So next time we'll see an article on how XFS ate your results? You do know that XFS is even worse in these kind of situation?

    Seriously, if you are doing benchmarks with graphic cards you know you are bound to get lock ups once in awhile...

    Leave a comment:


  • DanL
    replied
    Originally posted by DanL View Post
    The only problem is that it's impossible to know your probability of data loss without a time machine.
    Or, probability = 1 if Murphy's Law is correct.

    Leave a comment:


  • DanL
    replied
    Originally posted by bugmenot View Post
    For all those that are screaming "BACKUPS", please remember that backups only make sense if the ratio

    (Probability of data loss * Cost of data loss) / (Cost of backup)
    The only problem is that it's impossible to know your probability of data loss without a time machine.

    Leave a comment:


  • deanjo
    replied
    Originally posted by DeepDayze View Post
    A good idea, or even writing the data to an external drive
    It just seems to me that blaming the file system is a bit premature. It could just as easily be a controller driver bug or hd firmware issue.

    Leave a comment:


  • DeepDayze
    replied
    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

    Leave a comment:

Working...
X