DVD-RAM media failures

Bug #601361 reported by Dan McGrath
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

I don't know for sure if this is a kernel related bug, or other.

Basically, I am trying to use DVD-RAM discs with ubuntu. I can run mkudffs just fine and create the media, but after I start writting to the media, the system starts blocking lots of stuff. An example of a side effect is:

Jul 3 06:43:12 wks kernel: [ 2640.430057] INFO: task dpkg:2512 blocked for more than 120 seconds.
Jul 3 06:43:12 wks kernel: [ 2640.430061] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 3 06:43:12 wks kernel: [ 2640.430063] dpkg D 0000000000000002 0 2512 1991 0x00000000
Jul 3 06:43:12 wks kernel: [ 2640.430067] ffff88002f727db8 0000000000000086 0000000000015bc0 0000000000015bc0
Jul 3 06:43:12 wks kernel: [ 2640.430071] ffff8800674e9ab0 ffff88002f727fd8 0000000000015bc0 ffff8800674e96f0
Jul 3 06:43:12 wks kernel: [ 2640.430074] 0000000000015bc0 ffff88002f727fd8 0000000000015bc0 ffff8800674e9ab0
Jul 3 06:43:12 wks kernel: [ 2640.430077] Call Trace:
Jul 3 06:43:12 wks kernel: [ 2640.430084] [<ffffffff811663f0>] ? bdi_sched_wait+0x0/0x20
Jul 3 06:43:12 wks kernel: [ 2640.430087] [<ffffffff811663fe>] bdi_sched_wait+0xe/0x20
Jul 3 06:43:12 wks kernel: [ 2640.430091] [<ffffffff81541bbf>] __wait_on_bit+0x5f/0x90
Jul 3 06:43:12 wks kernel: [ 2640.430094] [<ffffffff811663f0>] ? bdi_sched_wait+0x0/0x20
Jul 3 06:43:12 wks kernel: [ 2640.430096] [<ffffffff81541c68>] out_of_line_wait_on_bit+0x78/0x90
Jul 3 06:43:12 wks kernel: [ 2640.430100] [<ffffffff81085470>] ? wake_bit_function+0x0/0x40
Jul 3 06:43:12 wks kernel: [ 2640.430102] [<ffffffff811663b4>] ? bdi_queue_work+0xa4/0xe0
Jul 3 06:43:12 wks kernel: [ 2640.430105] [<ffffffff8116776f>] bdi_sync_writeback+0x6f/0x80
Jul 3 06:43:12 wks kernel: [ 2640.430107] [<ffffffff811677a0>] sync_inodes_sb+0x20/0x30
Jul 3 06:43:12 wks kernel: [ 2640.430110] [<ffffffff8116b272>] __sync_filesystem+0x82/0x90
Jul 3 06:43:12 wks kernel: [ 2640.430112] [<ffffffff8116b359>] sync_filesystems+0xd9/0x130
Jul 3 06:43:12 wks kernel: [ 2640.430115] [<ffffffff8116b411>] sys_sync+0x21/0x40
Jul 3 06:43:12 wks kernel: [ 2640.430119] [<ffffffff810131b2>] system_call_fastpath+0x16/0x1b

Jul 3 07:07:34 wks kernel: [ 4102.723114] UDF-fs INFO UDF: Mounting volume 'LinuxUDF', timestamp 2010/06/28 17:51 (1f10)
Jul 3 07:07:58 wks kernel: [ 4126.593207] udf: udf_read_inode(ino 214403) failed !bh
Jul 3 07:07:58 wks kernel: [ 4126.597893] udf: udf_read_inode(ino 214411) failed !bh
Jul 3 07:07:58 wks kernel: [ 4126.603855] udf: udf_read_inode(ino 214433) failed !bh

The last paste above is what happens when I reinsert the DVD-RAM disk into the drive after an unclean eject, so it's somewhat expected.

I have had successful writes to the media though. But what I have noticed is that if I write some data to the disc, then issue an umount, it unmounts after only blocking for about 10 seconds, but still continues to write in the background. But then if I type "sync", it blocks forever (at least 1hour+, until I eject and give up) while the drive activity light goes solid and other things stop responding.

Shouldn't the kernel block any umount requests until the data is fully written to the disc? It seems like a bug that umount succeeds even though the data is being written in the background.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: mount 2.17.2-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-23.37-generic
Uname: Linux 2.6.32-23-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
CheckboxSubmission: c3db184c2753f743b7cb62d6a698ae29
CheckboxSystem: da9af3b901b5569a389df6337f3d812f
Date: Sat Jul 3 08:57:47 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
SourcePackage: util-linux

Revision history for this message
Dan McGrath (troubled) wrote :
priya (priyamtk)
affects: ubuntu → libburn (Ubuntu)
Revision history for this message
Dan McGrath (troubled) wrote :

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?

Revision history for this message
kurt belgrave (trinikrono) wrote :

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.

Revision history for this message
kurt belgrave (trinikrono) wrote :

wow ignore that

Revision history for this message
kurt belgrave (trinikrono) wrote :

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

affects: libburn (Ubuntu) → linux (Ubuntu)
Revision history for this message
Dan McGrath (troubled) wrote :

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?

Revision history for this message
kurt belgrave (trinikrono) wrote :

Hey Danny
I found a Forum thread that deals with what you are trying to do. Can you test the solutions posted there?

Revision history for this message
Dan McGrath (troubled) wrote :

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.

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

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

tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Dan McGrath (troubled) wrote :

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.

tags: removed: needs-upstream-testing
Revision history for this message
Dan McGrath (troubled) wrote :

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

Revision history for this message
nutznboltz (nutznboltz-deactivatedaccount) wrote :

"bdi_sync_writeback()" is the key.

Search for "writeback" in

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

Revision history for this message
Dan McGrath (troubled) wrote :

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.


Revision history for this message
Steve Conklin (sconklin) wrote :

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.


Revision history for this message
Dan McGrath (troubled) wrote :

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 :)

Revision history for this message
Dan McGrath (troubled) wrote :

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!

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.