8.0-RC2 mangles msdosfs

[Alexander Best]

i've experienced similar issues with msdosfs. it seems especially
/sbin/fsck_msdosfs needs some updating.

cheers.
alex
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Dominic Fandrey-2]

Alexander Best wrote:
> i've experienced similar issues with msdosfs. it seems especially
> /sbin/fsck_msdosfs needs some updating.
>
> cheers.
> alex

Not only that, write access is really broken.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Alexander Best]

Dominic Fandrey schrieb am 2009-10-31:
> Alexander Best wrote:
> > i've experienced similar issues with msdosfs. it seems especially
> > /sbin/fsck_msdosfs needs some updating.

> > cheers.
> > alex

> Not only that, write access is really broken.

looks like someone with really good fs/fat16/fat32 knowledge needs to take a
look at this.

seems fat16/fat32 quality has been steadily going down hill since releng_4
imo.

i guess the freebsd-fs@ guys know about these problems but don't have the time
to deal with it. most of them are probably working on zfs.

good thing however that you posted a pr (kern/140134). hope somebody will step
up and fix the msdosfs code.

alex
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Mark Linimon-2]

On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote:
> i guess the freebsd-fs@ guys know about these problems but don't have
> the time to deal with it.  most of them are probably working on zfs.

AFAIK there are only a handful of people working on ZFS.

We certainly need more people willing to work on filesystems code.  In
general it does have a large learning curve, so it's not as attractive
as some of the other areas.  That's probably why, as the kernel has
undergone radical changes (e.g. for SMP) over time, that some of the
fs code has not kept up.

mcl
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Paul G Webster-2]

As an example, this is a 1GB fat32 disk.


da0 at umass-sim0 bus 0 target 0 lun 0
da0: <LG USB Drive 1100> Removable Direct Access SCSI-0 device
da0: 1.000MB/s transfers
da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C)
desktop1# ls /dev | grep da0~
desktop1# ls /dev | grep da0
da0
desktop1# fdisk /dev/da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 114 (0x72),(unknown)
     start 778135908, size 1141509631 (557377 Meg), flag 6f
        beg: cyl 357/ head 116/ sector 40;
        end: cyl 357/ head 32/ sector 45
The data for partition 2 is:
sysid 101 (0x65),(Novell Netware/386 3.xx)
     start 168689522, size 1936028240 (945326 Meg), flag 69
        beg: cyl 288/ head 115/ sector 43;
        end: cyl 367/ head 114/ sector 50
The data for partition 3 is:
sysid 121 (0x79),(QNX4.x 3rd part)
     start 1869881465, size 1936028192 (945326 Meg), flag 73
        beg: cyl 366/ head 32/ sector 33;
        end: cyl 357/ head 32/ sector 43
The data for partition 4 is:
sysid 13 (0x0d),(unknown)
     start 0, size 3637226496 (1775989 Meg), flag 74
        beg: cyl 372/ head 97/ sector 50;
        end: cyl 0/ head 10/ sector 0
desktop1#


On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon <linimon@...>  
wrote:

> On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote:
>> i guess the freebsd-fs@ guys know about these problems but don't have
>> the time to deal with it.  most of them are probably working on zfs.
>
> AFAIK there are only a handful of people working on ZFS.
>
> We certainly need more people willing to work on filesystems code.  In
> general it does have a large learning curve, so it's not as attractive
> as some of the other areas.  That's probably why, as the kernel has
> undergone radical changes (e.g. for SMP) over time, that some of the
> fs code has not kept up.
>
> mcl
> _______________________________________________
> freebsd-current@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to  
> "freebsd-current-unsubscribe@..."
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Alexander Best]

Paul G Webster schrieb am 2009-11-03:
> As an example, this is a 1GB fat32 disk.

> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <LG USB Drive 1100> Removable Direct Access SCSI-0 device
> da0: 1.000MB/s transfers
> da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C)
> desktop1# ls /dev | grep da0~
> desktop1# ls /dev | grep da0
> da0
> desktop1# fdisk /dev/da0
> ******* Working on device /dev/da0 *******
> parameters extracted from in-core disklabel are:
> cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)

> parameters to be used for BIOS calculations are:
> cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)

