Messages in this thread | | | Date | Mon, 14 Oct 2013 13:48:15 +0200 | From | Jan Kara <> | Subject | Re: PROBLEM: udf mount takes forever to fail + proposed solution |
| |
On Fri 11-10-13 23:46:37, Péter András Felvégi wrote: > OK, I'll prepare a new patch with explicit ID checks (BEA01, BOOT2, > CDROM, CD001, CDW02, NSR02, NSR03, TEA01, that's all I think) and the > needed changelog in a few days. Do you think that a hard upper limit > on the sector offset is desirable? The ISO9660 driver looks for the > first 100 sectors, but I didn't find anything in the specs suggesting > a max length for the udf volume recognition area. Certainly a bound like 100 sectors would likely be OK as well. But as you already said, there isn't any such a limit in the spec so we can only guess which limit to pick... If using fixed strings won't work out, using a limit like 100 sectors would probably be the next best solution for me.
Honza
> On 11 October 2013 17:18, Jan Kara <jack@suse.cz> wrote: > > Hello, > > > > On Thu 10-10-13 23:23:11, Péter András Felvégi wrote: > >> recently I made the mistake trying to mount an unformatted ssd > >> partition. The mount command 'hang', was unable to kill it. Top showed > >> the process is in the uninterruptible D state. However, iotop showed > >> slight activity, about 4M/s read from the disk that noone else used. > >> This was 100% reproducible. sync froze, too, if was given out after > >> the mount cmd. When trying to shut down the machine, it didn't stop, > >> just waited for something to happen. > >> > >> I narrowed down the problem to the UDF filesystem driver. In > >> fs/udf/super.c, udf_check_vsd() reads the sectors in a for loop, with > >> the following exit conditions: > >> - NSR02 or NSR03 descriptor is found > >> - the read fails > >> - vsd->stdIdent[0] == 0 > >> > >> Browsed through the UDF 2.6 spec, ECMA 167 and 119. As I understand, > >> the descriptors should start at offset 32768, forming a contiguous > >> sequence. In ECMA 167 it is stated that the sequence is terminated by > >> an invalid descriptor: unrecorded, or blank (all zeros). However, this > >> presupposes that the filesystem is UDF. > >> > >> Since the ssd partition was not formatted, it contained only 0xff > >> bytes, thus none of the exit conditions were met, and the function > >> read through the whole, in two passes. The runtime was pathetic, it > >> took the mount 350 minutes to fail. I have no clue why this was so > >> slow, reading through the partition with dd gives 482 secs for the > >> 220G, ~450M/s. Setting the blocksize to 512 or 2048 didn't make much > >> of a difference. > >> > >> I peppered the code with some messages to see what happens: > >> # time mount -t udf /dev/sdb3 /media/floppy > >> UDF-fs: check_vsd: sectorsize=2048 > >> UDF-fs: check_vsd: sector offs=32768, s_blocksize=512, s_blocksize_bits=9 > >> UDF-fs: read 107989660 sectors of total size 55290705920 bytes > >> UDF-fs: warning (device sdb3): udf_load_vrs: No VRS found > >> UDF-fs: Rescanning with blocksize 2048 > >> UDF-fs: check_vsd: sectorsize=2048 > >> UDF-fs: check_vsd: sector offs=32768, s_blocksize=2048, s_blocksize_bits=11 > >> UDF-fs: read 107989660 sectors of total size 221162823680 bytes > >> UDF-fs: warning (device sdb3): udf_load_vrs: No VRS found > >> UDF-fs: warning (device sdb3): udf_fill_super: No partition found (1) > >> mount: wrong fs type, bad option, bad superblock on /dev/sdb3, > >> missing codepage or helper program, or other error > >> In some cases useful info is found in syslog - try > >> dmesg | tail or so > >> real 352m4.740s > >> user 0m0.000s > >> sys 27m23.560s > >> > >> Tried to mount other partitions, too, formatted to ext3, ext4, btrfs > >> and ntfs. The mount failed with those sooner, accidentally just > >> because there were some blocks near to the beginning with a zero byte > >> just at the right place. > >> > >> Then I prepared an 'all 0xff' 4G image, and burnt it to a DVD. The > >> mount failed, but took only 25 minutes. 'Only', compared to the case > >> with the ssd. This truely doesn't reflect the throughput of the > >> devices, hopefully someone with more experience will have a clue. > > Thanks for the report and detailed analysis. Frankly, instead of your > > function checking the identifier, I'd rather follow the standard in detail > > and add handling (meaning ignore) of the remaining specified descriptors > > (CDW02, BOOT2) and bail out if anything else is found. If someone complains > > because some broken medium stops mounting, we can try something more > > elaborate but for now I'd go with the simple solution. > > > > Also please read Documentation/SubmittingPatches - your patch was missing a > > changelog entry (you can basically take your somewhat shortened email for > > that) and a Signed-off-by line. Thanks! > > > > Honza > > -- > > Jan Kara <jack@suse.cz> > > SUSE Labs, CR -- Jan Kara <jack@suse.cz> SUSE Labs, CR -- 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/
| |