DVD-RAM media failures

I recently found that when I use a standard mkfs on the DVD-RAM, it seems to work properly for the most part. I still notice that it continues to write it seems, after I umount the disc. Won't that lead to unclean unmounts?

Thanks for your bug report and for your contribution to ubuntu. In order to determine if this issue is plymouth related, please boot your computer with plymouth disabled and then shutdown to see if you can reproduce the issue? To disable plymouth for a single boot, follow these steps:

1. Press Esc during Grub boot delay to access the boot menu.
2. Select your actual Ubuntu boot line and press "e" to edit it.
3. Select the "linux" line and at the end of the line, remove "splash" and "quiet".
5. Type "ctrl + x" to boot the custom boot line.

wow ignore that

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in Ubuntu linux kernel (linux).

Heh, np. Btw, you might want to check out bug #601410. I cross posted the problem against two packages as I wasn't sure which the cause was, but I am starting to think that I am just supposed to use mkfs to use DVD-RAM.

That being said, is mkudffs meant to also provide a working RAM accessable filesystem as well?

Hey Danny
http://ubuntuforums.org/showthread.php?t=11513
I found a Forum thread that deals with what you are trying to do. Can you test the solutions posted there?
Cheers

Hi Kurt,

Thanks for the URL btw, but I believe that is the forum post that I used to learn about the mkudffs command originally.

It seems that mkudffs with the syntax they used does indeed laydown a udf filesystem on the disc, and I am able to read/write/delete from the disc, but it seems to stall on anything more than a megabyte or two, and ever stalls out some of the system daemons after umount and fs sync until I force eject the disc (since it never finishes writting it seems).

To give you an idea, the drive was writting for about 2 hours straight for a simple udffs based disc with a 800mb copy of the linux git tree. However, using standard mkfs.ext2 on the disc, allowed me to write the same git tree to the disc in only 10 or 15 minutes, and without any problems like daemons blocking and locking up the system (like nautalis). But even with mkfs, I did notice that the writes still seemed to be taking place post umount occassionally. But for the most part, mkfs seems to work great.

Hi Danny,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Attached is a copy of some tests and stuff I tried with the stock and the latest current kernel.

It would see that the latest maverick kernel build properly blocks on umount or sync until all the data is written.

Hope this helps. Let me know what else you need.

Just a screenshot of my load meters that I was referring to from the last report after umount and sync. Seems to confuse nautilus.

"bdi_sync_writeback()" is the key.

Search for "writeback" in
https://edge.launchpad.net/ubuntu/+source/linux/2.6.32-25.43

Also look for "writeback" in

Bug #543617
Bug #585092
Bug #601361
Bug #620242
Bug #628047

Try the proposed kernel version 2.6.32-25.43, see
https://wiki.ubuntu.com/Testing/EnableProposed

Thanks for the info there nutznboltz, I will have to take a look at the next kernel and take a look. The last kernel I tried (despite causing some minor breakage being a much newer kernel with different/incompatible options for 10.04 it seemed) seemed to solve the problem. Hopefully this is the cause of the issue,

I was debating trying to do a bisect, but it takes such a long time to do for something like this that I just figured that I would wait it out :)

Anyways, I will see if I can take a look in the next week or so and try out 2.6.32-25.43 for ya. Thanks.

Dan

We need some testing of the proposed kernel to see whether this has been resolved - please see comment #12 for information about how to get the proposed kernel.

Thanks

Hey Steve,

I am curious, did I not solve this (or answer this) question in #10, above? I recall spending an hour or two a month or two ago doing the whole testing kernel thing, and a whole slew of tests with the DVD-RAM media. Everything then was 100% flawless in my tests. I just hope to avoid doing an hour or two of tests every time a new kernel comes out if I can help it :)

After upgrading to 10.10, it seems that initial tests show that everything is fine now. I only tested with an existing ext2 fs that was on a DVD-RAM disc already, not with mkudffs. Although I would imagine it works fine.

Specifically, sync blocked properly and after exit, all activity to the DVD-RAM settled down. I also ran a git clone on the linux tree that caused problems before. It took about 40 minutes, but completed just fine as well.

I guess this is considered closed in the newer versions of ubuntu, but I will leave that for the ubuntu folk to decide. Thanks!

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]