> Media sector size is 512
> Warning: BIOS sector numbering starts with sector 1
> Information from DOS bootblock is:
> The data for partition 1 is:
> sysid 114 (0x72),(unknown)
>    start 778135908, size 1141509631 (557377 Meg), flag 6f
>         beg: cyl 357/ head 116/ sector 40;
>         end: cyl 357/ head 32/ sector 45
> The data for partition 2 is:
> sysid 101 (0x65),(Novell Netware/386 3.xx)
>    start 168689522, size 1936028240 (945326 Meg), flag 69
>         beg: cyl 288/ head 115/ sector 43;
>         end: cyl 367/ head 114/ sector 50
> The data for partition 3 is:
> sysid 121 (0x79),(QNX4.x 3rd part)
>    start 1869881465, size 1936028192 (945326 Meg), flag 73
>         beg: cyl 366/ head 32/ sector 33;
>         end: cyl 357/ head 32/ sector 43
> The data for partition 4 is:
> sysid 13 (0x0d),(unknown)
>    start 0, size 3637226496 (1775989 Meg), flag 74
>         beg: cyl 372/ head 97/ sector 50;
>         end: cyl 0/ head 10/ sector 0
> desktop1#

*lol* just tried this myself and my fdisk output looks just as bad as yours:

******* Working on device da0 *******
parameters extracted from in-core disklabel are:
cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 110 (0x6e),(unknown)
    start 1768187213, size 1701211749 (830669 Meg), flag 65
        beg: cyl 357/ head 114/ sector 46;
        end: cyl 10/ head 255/ sector 13
The data for partition 2 is:
sysid 255 (0xff),(Xenix bad blocks table)
    start 1953723749, size 980709985 (478862 Meg), flag 68
        beg: cyl 370/ head 108/ sector 37;
        end: cyl 78/ head 13/ sector 10
The data for partition 3 is:
sysid 116 (0x74),(unknown)
    start 1801683314, size 168652389 (82349 Meg), flag 20
        beg: cyl 371/ head 84/ sector 33;
        end: cyl 100/ head 101/ sector 32
The data for partition 4 is:
sysid 0 (0000),(unused)
    start 2885681152, size 54212 (26 Meg), flag 0
        beg: cyl 0/ head 0/ sector 0;
        end: cyl 0/ head 0/ sector 0

`file -s /dev/da0` reports:

/dev/da0: x86 boot sector, Microsoft Windows XP Bootloader (4.german) NTLDR,
code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved sectors 38,
Media descriptor 0xf8, heads 255, sectors 3903487 (volumes > 32 MB) , FAT (32
bit), sectors/FAT 3805, serial number 0x88e88370, unlabeled

`fdisk` in general seems to need some updates. this is the output if i call
`fdisk` without any args:

fdisk: mounted root fs resource doesn't match expectations (regexec returned
1)

alex

> On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon
> <linimon@...>  wrote:

> >On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote:
> >>i guess the freebsd-fs@ guys know about these problems but don't
> >>have
> >>the time to deal with it.  most of them are probably working on
> >>zfs.

> >AFAIK there are only a handful of people working on ZFS.

> >We certainly need more people willing to work on filesystems code.
> >In
> >general it does have a large learning curve, so it's not as
> >attractive
> >as some of the other areas.  That's probably why, as the kernel has
> >undergone radical changes (e.g. for SMP) over time, that some of the
> >fs code has not kept up.

> >mcl
> >_______________________________________________
> >freebsd-current@... mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to
> >"freebsd-current-unsubscribe@..."



> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Robert Noland]

On Tue, 2009-11-03 at 18:46 +0100, Alexander Best wrote:

