Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751087AbWE2BPF (ORCPT ); Sun, 28 May 2006 21:15:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751085AbWE2BPF (ORCPT ); Sun, 28 May 2006 21:15:05 -0400 Received: from main.gmane.org ([80.91.229.2]:32233 "EHLO ciao.gmane.org") by vger.kernel.org with ESMTP id S1751087AbWE2BPE (ORCPT ); Sun, 28 May 2006 21:15:04 -0400 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: Salah Coronya Subject: Re: [UDF] (bogus?) overlap of directories and files + UDF oops Date: Sun, 28 May 2006 20:13:17 -0500 Message-ID: References: <20060528161858.GA4705@clipper.ens.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 71-14-84-46.dhcp.stls.mo.charter.com User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) In-Reply-To: <20060528161858.GA4705@clipper.ens.fr> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5798 Lines: 134 Nicolas George wrote: > Hi. > > > > I have a hard drive with an UDF filesystem, and something strange happened a > few weeks ago: I had a directory foo, then I created a file bar at a > completely different place; after that, foo was no longer a directory, it > was a plain file, a hard-link to the newly created bar, except that the link > count was wrong. Obviously there is a bug somewhere. > > Since then, I spent part of my free-time to dissect my filesystem, and I > found the following strange detail. > > > > > Some directories have eight allocated unrecorded (extent.length >> 30 == 1, > according to ECMA 167, 4/14.14.1.1, page 4/46) sectors at the end. The > strange thing is that some of these sectors also belong to others files or > directories, as recorded sectors. > > Is this situation normal? > > (For the record, I am currently using a 2.6.14.1 kernel, but I did not see > anything related in the ChangeLog of later releases.) > > > > PS: I managed to build and run fsck.udf from OpenSolaris under GNU/Linux, > but it seems to be limited to version 2 records, while Linux produces both > version 2 and version 3 records, so it did not help. I intend to release the > tools I have written to dissect my filesystem, but they still need a lot of > work. > > > Regards, > While were on the subject of UDF bugs, I can also reliably produce an oops updating a UDF filesystem (at least on a DVD-RW/DVD+RW/DVD-RAM, using the packet writer) cdrom: This disc doesn't have any tracks I recognize! pktcdvd: writer pktcdvd0 mapped to hdc pktcdvd: write speed 4155kB/s pktcdvd: 4473408kB available on disc UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2006/04/26 21:27 (1ed4) udf: udf_read_inode(ino 6454) failed !bh udf: udf_read_inode(ino 6454) failed !bh udf: udf_read_inode(ino 854577) failed !bh udf: udf_get_fileshortad() invalidparms udf: udf_read_inode(ino 854578) failed !bh udf: udf_read_inode(ino 854579) failed !bh udf: udf_read_inode(ino 854581) failed !bh udf: udf_read_inode(ino 854583) failed !bh udf: udf_read_inode(ino 854584) failed !bh udf: udf_read_inode(ino 854585) failed !bh udf: udf_read_inode(ino 854586) failed !bh udf: udf_read_inode(ino 854587) failed !bh udf: udf_read_inode(ino 854589) failed !bh udf: udf_get_fileshortad() invalidparms udf: udf_read_inode(ino 854590) failed !bh udf: udf_read_inode(ino 854591) failed !bh udf: udf_read_inode(ino 854576) failed !bh udf: udf_read_inode(ino 854576) failed !bh udf: udf_read_inode(ino 854580) failed !bh BUG: unable to handle kernel paging request at virtual address 0000194b printing eip: c01e6e56 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: it87 hwmon_vid eeprom lm90 i2c_isa pcspkr rtc snd_opl3_lib snd_cs4231_lib snd_hwdep snd_mpu401 analog ns558 parport_pc parport floppy i2c_prosavage 8139too mii snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd i2c_viapro via_agp agpgart pktcdvd dm_mirror dm_mod sata_mv ata_piix ahci sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil sata_promise libata sbp2 ohci1394 ieee1394 sl811_hcd ohci_hcd uhci_hcd usb_storage usbhid ehci_hcd usbcore CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.17-rc3-g30d55280 #1) EIP is at udf_get_filelongad+0x3d/0x4f eax: 00000000 ebx: d8e39ce8 ecx: 0000194b edx: 00000038 esi: c7cc1300 edi: d8e39ce8 ebp: c7cc1338 esp: d8e39c48 ds: 007b es: 007b ss: 0068 Process rsync (pid: 10903, threadinfo=d8e39000 task=dde29050) Stack: <0>0000194b c01e007e 0000194b 00001974 d8e39ce8 00000001 00000000 00000000 ffffffd2 c048b80e 00000202 c0119b4e d8e39ce0 d8e39cf8 c7cc1338 d8e39cec c01dff40 c7cc1338 d8e39ce0 d8e39ce8 d8e39cec d8e39cf4 d8e39cf8 00000001 Call Trace: udf_current_aext+0x12f/0x189 release_console_sem+0x9e/0xa2 udf_next_aext+0x78/0x87 udf_discard_prealloc+0x135/0x240 __udf_read_inode+0x55/0x1c0 udf_clear_inode+0x1c/0x37 clear_inode+0xa4/0xd2 generic_forget_inode+0x111/0x124 udf_iget+0x83/0x8b udf_lookup+0x80/0xb4 __cache_shrink+0x42/0x44 debug_mutex_add_waiter+0x7f/0x91 d_alloc+0x14/0x17f real_lookup+0x4d/0xa9 do_lookup+0x4a/0x7b __link_path_walk+0x748/0xb6d link_path_walk+0x3f/0xa7 do_path_lookup+0x1c9/0x22b getname+0x4a/0x51 __user_walk_fd+0x2a/0x3b vfs_lstat_fd+0x17/0x42 vfs_lstat+0xf/0x13 sys_lstat64+0x10/0x27 sysenter_past_esp+0x54/0x75 Code: c0 09 d0 a8 01 74 0f 68 7c c1 38 c0 e8 d3 29 f3 ff 5a 31 c0 eb 25 8b 03 85 c0 78 09 8d 50 10 3b 54 24 0c 76 04 31 c0 eb 12 31 c0 <83> 39 00 74 0b 83 7c 24 14 00 74 02 89 13 89 c8 5b c3 8b 4c 24 EIP: [] udf_get_filelongad+0x3d/0x4f SS:ESP 0068:d8e39c48 BUG: rsync/10903, lock held at task exit time! [c7610b3c] {inode_init_once} .. held by: rsync:10903 [dde29050, 117] ... acquired at: real_lookup+0x15/0xa9 A more serious problems is udftools (http://sourceforge.net/projects/linux-udf/) seems unmaintained (for 2+ years, at least) and the developer is MIA. Somebody - I think a Ubuntu developer tried to contact him with no response. There is a udffsck in udftools, but it won't help you :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/