Messages in this thread | | | Date | Tue, 18 Sep 2007 19:44:59 -0700 | From | Randy Dunlap <> | Subject | Re: iso9660 vs udf |
| |
On Wed, 19 Sep 2007 08:05:32 +0530 (IST) Satyam Sharma wrote:
> Hi Andries, > > > On Wed, 19 Sep 2007, Andries E. Brouwer wrote: > > > > On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote: > > > > > > > On the other hand, this filesystem announces itself as UDF > > > > > ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"), > > > > > perhaps the kernel code should be more robust. > > > > > > Could you send the complete dmesg log, and what you mean with filesystem/ > > > kernel (incorrectly?) announcing it as UDF here ... I agree with Jan, > > > this sounds like an issue with mount(8) to me. > > > > You already got the relevant part of the dmesg log. Slightly more below. > > > Failed mount: > > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078) > > udf: udf_read_inode(ino 547) failed !bh > > UDF-fs: Error in udf_iget, block=1, partition=1 > > Ok, like said, this comes from udf_fill_super(), but which shouldn't > have been called for this CD in the first place -- i.e. mount(8) shouldn't > have tried to mount a non-UDF filesystem as UDF (unless explicitly asked > as such). I was actually asking for the logs explaining why you thought > the _kernel_ incorrectly "announced" it as an UDF filesystem. > > Hmm ... those "CD-RTOS", "CD-BRIDGE" and "CDUDF File System - Adaptec Inc" > bits are not dmesg output, are they? Looks like "hwinfo --cdrom" or > "isoinfo" or some such. > > > I think the filesystem can be treated both as iso9660 and as udf, > > at least that is what I seem to recall CD-BRIDGE means. Thus, > > if the kernel cannot mount it as udf, I think it is a kernel flaw. > > Given that kernel flaw, and the fact that mounting as iso9660 works, > > mount(8) could work around the kernel problem by guessing iso9660. > > But maybe we should first try to fix the kernel. > > I don't think that is what CD-BRIDGE means -- so no kernel flaw :-) > What happened here is simply that in the absence of a "-t" option, > mount(8) defaulted (probably due to incorrect heuristics?) to UDF for > some reason, thereby obviously failing. I don't know who maintains > mount(8) / util-linux package, or do distributions have their own > maintainers these days (?)
Hi,
Adrian took over util-linux, but hasn't made any releases lately, so one of the RHAT developers is maintaining util-linux-ng: http://userweb.kernel.org/~kzak/util-linux-ng/
--- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/
| |