> Paul G Webster schrieb am 2009-11-03:
> > As an example, this is a 1GB fat32 disk.
>
>
> > da0 at umass-sim0 bus 0 target 0 lun 0
> > da0: <LG USB Drive 1100> Removable Direct Access SCSI-0 device
> > da0: 1.000MB/s transfers
> > da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C)
> > desktop1# ls /dev | grep da0~
> > desktop1# ls /dev | grep da0
> > da0
> > desktop1# fdisk /dev/da0
> > ******* Working on device /dev/da0 *******
> > parameters extracted from in-core disklabel are:
> > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)
>
> > parameters to be used for BIOS calculations are:
> > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)
>
> > Media sector size is 512
> > Warning: BIOS sector numbering starts with sector 1
> > Information from DOS bootblock is:
> > The data for partition 1 is:
> > sysid 114 (0x72),(unknown)
> >    start 778135908, size 1141509631 (557377 Meg), flag 6f
> >         beg: cyl 357/ head 116/ sector 40;
> >         end: cyl 357/ head 32/ sector 45
> > The data for partition 2 is:
> > sysid 101 (0x65),(Novell Netware/386 3.xx)
> >    start 168689522, size 1936028240 (945326 Meg), flag 69
> >         beg: cyl 288/ head 115/ sector 43;
> >         end: cyl 367/ head 114/ sector 50
> > The data for partition 3 is:
> > sysid 121 (0x79),(QNX4.x 3rd part)
> >    start 1869881465, size 1936028192 (945326 Meg), flag 73
> >         beg: cyl 366/ head 32/ sector 33;
> >         end: cyl 357/ head 32/ sector 43
> > The data for partition 4 is:
> > sysid 13 (0x0d),(unknown)
> >    start 0, size 3637226496 (1775989 Meg), flag 74
> >         beg: cyl 372/ head 97/ sector 50;
> >         end: cyl 0/ head 10/ sector 0
> > desktop1#
>
> *lol* just tried this myself and my fdisk output looks just as bad as yours:
>
> ******* Working on device da0 *******
> parameters extracted from in-core disklabel are:
> cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl)
>
> parameters to be used for BIOS calculations are:
> cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl)
>
> Media sector size is 512
> Warning: BIOS sector numbering starts with sector 1
> Information from DOS bootblock is:
> The data for partition 1 is:
> sysid 110 (0x6e),(unknown)
>     start 1768187213, size 1701211749 (830669 Meg), flag 65
>         beg: cyl 357/ head 114/ sector 46;
>         end: cyl 10/ head 255/ sector 13
> The data for partition 2 is:
> sysid 255 (0xff),(Xenix bad blocks table)
>     start 1953723749, size 980709985 (478862 Meg), flag 68
>         beg: cyl 370/ head 108/ sector 37;
>         end: cyl 78/ head 13/ sector 10
> The data for partition 3 is:
> sysid 116 (0x74),(unknown)
>     start 1801683314, size 168652389 (82349 Meg), flag 20
>         beg: cyl 371/ head 84/ sector 33;
>         end: cyl 100/ head 101/ sector 32
> The data for partition 4 is:
> sysid 0 (0000),(unused)
>     start 2885681152, size 54212 (26 Meg), flag 0
>         beg: cyl 0/ head 0/ sector 0;
>         end: cyl 0/ head 0/ sector 0
>
> `file -s /dev/da0` reports:
>
> /dev/da0: x86 boot sector, Microsoft Windows XP Bootloader (4.german) NTLDR,
> code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved sectors 38,
> Media descriptor 0xf8, heads 255, sectors 3903487 (volumes > 32 MB) , FAT (32
> bit), sectors/FAT 3805, serial number 0x88e88370, unlabeled
>
> `fdisk` in general seems to need some updates. this is the output if i call
> `fdisk` without any args:

The important question is what does "gpart show" say about these
disks....

robert.

> fdisk: mounted root fs resource doesn't match expectations (regexec returned
> 1)
>
> alex
>
> > On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon
> > <linimon@...>  wrote:
>
> > >On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote:
> > >>i guess the freebsd-fs@ guys know about these problems but don't
> > >>have
> > >>the time to deal with it.  most of them are probably working on
> > >>zfs.
>
> > >AFAIK there are only a handful of people working on ZFS.
>
> > >We certainly need more people willing to work on filesystems code.
> > >In
> > >general it does have a large learning curve, so it's not as
> > >attractive
> > >as some of the other areas.  That's probably why, as the kernel has
> > >undergone radical changes (e.g. for SMP) over time, that some of the
> > >fs code has not kept up.
>
> > >mcl
> > >_______________________________________________
> > >freebsd-current@... mailing list
> > >http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > >To unsubscribe, send any mail to
> > >"freebsd-current-unsubscribe@..."
>
>
>
> > --
> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> _______________________________________________
> freebsd-current@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

--
Robert Noland <rnoland@...>
FreeBSD

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Paul G Webster-2]

NOTE: I apologize  to Mark Linimon he will get this message twice, I  
accidentally hit 'reply' instead of 'reply all'

Here is the comedy, I just realized... This box is FreeBSD desktop1.yuno  
7.2-RELEASE-p3 not 8-BETA2 I have to many desktops got a little confused  
between them.

Incidentally the BETA2 box shows the exact same results ill get the gpart  
information as soon as I can.

On Tue, 03 Nov 2009 18:01:05 -0000, Robert Noland <rnoland@...>  
wrote:

