[PATCH 1/1] partitions/msdos: Unable to mount UFS 44bsd partitions
UFS partitions from newer versions of FreeBSD 10 and 11 use relative addressing for their subpartitions. But older versions of FreeBSD still use absolute addressing just like OpenBSD and NetBSD. Instead of simply testing for a FreeBSD partition, the code needs to also test if the starting offset of the C subpartition is zero. https://bugzilla.kernel.org/show_bug.cgi?id=197733 Signed-off-by: Richard Narron <comet.berke...@gmail.com> --- --- a/block/partitions/msdos.c.orig 2017-11-05 13:05:14.0 -0800 +++ b/block/partitions/msdos.c 2017-11-06 09:46:00.148228242 -0800 @@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); - if (memcmp(flavour, "bsd\0", 4) == 0) + /* FreeBSD has relative offset if C partition offset is zero */ + if (memcmp(flavour, "bsd\0", 4) == 0 && + le32_to_cpu(l->d_partitions[2].p_offset) == 0) bsd_start += offset; if (offset == bsd_start && size == bsd_size) /* full parent partition, we have it already */
[PATCH 1/1] partitions/msdos: Unable to mount UFS 44bsd partitions
UFS partitions from newer versions of FreeBSD 10 and 11 use relative addressing for their subpartitions. But older versions of FreeBSD still use absolute addressing just like OpenBSD and NetBSD. Instead of simply testing for a FreeBSD partition, the code needs to also test if the starting offset of the C subpartition is zero. https://bugzilla.kernel.org/show_bug.cgi?id=197733 Signed-off-by: Richard Narron --- --- a/block/partitions/msdos.c.orig 2017-11-05 13:05:14.0 -0800 +++ b/block/partitions/msdos.c 2017-11-06 09:46:00.148228242 -0800 @@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); - if (memcmp(flavour, "bsd\0", 4) == 0) + /* FreeBSD has relative offset if C partition offset is zero */ + if (memcmp(flavour, "bsd\0", 4) == 0 && + le32_to_cpu(l->d_partitions[2].p_offset) == 0) bsd_start += offset; if (offset == bsd_start && size == bsd_size) /* full parent partition, we have it already */
Re: [git pull] first batch of ufs fixes
On Sun, 18 Jun 2017, Al Viro wrote:
On Sat, Jun 17, 2017 at 03:15:48AM +0100, Al Viro wrote:
On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
They seem to work fine with the simple testing that I do.
I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2
filesystems, 44bsd (ufs1) and ufs2.
I found no errors doing a Linux mkdir, copy large file, BSD fsck, Linux rm
large file, rmdir and BSD fsck in any of the 6 combinations.
FWIW, with xfstests I see the following:
* _require_metadata_journaling needs to be told not to bother with
our ufs
* generic/{409,410,411} lack $MOUNT_OPTIONS in several invocations
of mount -t $FSTYP; for ufs it's obviosuly a problem. Trivial bug in tests,
fixing it makes them pass.
* generic/258 (timestamp wraparound) fails; fs is left intact
Trivially fixed (cast to (signed) in ufs1_read_inode(), similar to what
other filesystems with 32bit timestamps are doing); ufs2 has no problem
at all)
* generic/426 (fhandle stuff) fails and buggers the filesystem
Everything else passes with no fs corruption that could be detected by
fsck.ufs.
Also trivially fixed - it's a self-inflicted wound. Just have zero nlink in
ufs{1,2}_read_inode() fail with -ESTALE instead of triggering ufs_error().
As for my immediate plans, I'll look into the two failing tests,
but any further active work on ufs will have to wait for the next
cycle. It had been a fun couple of weeks, but I have more than
enough other stuff to deal with. And I would still very much prefer
for somebody to adopt that puppy.
Another piece of fun spotted: the logics for switching between two allocation
policies when relocating a packed tail that can't be expanded in place had
been b0rken since typo in 2.4.14.7 - switch back from OPTTIME to OPTSPACE
had been screwed by this:
- usb1->fs_optim = SWAB32(UFS_OPTSPACE);
+ usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
And fragmentation levels for switching back and force really ought to be
calculated at mount time. Another (minor) issue is mentioned in this
commit message from Kirck McKusick back in 1995:
The threshold for switching from time-space and space-time is too small
when minfree is 5%...so make it stay at space in this case.
Not that minfree at 5% had been frequently seen - default has never been that
low (back in 4.2BSD it was 10%, these days it's 8%)
Resulting kernel passes xfstests clean and now I'm definitely done with UFS for
this cycle. Linus, in case you want to pull that sucker, pull request would
be as below:
The following changes since commit a8fad984833832d5ca11a9ed64ddc55646da30e3:
ufs_truncate_blocks(): fix the case when size is in the last direct block
(2017-06-15 03:57:46 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git ufs-fixes
for you to fetch changes up to 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1:
ufs: fix the logics for tail relocation (2017-06-17 17:22:42 -0400)
Al Viro (3):
fix signedness of timestamps on ufs1
ufs_iget(): fail with -ESTALE on deleted inode
ufs: fix the logics for tail relocation
fs/ufs/balloc.c | 22 ++
fs/ufs/inode.c | 27 +++
fs/ufs/super.c | 9 +
fs/ufs/ufs_fs.h | 2 ++
4 files changed, 28 insertions(+), 32 deletions(-)
I just tested these 3 patches along with the earlier 8 patches against
Linux 4.12-rc5 and they look fine. All 6 test cases look good.
The ufs code is much better now than it was before all these patches.
Re: [git pull] first batch of ufs fixes
On Sun, 18 Jun 2017, Al Viro wrote:
On Sat, Jun 17, 2017 at 03:15:48AM +0100, Al Viro wrote:
On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
They seem to work fine with the simple testing that I do.
I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2
filesystems, 44bsd (ufs1) and ufs2.
I found no errors doing a Linux mkdir, copy large file, BSD fsck, Linux rm
large file, rmdir and BSD fsck in any of the 6 combinations.
FWIW, with xfstests I see the following:
* _require_metadata_journaling needs to be told not to bother with
our ufs
* generic/{409,410,411} lack $MOUNT_OPTIONS in several invocations
of mount -t $FSTYP; for ufs it's obviosuly a problem. Trivial bug in tests,
fixing it makes them pass.
* generic/258 (timestamp wraparound) fails; fs is left intact
Trivially fixed (cast to (signed) in ufs1_read_inode(), similar to what
other filesystems with 32bit timestamps are doing); ufs2 has no problem
at all)
* generic/426 (fhandle stuff) fails and buggers the filesystem
Everything else passes with no fs corruption that could be detected by
fsck.ufs.
Also trivially fixed - it's a self-inflicted wound. Just have zero nlink in
ufs{1,2}_read_inode() fail with -ESTALE instead of triggering ufs_error().
As for my immediate plans, I'll look into the two failing tests,
but any further active work on ufs will have to wait for the next
cycle. It had been a fun couple of weeks, but I have more than
enough other stuff to deal with. And I would still very much prefer
for somebody to adopt that puppy.
Another piece of fun spotted: the logics for switching between two allocation
policies when relocating a packed tail that can't be expanded in place had
been b0rken since typo in 2.4.14.7 - switch back from OPTTIME to OPTSPACE
had been screwed by this:
- usb1->fs_optim = SWAB32(UFS_OPTSPACE);
+ usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
And fragmentation levels for switching back and force really ought to be
calculated at mount time. Another (minor) issue is mentioned in this
commit message from Kirck McKusick back in 1995:
The threshold for switching from time-space and space-time is too small
when minfree is 5%...so make it stay at space in this case.
Not that minfree at 5% had been frequently seen - default has never been that
low (back in 4.2BSD it was 10%, these days it's 8%)
Resulting kernel passes xfstests clean and now I'm definitely done with UFS for
this cycle. Linus, in case you want to pull that sucker, pull request would
be as below:
The following changes since commit a8fad984833832d5ca11a9ed64ddc55646da30e3:
ufs_truncate_blocks(): fix the case when size is in the last direct block
(2017-06-15 03:57:46 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git ufs-fixes
for you to fetch changes up to 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1:
ufs: fix the logics for tail relocation (2017-06-17 17:22:42 -0400)
Al Viro (3):
fix signedness of timestamps on ufs1
ufs_iget(): fail with -ESTALE on deleted inode
ufs: fix the logics for tail relocation
fs/ufs/balloc.c | 22 ++
fs/ufs/inode.c | 27 +++
fs/ufs/super.c | 9 +
fs/ufs/ufs_fs.h | 2 ++
4 files changed, 28 insertions(+), 32 deletions(-)
I just tested these 3 patches along with the earlier 8 patches against
Linux 4.12-rc5 and they look fine. All 6 test cases look good.
The ufs code is much better now than it was before all these patches.
Re: [git pull] first batch of ufs fixes
On Thu, 15 Jun 2017, Al Viro wrote: On Wed, Jun 14, 2017 at 08:11:33AM +0100, Al Viro wrote: FWIW, it seems to work here. Said that, *BSD fsck_ffs is not worth much - play a bit with redundancy in UFS superblock (starting with fragment and block sizes, their ratio, logarithms, bitmasks, etc.) and you can screw at least 10.3 into the ground when mounting an image that passes their fsck. Sure, anyone who mounts untrusted images is a cretin who deserves everything they get, fsck or no fsck, but... no complaints from fsck is not a reliable indicator of image being in good condition and that's PITA for testing. Another pile of fun: "reserve ->s_minfree percents of total" logics had been broken. * using hardwired 5% is wrong - especially for ufs2, where it's not even the default * ufs_freespace() returns u64; testing for <= 0 is not doing the right thing * no capability checks before we need them, TYVM... * ufs2 needs 64bit uspi->s_dsize (and ->s_size, while we are at it). 64bit variants were even calculated - and never used. * while we are at it, doing "multiply the total data frags by s_minfree and divide by 100" every time we allocate a block is bloody dumb - that should be calculated once. We really need to get the sodding tail unpacking moved up from the place where it's buried - turns out that my doubts about that code managing to avoid deadlocks had been correct. Long-term we need to move that thing to iomap-based ->write_iter() and do unpacking there and in truncate(). For now I've slapped together something that is easier to backport - avoiding ->truncate_mutex when possible and not holding ->s_lock over ufs_change_blocknr(). Another bug in the same area: ufs_get_locked_page() doesn't guarantee that buffer_heads are attached (race with vmscan trying to evict the page in question can end with buffer_heads freed and page left alive and uptodate). Callers do expect buffer_heads to be there, so we either need to do create_empty_buffers() in those callers or in ufs_get_locked_page(); I went for the latter for now. Off-by-one in ufs_truncate_blocks(): the logics when deciding whether we need to do anything with direct blocks is broken when new size is within the last direct block. It's better to find the path to the last byte _not_ to be removed and use that instead of the path to the beginning of the first block to be freed. I've pushed fixes for those into vfs.git#ufs-fixes; they do need more testing before I send a pull request, though. The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5. They seem to work fine with the simple testing that I do. I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2 filesystems, 44bsd (ufs1) and ufs2. I found no errors doing a Linux mkdir, copy large file, BSD fsck, Linux rm large file, rmdir and BSD fsck in any of the 6 combinations. Doing a "df" on BSD and Linux now match on the counts including the "Available" counts. It might be worth testing with ufs filesystems using softdep and/or journaling. Should the Linux mount command reject such filesystems? Now that ufs write access is working more or less, we're dangerous.
Re: [git pull] first batch of ufs fixes
On Thu, 15 Jun 2017, Al Viro wrote: On Wed, Jun 14, 2017 at 08:11:33AM +0100, Al Viro wrote: FWIW, it seems to work here. Said that, *BSD fsck_ffs is not worth much - play a bit with redundancy in UFS superblock (starting with fragment and block sizes, their ratio, logarithms, bitmasks, etc.) and you can screw at least 10.3 into the ground when mounting an image that passes their fsck. Sure, anyone who mounts untrusted images is a cretin who deserves everything they get, fsck or no fsck, but... no complaints from fsck is not a reliable indicator of image being in good condition and that's PITA for testing. Another pile of fun: "reserve ->s_minfree percents of total" logics had been broken. * using hardwired 5% is wrong - especially for ufs2, where it's not even the default * ufs_freespace() returns u64; testing for <= 0 is not doing the right thing * no capability checks before we need them, TYVM... * ufs2 needs 64bit uspi->s_dsize (and ->s_size, while we are at it). 64bit variants were even calculated - and never used. * while we are at it, doing "multiply the total data frags by s_minfree and divide by 100" every time we allocate a block is bloody dumb - that should be calculated once. We really need to get the sodding tail unpacking moved up from the place where it's buried - turns out that my doubts about that code managing to avoid deadlocks had been correct. Long-term we need to move that thing to iomap-based ->write_iter() and do unpacking there and in truncate(). For now I've slapped together something that is easier to backport - avoiding ->truncate_mutex when possible and not holding ->s_lock over ufs_change_blocknr(). Another bug in the same area: ufs_get_locked_page() doesn't guarantee that buffer_heads are attached (race with vmscan trying to evict the page in question can end with buffer_heads freed and page left alive and uptodate). Callers do expect buffer_heads to be there, so we either need to do create_empty_buffers() in those callers or in ufs_get_locked_page(); I went for the latter for now. Off-by-one in ufs_truncate_blocks(): the logics when deciding whether we need to do anything with direct blocks is broken when new size is within the last direct block. It's better to find the path to the last byte _not_ to be removed and use that instead of the path to the beginning of the first block to be freed. I've pushed fixes for those into vfs.git#ufs-fixes; they do need more testing before I send a pull request, though. The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5. They seem to work fine with the simple testing that I do. I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2 filesystems, 44bsd (ufs1) and ufs2. I found no errors doing a Linux mkdir, copy large file, BSD fsck, Linux rm large file, rmdir and BSD fsck in any of the 6 combinations. Doing a "df" on BSD and Linux now match on the counts including the "Available" counts. It might be worth testing with ufs filesystems using softdep and/or journaling. Should the Linux mount command reject such filesystems? Now that ufs write access is working more or less, we're dangerous.
Re: [git pull] first batch of ufs fixes
d if=/dev/zero bs=1M count=3072 3) BSD: Check a ufs filesystem fsck -f 4) Linux: Remove the large file and the subdirectory rm rmdir 5) BSD; check a ufs filesystem fsck -f Tested-By: Richard Narron <comet.berke...@gmail.com>
Re: [git pull] first batch of ufs fixes
On Wed, 14 Jun 2017, Al Viro wrote:
...
AFAICS, a conservative approach would be
* reject UFS_42POSTBLFMT for 44bsd ones - it's almost certainly
*not* one.
* check if fs_maxbsize is equal to frag size; treat that as
"counts are read from new location and stored both to old and new".
44bsd fs_maxbsize != block size => not converted, just use old locations
for everything. UFS2 => use new locations for everything, don't bother
with old ones. IOW, something like this (WARNING: completely untested,
might screw your filesystem) might do.
NOTE: all I have is your image *after* it had counters buggered; I don't
know the exact sequence of operations that fucked it in your case. One
way to trigger it is to mount/umount on OpenBSD, then mount/modify/umount
on Linux, then mount/umount on OpenBSD, then fsck on OpenBSD. This patch
apparently fixes that, but your reproducer might be something different.
Signed-off-by: Al Viro
---
diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index d9aa2627c9df..eca838a8b43e 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -480,7 +480,7 @@ static void ufs_setup_cstotal(struct super_block *sb)
usb3 = ubh_get_usb_third(uspi);
if ((mtype == UFS_MOUNT_UFSTYPE_44BSD &&
-(usb1->fs_flags & UFS_FLAGS_UPDATED)) ||
+(usb2->fs_un.fs_u2.fs_maxbsize == usb1->fs_bsize)) ||
mtype == UFS_MOUNT_UFSTYPE_UFS2) {
/*we have statistic in different place, then usual*/
uspi->cs_total.cs_ndir = fs64_to_cpu(sb,
usb2->fs_un.fs_u2.cs_ndir);
@@ -596,9 +596,7 @@ static void ufs_put_cstotal(struct super_block *sb)
usb2 = ubh_get_usb_second(uspi);
usb3 = ubh_get_usb_third(uspi);
- if ((mtype == UFS_MOUNT_UFSTYPE_44BSD &&
-(usb1->fs_flags & UFS_FLAGS_UPDATED)) ||
- mtype == UFS_MOUNT_UFSTYPE_UFS2) {
+ if (mtype == UFS_MOUNT_UFSTYPE_UFS2) {
/*we have statistic in different place, then usual*/
usb2->fs_un.fs_u2.cs_ndir =
cpu_to_fs64(sb, uspi->cs_total.cs_ndir);
@@ -608,16 +606,26 @@ static void ufs_put_cstotal(struct super_block *sb)
cpu_to_fs64(sb, uspi->cs_total.cs_nifree);
usb3->fs_un1.fs_u2.cs_nffree =
cpu_to_fs64(sb, uspi->cs_total.cs_nffree);
- } else {
- usb1->fs_cstotal.cs_ndir =
- cpu_to_fs32(sb, uspi->cs_total.cs_ndir);
- usb1->fs_cstotal.cs_nbfree =
- cpu_to_fs32(sb, uspi->cs_total.cs_nbfree);
- usb1->fs_cstotal.cs_nifree =
- cpu_to_fs32(sb, uspi->cs_total.cs_nifree);
- usb1->fs_cstotal.cs_nffree =
- cpu_to_fs32(sb, uspi->cs_total.cs_nffree);
+ goto out;
}
+
+ if (mtype == UFS_MOUNT_UFSTYPE_44BSD &&
+(usb2->fs_un.fs_u2.fs_maxbsize == usb1->fs_bsize)) {
+ /* store stats in both old and new places */
+ usb2->fs_un.fs_u2.cs_ndir =
+ cpu_to_fs64(sb, uspi->cs_total.cs_ndir);
+ usb2->fs_un.fs_u2.cs_nbfree =
+ cpu_to_fs64(sb, uspi->cs_total.cs_nbfree);
+ usb3->fs_un1.fs_u2.cs_nifree =
+ cpu_to_fs64(sb, uspi->cs_total.cs_nifree);
+ usb3->fs_un1.fs_u2.cs_nffree =
+ cpu_to_fs64(sb, uspi->cs_total.cs_nffree);
+ }
+ usb1->fs_cstotal.cs_ndir = cpu_to_fs32(sb, uspi->cs_total.cs_ndir);
+ usb1->fs_cstotal.cs_nbfree = cpu_to_fs32(sb, uspi->cs_total.cs_nbfree);
+ usb1->fs_cstotal.cs_nifree = cpu_to_fs32(sb, uspi->cs_total.cs_nifree);
+ usb1->fs_cstotal.cs_nffree = cpu_to_fs32(sb, uspi->cs_total.cs_nffree);
+out:
ubh_mark_buffer_dirty(USPI_UBH(uspi));
ufs_print_super_stuff(sb, usb1, usb2, usb3);
UFSD("EXIT\n");
@@ -997,6 +1005,13 @@ static int ufs_fill_super(struct super_block *sb, void
*data, int silent)
flags |= UFS_ST_SUN;
}
+ if ((flags & UFS_ST_MASK) == UFS_ST_44BSD &&
+ uspi->s_postblformat == UFS_42POSTBLFMT) {
+ if (!silent)
+ pr_err("this is not a 44bsd filesystem");
+ goto failed;
+ }
+
/*
* Check ufs magic number
*/
Al this patch looks good to me (so far). I tested all 6 combinations of
ufs1 and ufs2 in FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1
For each combination, I do 5 steps:
1) BSD: Make a ufs filesystem
dd if=/dev/zero to the BSD subpartition
make (newfs) a ufs (1 or 2) filesystem on the BSD subpartiton
2) Linux: Create a subdirectory and make a large file
mkdir a
dd if=/dev/zero bs=1M count
Re: [git pull] first batch of ufs fixes
On Tue, 13 Jun 2017, Al Viro wrote: On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote: Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after Linux 4.12-rc5 copy of my >2GB file using "cp". But later today I get the error when I copy using your "dd" method... In any case I always get a ufs1 fsck error after the Linux rm and rmdir. Interesting... Could you put together an image (starting with zeroing the device before newfs, and ideally with dd from /dev/zero to create files) that would a) pass fsck on OpenBSD b) after rm on Linux fail the same then convert it to qcow2 and publish? Or just compress it - all free and data blocks would contain only zeroes, so any kind of compression (gzip, bzip2, whatever) would reduce the size to something more managable... I created a gzip and sent you an email with the link to a UFS1 OpenBSD filesytem image. I finished simple testing of UFS1 with FreeBSD and NetBSD and found no problems except for the differences between "available" blocks in df commands. And testing UFS2 was fine with all 3 systems, FreeBSD, OpenBSD and NetBSD.
Re: [git pull] first batch of ufs fixes
On Tue, 13 Jun 2017, Al Viro wrote: On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote: Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after Linux 4.12-rc5 copy of my >2GB file using "cp". But later today I get the error when I copy using your "dd" method... In any case I always get a ufs1 fsck error after the Linux rm and rmdir. Interesting... Could you put together an image (starting with zeroing the device before newfs, and ideally with dd from /dev/zero to create files) that would a) pass fsck on OpenBSD b) after rm on Linux fail the same then convert it to qcow2 and publish? Or just compress it - all free and data blocks would contain only zeroes, so any kind of compression (gzip, bzip2, whatever) would reduce the size to something more managable... I created a gzip and sent you an email with the link to a UFS1 OpenBSD filesytem image. I finished simple testing of UFS1 with FreeBSD and NetBSD and found no problems except for the differences between "available" blocks in df commands. And testing UFS2 was fine with all 3 systems, FreeBSD, OpenBSD and NetBSD.
Re: [git pull] first batch of ufs fixes
On Mon, 12 Jun 2017, Al Viro wrote: On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote: 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large > 2GB file and creating a directory, there are errors on OpenBSD with the fsck: Can't reproduce... # fsck -f /dev/rwd1c ** /dev/rwd1c ** File system is already clean ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 3 files, 1573258 used, 489445 free (13 frags, 61179 blocks, 0.0% fragmentation) # uname -mrsv OpenBSD 6.1 GENERIC#19 amd64 # file -s /dev/rwd1c /dev/rwd1c: Unix Fast File system [v1] (little-endian), last mounted on , last written at Mon Jun 12 06:03:57 2017, clean flag 1, number of blocks 2097152, number of data blocks 2062703, number of cylinder groups 21, block size 16384, fragment size 2048, minimum percentage of free blocks 5, rotational delay 0ms, disk rotational speed 60rps, TIME optimization That's after # mkdir /mnt/a; dd if=/dev/zero of=/mnt/a/foo bs=1M count=3072 on the Linux side, with root@kvm1:~# uname -msrv Linux 4.12.0-rc1+ #112 SMP Fri Jun 9 17:16:00 EDT 2017 x86_64 there. -o loop mount on Linux (image living on 9p), direct -hdb ../9p/ufs on OpenBSD side of things (both in KVM on the same host)... Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after Linux 4.12-rc5 copy of my >2GB file using "cp". But later today I get the error when I copy using your "dd" method... In any case I always get a ufs1 fsck error after the Linux rm and rmdir. Here is the error after rm of the files created by the "dd" method: #/usr/bin/uname -mrsv OpenBSD 6.1 GENERIC.MP#6 amd64 #/sbin/fsck -n -f /dev/sd0e ** /dev/rsd0e (NO WRITE) ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no 1 files, 1 used, 6682349 free (13 frags, 835292 blocks, 0.0% fragmentation) #/sbin/fsck -f /dev/sd0e ** /dev/rsd0e ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [Fyn?] 1 files, 1 used, 8255606 free (14 frags, 1031949 blocks, 0.0% fragmentation) * FILE SYSTEM WAS MODIFIED * #/sbin/mount /dev/sd0e #/bin/df /diske Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd0e 33022428 4 31371304 0%/diske #/sbin/mount /dev/sd0e #/bin/df /diske Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd0e 33022428 4 31371304 0%/diske OpenBSD 6.1 is not very stable for me. I will test FreeBSD and NetBSD ufs1 to see if they have a problem...
Re: [git pull] first batch of ufs fixes
On Mon, 12 Jun 2017, Al Viro wrote: On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote: 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large > 2GB file and creating a directory, there are errors on OpenBSD with the fsck: Can't reproduce... # fsck -f /dev/rwd1c ** /dev/rwd1c ** File system is already clean ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 3 files, 1573258 used, 489445 free (13 frags, 61179 blocks, 0.0% fragmentation) # uname -mrsv OpenBSD 6.1 GENERIC#19 amd64 # file -s /dev/rwd1c /dev/rwd1c: Unix Fast File system [v1] (little-endian), last mounted on , last written at Mon Jun 12 06:03:57 2017, clean flag 1, number of blocks 2097152, number of data blocks 2062703, number of cylinder groups 21, block size 16384, fragment size 2048, minimum percentage of free blocks 5, rotational delay 0ms, disk rotational speed 60rps, TIME optimization That's after # mkdir /mnt/a; dd if=/dev/zero of=/mnt/a/foo bs=1M count=3072 on the Linux side, with root@kvm1:~# uname -msrv Linux 4.12.0-rc1+ #112 SMP Fri Jun 9 17:16:00 EDT 2017 x86_64 there. -o loop mount on Linux (image living on 9p), direct -hdb ../9p/ufs on OpenBSD side of things (both in KVM on the same host)... Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after Linux 4.12-rc5 copy of my >2GB file using "cp". But later today I get the error when I copy using your "dd" method... In any case I always get a ufs1 fsck error after the Linux rm and rmdir. Here is the error after rm of the files created by the "dd" method: #/usr/bin/uname -mrsv OpenBSD 6.1 GENERIC.MP#6 amd64 #/sbin/fsck -n -f /dev/sd0e ** /dev/rsd0e (NO WRITE) ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no 1 files, 1 used, 6682349 free (13 frags, 835292 blocks, 0.0% fragmentation) #/sbin/fsck -f /dev/sd0e ** /dev/rsd0e ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [Fyn?] 1 files, 1 used, 8255606 free (14 frags, 1031949 blocks, 0.0% fragmentation) * FILE SYSTEM WAS MODIFIED * #/sbin/mount /dev/sd0e #/bin/df /diske Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd0e 33022428 4 31371304 0%/diske #/sbin/mount /dev/sd0e #/bin/df /diske Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd0e 33022428 4 31371304 0%/diske OpenBSD 6.1 is not very stable for me. I will test FreeBSD and NetBSD ufs1 to see if they have a problem...
Re: [git pull] first batch of ufs fixes
The ufs fixes are looking good, much better than what we started with. After applying the 8 ufs patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git /commit/?id=5faab9e0f03c4eef97886b45436015e107f79f5f Copying files to FreeBSD 11.0 (ufs2) and NetBSD 7.1 (ufs2) looks pretty good. I can copy a large >2GB file, create a directory and then run and fsck without errors with a FreeBSD disk and a NetBSD disk. But... 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large > 2GB file and creating a directory, there are errors on OpenBSD with the fsck: OpenBSD (44bsd): #fsck sd0e ** /dev/rsd0e ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [Fyn?] 3 files, 1272410 used, 6983197 free (13 frags, 872898 blocks, 0.0% fragmentation) * FILE SYSTEM WAS MODIFIED * And also after removing the files on Linux, there were errors in the fsck on OpenBSD: #fsck sd0e ** /dev/rsd0e ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [Fyn?] 1 files, 1 used, 8255606 free (14 frags, 1031949 blocks, 0.0% fragmentation) * FILE SYSTEM WAS MODIFIED * 2) The available block counts on a newly created FreeBSD 11.0 ufs2 filesystem (13079640) differ from Linux 4.12-rc4 (13079656): Freebsd (ufs2): #df /diske Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ada0s3e 142170088 13079640 0%/diske Linux: #df /fbsd23 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda23 14217008 8 13079656 1% /fbsd23 3) The available block counts on a newly created NetBSD 7.1 ufs2 filesystem (9518316) differ from Linux 4.12-rc4 (9518314): NetBSD (ufs2): #df /nbsdf Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda22 10019278 2 9518316 1% /nbsdf Linux: #df /diskf Filesystem1K-blocks Used Avail %Cap Mounted on /dev/wd0f 10019278 29518314 0% /diskf
Re: [git pull] first batch of ufs fixes
The ufs fixes are looking good, much better than what we started with. After applying the 8 ufs patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git /commit/?id=5faab9e0f03c4eef97886b45436015e107f79f5f Copying files to FreeBSD 11.0 (ufs2) and NetBSD 7.1 (ufs2) looks pretty good. I can copy a large >2GB file, create a directory and then run and fsck without errors with a FreeBSD disk and a NetBSD disk. But... 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large > 2GB file and creating a directory, there are errors on OpenBSD with the fsck: OpenBSD (44bsd): #fsck sd0e ** /dev/rsd0e ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [Fyn?] 3 files, 1272410 used, 6983197 free (13 frags, 872898 blocks, 0.0% fragmentation) * FILE SYSTEM WAS MODIFIED * And also after removing the files on Linux, there were errors in the fsck on OpenBSD: #fsck sd0e ** /dev/rsd0e ** File system is already clean ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [Fyn?] 1 files, 1 used, 8255606 free (14 frags, 1031949 blocks, 0.0% fragmentation) * FILE SYSTEM WAS MODIFIED * 2) The available block counts on a newly created FreeBSD 11.0 ufs2 filesystem (13079640) differ from Linux 4.12-rc4 (13079656): Freebsd (ufs2): #df /diske Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ada0s3e 142170088 13079640 0%/diske Linux: #df /fbsd23 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda23 14217008 8 13079656 1% /fbsd23 3) The available block counts on a newly created NetBSD 7.1 ufs2 filesystem (9518316) differ from Linux 4.12-rc4 (9518314): NetBSD (ufs2): #df /nbsdf Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda22 10019278 2 9518316 1% /nbsdf Linux: #df /diskf Filesystem1K-blocks Used Avail %Cap Mounted on /dev/wd0f 10019278 29518314 0% /diskf
Re: [git pull] first batch of ufs fixes
On Fri, 9 Jun 2017, Al Viro wrote: That's just the obvious backport fodder; I'm pretty sure that there will be more - definitely so wrt performance and quite possibly correctness as well. These fixes improve the ufs code and they are a good start. Here are a couple of bugs that still remain: 1) Just after creating a new filesystem on FreeBSD 11.0, the FreeBSD df is different from the Linux 4.12.0-rc4 with the ufs fixes. The available count on Linux is is 16k higher than on FreeBSD: FreeBSD 11.0: #df /diske Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ada0s3e 142170088 13079640 0%/diske Linux 4.12-0-rc4 with ufs fixes: #df /fbsd23 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda23 14217008 8 13079656 1% /fbsd23 2) After creating a new filesystem on FreeBSD, then on Linux copying a larger than 2GB file and creating a directory, the fsck back on FreeBSD looks ok. But after going back to Linux and removing the large file and removing the directory, the fsck on FreeBSD looks not so good: Linux: #cp /fbsd/tmp/usr-local.tar /fbsd23 #mkdir /fbsd23/a FreeBSD: #fsck -f /dev/ada0s3e ** /dev/ada0s3e ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 4 files, 636219 used, 2918033 free (25 frags, 364751 blocks, 0.0% fragmentation) * FILE SYSTEM IS CLEAN * Linux: #cd /fbsd23 rmusr-local.tar rmdir a FreeBSD: #fsck -n -f /dev/ada0s3e ** /dev/ada0s3e (NO WRITE) ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity UNREF DIR I=5 OWNER=root MODE=40755 SIZE=512 MTIME=Jun 10 01:51 2017 RECONNECT? no ** Phase 4 - Check Reference Counts LINK COUNT DIR I=2 OWNER=root MODE=40755 SIZE=512 MTIME=Jun 10 02:04 2017 COUNT 3 SHOULD BE 4 ADJUST? no UNREF FILE I=4 OWNER=root MODE=100644 SIZE=2605231616 MTIME=Jun 10 01:47 2017 RECONNECT? no CLEAR? no LINK COUNT DIR I=5 OWNER=root MODE=40755 SIZE=512 MTIME=Jun 10 01:51 2017 COUNT 2 SHOULD BE 1 ADJUST? no ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no SUMMARY INFORMATION BAD SALVAGE? no BLK(S) MISSING IN BIT MAPS SALVAGE? no 4 files, 636219 used, 3554250 free (26 frags, 444278 blocks, 0.0% fragmentation)
Re: [git pull] first batch of ufs fixes
On Fri, 9 Jun 2017, Al Viro wrote: That's just the obvious backport fodder; I'm pretty sure that there will be more - definitely so wrt performance and quite possibly correctness as well. These fixes improve the ufs code and they are a good start. Here are a couple of bugs that still remain: 1) Just after creating a new filesystem on FreeBSD 11.0, the FreeBSD df is different from the Linux 4.12.0-rc4 with the ufs fixes. The available count on Linux is is 16k higher than on FreeBSD: FreeBSD 11.0: #df /diske Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ada0s3e 142170088 13079640 0%/diske Linux 4.12-0-rc4 with ufs fixes: #df /fbsd23 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda23 14217008 8 13079656 1% /fbsd23 2) After creating a new filesystem on FreeBSD, then on Linux copying a larger than 2GB file and creating a directory, the fsck back on FreeBSD looks ok. But after going back to Linux and removing the large file and removing the directory, the fsck on FreeBSD looks not so good: Linux: #cp /fbsd/tmp/usr-local.tar /fbsd23 #mkdir /fbsd23/a FreeBSD: #fsck -f /dev/ada0s3e ** /dev/ada0s3e ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 4 files, 636219 used, 2918033 free (25 frags, 364751 blocks, 0.0% fragmentation) * FILE SYSTEM IS CLEAN * Linux: #cd /fbsd23 rmusr-local.tar rmdir a FreeBSD: #fsck -n -f /dev/ada0s3e ** /dev/ada0s3e (NO WRITE) ** Last Mounted on /diske ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity UNREF DIR I=5 OWNER=root MODE=40755 SIZE=512 MTIME=Jun 10 01:51 2017 RECONNECT? no ** Phase 4 - Check Reference Counts LINK COUNT DIR I=2 OWNER=root MODE=40755 SIZE=512 MTIME=Jun 10 02:04 2017 COUNT 3 SHOULD BE 4 ADJUST? no UNREF FILE I=4 OWNER=root MODE=100644 SIZE=2605231616 MTIME=Jun 10 01:47 2017 RECONNECT? no CLEAR? no LINK COUNT DIR I=5 OWNER=root MODE=40755 SIZE=512 MTIME=Jun 10 01:51 2017 COUNT 2 SHOULD BE 1 ADJUST? no ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no SUMMARY INFORMATION BAD SALVAGE? no BLK(S) MISSING IN BIT MAPS SALVAGE? no 4 files, 636219 used, 3554250 free (26 frags, 444278 blocks, 0.0% fragmentation)
Re: [PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized
On Fri, 26 May 2017, Joe Perches wrote: (please keep replies on the list) On Fri, 2017-05-26 at 18:33 -0700, Richard Narron wrote: On Fri, 26 May 2017, Joe Perches wrote: On Fri, 2017-05-26 at 16:30 -0700, Richard Narron wrote: On Fri, 26 May 2017, Joe Perches wrote: On Fri, 2017-05-26 at 03:48 -0700, Richard Narron wrote: The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions. But for FreeBSD the subpartitions are always "bad". Kernel: [] block/partitions/msdos.c | 2 ++ [] @@ -300,6 +300,8 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); + if (memcmp(flavour, "bsd\0", 4) == 0) Weird code. Why not: if (strcmp(flavor, "bsd") == 0) I instinctively trust the memcmp function as it seems more like assembly language to me and more straight forward and more reliable than strcmp. That really doesn't matter. Your code stores "bsd\0\0" and not just "bsd\0" Thanks for looking at this code. I do appreciate it. How about saving a byte and doing this instead? if (memcmp(flavour, "bsd", 4) == 0) I do appreciate your input as coding style is important, but so too is reliability. I don't trust the string functions and probably never will. It is not surprising to me that things like SQL injection and any number of other C string exploits are very common. IBM gave up on the idea of marking memory to keep track of data length with the 1401 machines in the 1950's. But Digital Equipment kept the idea alive of using null characters for a long time. Sadly the C programming language copied this bad idea for strings. Let's not argue the language. Please use what's normal for the language as that is readers of the code typically expect. Under the /block/partitions directory the c programs have about 13 uses of memcmp() and 6 uses of strcmp().
Re: [PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized
On Fri, 26 May 2017, Joe Perches wrote: (please keep replies on the list) On Fri, 2017-05-26 at 18:33 -0700, Richard Narron wrote: On Fri, 26 May 2017, Joe Perches wrote: On Fri, 2017-05-26 at 16:30 -0700, Richard Narron wrote: On Fri, 26 May 2017, Joe Perches wrote: On Fri, 2017-05-26 at 03:48 -0700, Richard Narron wrote: The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions. But for FreeBSD the subpartitions are always "bad". Kernel: [] block/partitions/msdos.c | 2 ++ [] @@ -300,6 +300,8 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); + if (memcmp(flavour, "bsd\0", 4) == 0) Weird code. Why not: if (strcmp(flavor, "bsd") == 0) I instinctively trust the memcmp function as it seems more like assembly language to me and more straight forward and more reliable than strcmp. That really doesn't matter. Your code stores "bsd\0\0" and not just "bsd\0" Thanks for looking at this code. I do appreciate it. How about saving a byte and doing this instead? if (memcmp(flavour, "bsd", 4) == 0) I do appreciate your input as coding style is important, but so too is reliability. I don't trust the string functions and probably never will. It is not surprising to me that things like SQL injection and any number of other C string exploits are very common. IBM gave up on the idea of marking memory to keep track of data length with the 1401 machines in the 1950's. But Digital Equipment kept the idea alive of using null characters for a long time. Sadly the C programming language copied this bad idea for strings. Let's not argue the language. Please use what's normal for the language as that is readers of the code typically expect. Under the /block/partitions directory the c programs have about 13 uses of memcmp() and 6 uses of strcmp().
Re: [PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized
On Fri, 26 May 2017, Joe Perches wrote: On Fri, 2017-05-26 at 03:48 -0700, Richard Narron wrote: The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions. But for FreeBSD the subpartitions are always "bad". Kernel: [] block/partitions/msdos.c | 2 ++ [] @@ -300,6 +300,8 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); + if (memcmp(flavour, "bsd\0", 4) == 0) Weird code. Why not: if (strcmp(flavor, "bsd") == 0) I instinctively trust the memcmp function as it seems more like assembly language to me and more straight forward and more reliable than strcmp. I'm new to this forum and did not know who you were so I looked up your name in old threads and oddly enough found this thread about a strcmp bug: http://marc.info/?l=linux-kernel=125848558316468=2 http://marc.info/?l=linux-kernel=125847802903422=2
Re: [PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized
On Fri, 26 May 2017, Joe Perches wrote: On Fri, 2017-05-26 at 03:48 -0700, Richard Narron wrote: The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions. But for FreeBSD the subpartitions are always "bad". Kernel: [] block/partitions/msdos.c | 2 ++ [] @@ -300,6 +300,8 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); + if (memcmp(flavour, "bsd\0", 4) == 0) Weird code. Why not: if (strcmp(flavor, "bsd") == 0) I instinctively trust the memcmp function as it seems more like assembly language to me and more straight forward and more reliable than strcmp. I'm new to this forum and did not know who you were so I looked up your name in old threads and oddly enough found this thread about a strcmp bug: http://marc.info/?l=linux-kernel=125848558316468=2 http://marc.info/?l=linux-kernel=125847802903422=2
[PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized
The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions. But for FreeBSD the subpartitions are always "bad". Kernel: Cc: Andries Brouwer <a...@cwi.nl> Cc: linux-bl...@vger.kernel.org Reviewed-by: Christoph Hellwig <h...@lst.de> Signed-off-by: Richard Narron <comet.berke...@gmail.com> --- Changelog v2->v3: - Add Cc: Changelog v1->v2: - Improve style, use += --- block/partitions/msdos.c | 2 ++ 1 file changed, 2 insertions(+) --- a/block/partitions/msdos.c 2015-12-27 18:17:37.0 -0800 +++ b/block/partitions/msdos.c 2015-12-29 10:44:25.813773357 -0800 @@ -300,6 +300,8 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); + if (memcmp(flavour, "bsd\0", 4) == 0) + bsd_start += offset; if (offset == bsd_start && size == bsd_size) /* full parent partition, we have it already */ continue;
[PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized
The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions. But for FreeBSD the subpartitions are always "bad". Kernel: Cc: Andries Brouwer Cc: linux-bl...@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Richard Narron --- Changelog v2->v3: - Add Cc: Changelog v1->v2: - Improve style, use += --- block/partitions/msdos.c | 2 ++ 1 file changed, 2 insertions(+) --- a/block/partitions/msdos.c 2015-12-27 18:17:37.0 -0800 +++ b/block/partitions/msdos.c 2015-12-29 10:44:25.813773357 -0800 @@ -300,6 +300,8 @@ static void parse_bsd(struct parsed_part continue; bsd_start = le32_to_cpu(p->p_offset); bsd_size = le32_to_cpu(p->p_size); + if (memcmp(flavour, "bsd\0", 4) == 0) + bsd_start += offset; if (offset == bsd_start && size == bsd_size) /* full parent partition, we have it already */ continue;