> On Tue, 2009-11-03 at 18:46 +0100, Alexander Best wrote:
>> Paul G Webster schrieb am 2009-11-03:
>> > As an example, this is a 1GB fat32 disk.
>>
>>
>> > da0 at umass-sim0 bus 0 target 0 lun 0
>> > da0: <LG USB Drive 1100> Removable Direct Access SCSI-0 device
>> > da0: 1.000MB/s transfers
>> > da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C)
>> > desktop1# ls /dev | grep da0~
>> > desktop1# ls /dev | grep da0
>> > da0
>> > desktop1# fdisk /dev/da0
>> > ******* Working on device /dev/da0 *******
>> > parameters extracted from in-core disklabel are:
>> > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)
>>
>> > parameters to be used for BIOS calculations are:
>> > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl)
>>
>> > Media sector size is 512
>> > Warning: BIOS sector numbering starts with sector 1
>> > Information from DOS bootblock is:
>> > The data for partition 1 is:
>> > sysid 114 (0x72),(unknown)
>> >    start 778135908, size 1141509631 (557377 Meg), flag 6f
>> >         beg: cyl 357/ head 116/ sector 40;
>> >         end: cyl 357/ head 32/ sector 45
>> > The data for partition 2 is:
>> > sysid 101 (0x65),(Novell Netware/386 3.xx)
>> >    start 168689522, size 1936028240 (945326 Meg), flag 69
>> >         beg: cyl 288/ head 115/ sector 43;
>> >         end: cyl 367/ head 114/ sector 50
>> > The data for partition 3 is:
>> > sysid 121 (0x79),(QNX4.x 3rd part)
>> >    start 1869881465, size 1936028192 (945326 Meg), flag 73
>> >         beg: cyl 366/ head 32/ sector 33;
>> >         end: cyl 357/ head 32/ sector 43
>> > The data for partition 4 is:
>> > sysid 13 (0x0d),(unknown)
>> >    start 0, size 3637226496 (1775989 Meg), flag 74
>> >         beg: cyl 372/ head 97/ sector 50;
>> >         end: cyl 0/ head 10/ sector 0
>> > desktop1#
>>
>> *lol* just tried this myself and my fdisk output looks just as bad as  
>> yours:
>>
>> ******* Working on device da0 *******
>> parameters extracted from in-core disklabel are:
>> cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl)
>>
>> parameters to be used for BIOS calculations are:
>> cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl)
>>
>> Media sector size is 512
>> Warning: BIOS sector numbering starts with sector 1
>> Information from DOS bootblock is:
>> The data for partition 1 is:
>> sysid 110 (0x6e),(unknown)
>>     start 1768187213, size 1701211749 (830669 Meg), flag 65
>>         beg: cyl 357/ head 114/ sector 46;
>>         end: cyl 10/ head 255/ sector 13
>> The data for partition 2 is:
>> sysid 255 (0xff),(Xenix bad blocks table)
>>     start 1953723749, size 980709985 (478862 Meg), flag 68
>>         beg: cyl 370/ head 108/ sector 37;
>>         end: cyl 78/ head 13/ sector 10
>> The data for partition 3 is:
>> sysid 116 (0x74),(unknown)
>>     start 1801683314, size 168652389 (82349 Meg), flag 20
>>         beg: cyl 371/ head 84/ sector 33;
>>         end: cyl 100/ head 101/ sector 32
>> The data for partition 4 is:
>> sysid 0 (0000),(unused)
>>     start 2885681152, size 54212 (26 Meg), flag 0
>>         beg: cyl 0/ head 0/ sector 0;
>>         end: cyl 0/ head 0/ sector 0
>>
>> `file -s /dev/da0` reports:
>>
>> /dev/da0: x86 boot sector, Microsoft Windows XP Bootloader (4.german)  
>> NTLDR,
>> code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved  
>> sectors 38,
>> Media descriptor 0xf8, heads 255, sectors 3903487 (volumes > 32 MB) ,  
>> FAT (32
>> bit), sectors/FAT 3805, serial number 0x88e88370, unlabeled
>>
>> `fdisk` in general seems to need some updates. this is the output if i  
>> call
>> `fdisk` without any args:
>
> The important question is what does "gpart show" say about these
> disks....
>
> robert.
>
>> fdisk: mounted root fs resource doesn't match expectations (regexec  
>> returned
>> 1)
>>
>> alex
>>
>> > On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon
>> > <linimon@...>  wrote:
>>
>> > >On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote:
>> > >>i guess the freebsd-fs@ guys know about these problems but don't
>> > >>have
>> > >>the time to deal with it.  most of them are probably working on
>> > >>zfs.
>>
>> > >AFAIK there are only a handful of people working on ZFS.
>>
>> > >We certainly need more people willing to work on filesystems code.
>> > >In
>> > >general it does have a large learning curve, so it's not as
>> > >attractive
>> > >as some of the other areas.  That's probably why, as the kernel has
>> > >undergone radical changes (e.g. for SMP) over time, that some of the
>> > >fs code has not kept up.
>>
>> > >mcl
>> > >_______________________________________________
>> > >freebsd-current@... mailing list
>> > >http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > >To unsubscribe, send any mail to
>> > >"freebsd-current-unsubscribe@..."
>>
>>
>>
>> > --
>> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>> _______________________________________________
>> freebsd-current@... mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to  
>> "freebsd-current-unsubscribe@..."

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Dominic Fandrey-2]

Alexander Best wrote:
> Paul G Webster schrieb am 2009-11-03:
> *lol* just tried this myself and my fdisk output looks just as bad as yours:

I think funny fdisk output is not that much of a problem.

I normally put a single file system on external drives and
don't bother partitioning. This is also a common default
for many portable audio players.

Heavy file system corruption with every write operation really
renders msdosfs completely unusable. Now, I've got to rip my
CDs and DVDs under FreeBSD and reboot into Windows to copy music
and videos onto my player. This is really annoying for such a
trivial use case.

And msdosfs is still the default file system for portable
devices, so it's an important desktop use case. Even in the
business world, where often restrictive networks render USB
sticks the only acceptable method of transporting large chunks
of data.

What I wonder is - are there more people who witness file
system corruption upon msdosfs writes (and don't forget
that either newfs_msdos or fsck_msdosfs is broken as well,
and that fsck_msdosfs certainly does not recognize
cross-linked files). The impact is so horrid that I had
to reformat my portable player (with Windows) and reinstall
the firmware to get it back going.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Dominic Fandrey-2]

Mark Linimon wrote:

> On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote:
>> i guess the freebsd-fs@ guys know about these problems but don't have
>> the time to deal with it.  most of them are probably working on zfs.
>
> AFAIK there are only a handful of people working on ZFS.
>
> We certainly need more people willing to work on filesystems code.  In
> general it does have a large learning curve, so it's not as attractive
> as some of the other areas.  That's probably why, as the kernel has
> undergone radical changes (e.g. for SMP) over time, that some of the
> fs code has not kept up.

Is there material, apart from the code, explaining the concepts
behind the FreeBSD file system code? File systems are an
interesting topic for anyone who likes to get into low level
stuff.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Alexey Shuvaev-2]

On Wed, Nov 04, 2009 at 02:50:21PM +0100, Dominic Fandrey wrote:

> Alexander Best wrote:
> > Paul G Webster schrieb am 2009-11-03:
> > *lol* just tried this myself and my fdisk output looks just as bad as yours:
>
> I think funny fdisk output is not that much of a problem.
>
> [snip]
>
> What I wonder is - are there more people who witness file
> system corruption upon msdosfs writes (and don't forget
> that either newfs_msdos or fsck_msdosfs is broken as well,
> and that fsck_msdosfs certainly does not recognize
> cross-linked files). The impact is so horrid that I had
> to reformat my portable player (with Windows) and reinstall
> the firmware to get it back going.
>

The relative silence on the mailing list seems to show it is not
the common problem...

~> uname -a
FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198671: Fri Oct 30 16:12:10 CET 2009     root@wep4035:/usr/obj/usr/src/sys/GENERIC  amd64

ugen7.2: <SanDisk> at usbus7
umass0: <SanDisk MobileMate Micro, class 0/0, rev 2.00/94.07, addr 2> on usbus7
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:1:0:-1: Attached to scbus1
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
(probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
da0: <Generic STORAGE DEVICE 9407> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7790MB (15954944 512 byte sectors: 255H 63S/T 993C)
GEOM: da0: partition 1 does not start on a track boundary.
GEOM: da0: partition 1 does not end on a track boundary.

~> gpart show da0
=>      63  15954876  da0  MBR  (7.6G)
        63      8129       - free -  (4.0M)
      8192  15946752    1  !11  (7.6G)

~> df
[snip]
/dev/da0s1             7969344  6322272  1647072    79%    /home/lexx/mnt

~> mount
[snip]
/dev/da0s1 on /home/lexx/mnt (msdosfs, local, nosuid, mounted by lexx)

This is a microSD card in a USB adaptor. Haven't any problems with it
up to date. However I use it more or less carefully by:
- trying to use only ASCII characters for filenames (from "C" locale) and
  avoiding any characters that require escaping in the shell,
- never ever detaching it without prior unmount
- if it matters I have never run fsck_msdosfs on it.

Just 0.02$,
Alexey.
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Szilveszter Adam]

Hello,

On Wed, Nov 04, 2009 at 02:50:21PM +0100, Dominic Fandrey wrote:
> What I wonder is - are there more people who witness file
> system corruption upon msdosfs writes (and don't forget
> that either newfs_msdos or fsck_msdosfs is broken as well,
> and that fsck_msdosfs certainly does not recognize
> cross-linked files). The impact is so horrid that I had
> to reformat my portable player (with Windows) and reinstall
> the firmware to get it back going.

Well, this is of course only anecdotal, but I do not witness corruption
with any of my USB-attached umass devices. (I no longer have a floppy
drive, and I do not have a FAT partition on my HDD either, so I cannot
test that). I am using 9.0-CURRENT, rev 198667 (but the problem did not
show also on earlier revs)

The devices that I use on and off:

- Meizu M3 Music Card audio player
- Cowon iaudio D2 audio player (According to user forums, this one is
  particularly sensitive to fs corruption)
- various USB sticks, most notably a Kingston Data Traveller 4G (I
  believe)
- Even the occasional memory stick, or SD card in card reader

However, I must also state that I never used fsck_msdosfs in the last
few years. Neither have I formatted any FAT file systems under FreeBSD for
years. Also, I always unmount the devices before removing them.

--
Regards:

Szilveszter ADAM
Budapest
Hungary
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Dominic Fandrey-2]

Szilveszter Adam wrote:
> Well, this is of course only anecdotal, but I do not witness corruption
> with any of my USB-attached umass devices.

A friend tried to reproduce my problem to no avail, so it appears to
be a rare issue. But I also can produce the problems with with file
system backed md devices, so it's not a USB issue.

I've first run into it on RC1, so rebuilding is not a solution, either.

> (I no longer have a floppy
> drive, and I do not have a FAT partition on my HDD either, so I cannot
> test that). I am using 9.0-CURRENT, rev 198667 (but the problem did not
> show also on earlier revs)
>
> The devices that I use on and off:
>
> - Meizu M3 Music Card audio player
> - Cowon iaudio D2 audio player (According to user forums, this one is
>   particularly sensitive to fs corruption)

I'm using a Cowon S9. When I added a couple of new songs to the
device, it complained about them to be corrupted (despite a proper
umount). So I ran fsck_msdosfs, which found quite a number of
problems and recopied the files.

After turning the device back on I only got random coloured garbage on
the screen, whenever I tried to access something.

I booted Windows and chkdsk reported all these problems (cross-linked
files and the like). But the player didn't recover until I reformatted
the whole mess.

> - various USB sticks, most notably a Kingston Data Traveller 4G (I
>   believe)
> - Even the occasional memory stick, or SD card in card reader
>
> However, I must also state that I never used fsck_msdosfs in the last
> few years. Neither have I formatted any FAT file systems under FreeBSD for
> years. Also, I always unmount the devices before removing them.
>

So do I. This didn't safe me, though.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Ulrich Spoerlein-3]

On Wed, 04.11.2009 at 16:40:44 +0100, Alexey Shuvaev wrote:

> On Wed, Nov 04, 2009 at 02:50:21PM +0100, Dominic Fandrey wrote:
> > Alexander Best wrote:
> > > Paul G Webster schrieb am 2009-11-03:
> > > *lol* just tried this myself and my fdisk output looks just as bad as yours:
> >
> > I think funny fdisk output is not that much of a problem.
> >
> > [snip]
> >
> > What I wonder is - are there more people who witness file
> > system corruption upon msdosfs writes (and don't forget
> > that either newfs_msdos or fsck_msdosfs is broken as well,
> > and that fsck_msdosfs certainly does not recognize
> > cross-linked files). The impact is so horrid that I had
> > to reformat my portable player (with Windows) and reinstall
> > the firmware to get it back going.
> >
> The relative silence on the mailing list seems to show it is not
> the common problem...

Indeed, on my main desktop, running 8.0something I regularly copy
MP3/OGG files to a FAT16 (!) MP3-Player and albeit the copying is slow
and produces "funny" dmesg output, I have yet to observe a corruption of
the FS.

Bye,
Uli
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."