How should I use ext2 in OpenBSD?

[e1-531g]

Hello,
OpenBSD-current amd64 dated 18-12-2015.
I have fully encrypted OpenBSD using softraid.
I was using fat filesystem to exchange data beetwen
Windows and OpenBSD (unencrypted partition).
I want to use ext2 instead. I have created ext2
filesystem using command:

newfs_ext2fs -O1 -m1 /dev/rsd0f

I can mount using command line:

# mount -t ext2fs /dev/sd0f /mnt/partycjaExt/ 
# touch /mnt/partycjaExt/hello1               
# umount /mnt/partycjaExt/                    
# mount -t ext2fs /dev/sd0f /mnt/partycjaExt/ 
# ls /mnt/partycjaExt/                        
hello1     lost+found

but when I added to /etc/fstab :

# cat /etc/fstab.back       
e2687744d2198a2e.a / ffs rw 1 1
e2687744d2198a2e.h /home ffs rw,nodev,nosuid 1 2
e2687744d2198a2e.e /usr ffs rw,nodev 1 2
e2687744d2198a2e.d /var ffs rw,nodev,nosuid 1 2
#3a9569f176005878.f /mnt/partycjaFat msdos rw,nodev,nosuid 1 2
3a9569f176005878.f /mnt/partycjaExt ext2fs ro 1 2

OpenBSD fails to boot completly to normal login.
Instead it offers me to drop to shell in single user mode and
tells me something about inconsistency.

# disklabel sd0                                                                
# /dev/rsd0c:
type: SCSI
disk: Ubuntu 14.04.2 L
label: TS i386         
duid: 3a9569f176005878
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60801
total sectors: 976773168
boundstart: 829967361
boundend: 976773168
drivedata: 0 

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  a:        146805807        829967361    RAID                   
  c:        976773168                0  unused                   
  f:         83886080        399179776  ext2fs                   
  i:           716800             2048    NTFS                   
  j:        398458880           718848    NTFS                   
  k:         83886080        399179776  ext2fs                   
  l:        346899457        483067904    NTFS

# disklabel sd1 
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: SR CRYPTO
duid: e2687744d2198a2e
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 9138
total sectors: 146805279
boundstart: 64
boundend: 146801970
drivedata: 0 

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  a:          8388608               64  4.2BSD   2048 16384    1 # /
  c:        146805279                0  unused                   
  d:          2097152          8388672  4.2BSD   2048 16384    1 # /var
  e:         31457280         10485824  4.2BSD   2048 16384    1 # /usr
  h:        104858848         41943104  4.2BSD   2048 16384    1 # /home

And error from normal OpenBSD boot.
On newly created filesystem there are no
errors, but if I add two example files using touch
and one with nano containing few bytes of date
then umount filesystem manually, fsck gives mi this error:

# fsck_ext2fs /dev/rsd0f                       
** /dev/rsd0f
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
/dev/rsd0f: BLOCK SIZE DETERMINED TO BE ZERO

[jggimi]

I am able to reproduce this error, but do not understand it. /etc/rc issues a mount(8) command with -a -t nonfs,vnd which works properly when issued manually in either single or multiuser mode, but not when the script is run by init(8).

[e1-531g]

I could also reproduce this problem on one day newer
amd64 snapshot dated 19-12-2015.

 sysctl kern.version                                                          
kern.version=OpenBSD 5.8-current (GENERIC.MP) #1757: Sat Dec 19 08:17:18 MST 2015
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

# newfs_ext2fs -O1 -m1 /dev/rsd0f
/dev/rsd0f: 40960.0MB (83886080 sectors) block size 4096, fragment size 4096
        using 320 block groups of 128.0MB, 32768 blks, 16384 inodes.
super-block backups (for fsck_ext2fs -b #) at:
   32768,    98304,   163840,   229376,   294912,   819200,   884736,  1605632,
 2654208,  4096000,  7962624,
# mount -t ext2fs /dev/rsd0                                                    
rsd0a  rsd0c  rsd0e  rsd0g  rsd0i  rsd0k  rsd0m  rsd0o  
rsd0b  rsd0d  rsd0f  rsd0h  rsd0j  rsd0l  rsd0n  rsd0p  
 -t ext2fs /dev/rsd0f /mnt/partycjaExt/                                       <
mount_ext2fs: /dev/rsd0f on /mnt/partycjaExt: Block device required
# mount -t ext2fs /dev/sd0f /mnt/partycjaExt/  
# touch /mnt/partycjaExt/hello1                                                
# touch /mnt/partycjaExt/hello2 
# nano -w /mnt/partycjaExt/nano1                                               
# sync
# umount /mnt/partycjaExt/                                                     
# fsck_ext2fs /dev/rsd0                                                        
rsd0a  rsd0c  rsd0e  rsd0g  rsd0i  rsd0k  rsd0m  rsd0o  
rsd0b  rsd0d  rsd0f  rsd0h  rsd0j  rsd0l  rsd0n  rsd0p  
# fsck_ext2fs /dev/rsd0f                                                       
** /dev/rsd0f
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
/dev/rsd0f: BLOCK SIZE DETERMINED TO BE ZERO

[jggimi]

You may wish to report the problem to the Project. Meanwhile, you can circumvent the problem by removing the filesystem from /etc/fstab, and mounting via a mount command in /etc/rc.local.

[e1-531g]

Thanks jggimi.
I will more free time around Wednesday, so I am going to wait day or to, test again with newer snapshot and then if it still fails report it.

[jggimi]

I've done a little more experimenting, and uncovered the root cause: do_fsck in /etc/rc.

[e1-531g]

I have reported problem to the Project today 24 December 2015 to bugs mailing list 12:56 and I received copy of my email 12:59.

[J65nko]

Your /etc/fstab entry instructs the system to do the fsck.

From fstab(5):

A line has the following format:

           fs_spec fs_file fs_vfstype fs_mntops fs_freq fs_passno

[snip]

The fifth field, fs_freq, is used by the -W and -w options of dump(8) to
recommend which filesystems should be backed up.  The value specifies the
number of days after which a dump is regarded as being old; if it is not
present, a value of zero is returned and dump(8) will assume that the
filesystem does not need to be dumped.

The sixth field, fs_passno, is used by the fsck(8) program to determine
the order in which filesystem checks are done at reboot time.  The root
filesystem should be specified with a fs_passno of 1, and other
filesystems should have a fs_passno of 2.  Filesystems within a drive
will be checked sequentially, but filesystems on different drives will be
checked at the same time to utilize parallelism available in the
hardware.  If the sixth field is not present or is zero, a value of zero
is returned and fsck(8) will assume that the filesystem does not need to
be checked.

So instead from your current /etc/fstab entry:

3a9569f176005878.f /mnt/partycjaExt ext2fs ro 1 2

you simply omit the last 2 fields:

3a9569f176005878.f /mnt/partycjaExt ext2fs ro

That should tell fsck(8) that this file system should not be checked.

[jggimi]

Either circumvention works, and yours is better than mine. But there is a problem with fsck_ext2fs(8), which is the root cause.

[hanzer]

Originally Posted by jggimi

[...] But there is a problem with fsck_ext2fs(8), which is the root cause.

Any news about this? I have a portable 1TB USB drive that I am about to reformat to a filesystem more stable [than ntfs] for OpenBSD and Linux. To just say that ntfs is unstable doesn't really stress how unstable [it is] - copying files (300GB) from a # mount_ntfs /dev/sd1i /mnt style mount kernel panic'ed an OpenBSD machine this morning and zombied an Ubuntu machine last night.

Is ext2 the way to go for a new file-system on this portable 1TB USB drive [that will backup/restore and transport files between Linux and OpenBSD machines]?

[e1-531g]

I don't know. I now use FAT filesystem aka msdos for interoperability.
It has however some limitations like maximum size of file 4GB.
I also use tar to make sure that characters from my language (Polish language) are not devastated during copying to Windows's FAT filesystem.
Tar however also have some limitations like maximum file name length.

[jggimi]

Originally Posted by hanzer

Any news about this?

Let's look in the source tree together.

$ which fsck_ext2fs
/sbin/fsck_ext2fs

The source repository (src) code is in /usr/src/sbin/fsck_ext2fs, which we can look at via the CVS Web Portal. If we click through to that source directory, and sort by age, we discover there were two updates in the middle of March - to main.c and utilities.c. Each had a single commit, which doesn't say "fixed this weird problem." Instead, the patches, done at the same time in a single commit, have a log note which says:

More "(<blah> *)0" -> NULL, avoiding any stdarg functions.

Feedback millert@ kettenis@

And we can see that the commit was from krw@. You now know which developers were involved. Let's look at the specific patches, and see if we can see what was changed.

===================================================================
RCS file: /cvs/src/sbin/fsck_ext2fs/main.c,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- src/sbin/fsck_ext2fs/main.c    2015/11/25 00:29:15    1.26
+++ src/sbin/fsck_ext2fs/main.c    2016/03/16 15:41:10    1.27
@@ -1,4 +1,4 @@
-/*    $OpenBSD: main.c,v 1.26 2015/11/25 00:29:15 deraadt Exp $    */
+/*    $OpenBSD: main.c,v 1.27 2016/03/16 15:41:10 krw Exp $    */
 /*    $NetBSD: main.c,v 1.1 1997/06/11 11:21:50 bouyer Exp $    */
 
 /*
@@ -248,9 +248,9 @@
             printf("\n");
         }
     }
-    zlnhead = (struct zlncnt *)0;
-    duplist = (struct dups *)0;
-    muldup = (struct dups *)0;
+    zlnhead = NULL;
+    duplist = NULL;
+    muldup = NULL;
     inocleanup();
     if (fsmodified) {
         time_t t;

===================================================================
RCS file: /cvs/src/sbin/fsck_ext2fs/utilities.c,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- src/sbin/fsck_ext2fs/utilities.c    2015/09/05 20:07:11    1.26
+++ src/sbin/fsck_ext2fs/utilities.c    2016/03/16 15:41:10    1.27
@@ -1,4 +1,4 @@
-/*    $OpenBSD: utilities.c,v 1.26 2015/09/05 20:07:11 guenther Exp $    */
+/*    $OpenBSD: utilities.c,v 1.27 2016/03/16 15:41:10 krw Exp $    */
 /*    $NetBSD: utilities.c,v 1.6 2001/02/04 21:19:34 christos Exp $    */
 
 /*
@@ -121,7 +121,7 @@
     char *bufp;
 
     diskreads = totalreads = 0;
-    pbp = pdirbp = (struct bufarea *)0;
+    pbp = pdirbp = NULL;
     bufhead.b_next = bufhead.b_prev = &bufhead;
     bufcnt = MAXBUFSPACE / sblock.e2fs_bsize;
     if (bufcnt < MINBUFS)
@@ -256,7 +256,7 @@
     }
     if (bufhead.b_size != cnt)
         errexit("Panic: lost %d buffers\n", bufhead.b_size - cnt);
-    pbp = pdirbp = (struct bufarea *)0;
+    pbp = pdirbp = NULL;
     if (markclean && (sblock.e2fs.e2fs_state & E2FS_ISCLEAN) == 0) {
         /*
          * Mark the file system as clean, and sync the superblock.

I know, from looking carefully at this commit, that I am completely clueless about what it is intended to do.

So I searched the tech@ archives, and did not see a discussion of it there. There was a post from a user with a proposed patch, but it appeared unrelated to this commit or to the problem. I also checked the misc@ archives -- nothing there either.

If I were curious, I would ensure I was running a snapshot newer than March 16, and test this again. I'll leave that to you.

[jggimi]

I'll just add to my prior discussion about the web portal to the repositories. While you can get the same information if you have the source in CVS working directory format, sometimes the web portal's information can be more clearly presented. In particular, determining the patches that are in -release, or a prior -release, or in -current, can be seen at a glance. The output of a cvs(1) log command is much more cryptic. The data is there, but not as clearly presented.

In addition to presenting unified diffs, such as the ones I copied/pasted into the post above, the portal can also show you changes in multiple colors, if you prefer viewing them that way. The cvs(1) command cannot present color diffs.

Using cvs(1) to look at this same sort of information requires a working directory acquired from an AnonCVS repository mirror, as source tarballs from Project CDs do not include CVS metadata.
See FAQ 5 and the AnonCVS link at the Project website for more information on obtaining source trees that can be managed (and examined) with cvs(1).

[IdOp]

The changes are specifying a NULL pointer in a different way. I would guess this might be something to keep a compiler happy, but not fix any real issues with filesystem support?

[jggimi]

Thanks. I was confused by the structure pointer syntax, and had no clear understanding that this was a null pointer. I can now understand why it was changed -- because it confused me. I agree, this change should have no operational impact.

[IdOp]

Well, the commit also says "avoiding stdarg functions". I have no knowledge about what that means. But perhaps it implies some kind of simplification beyond the visual? But agreed, very unlikely to be of operational impact.

[hanzer]

Originally Posted by e1-531g

I don't know. I now use FAT filesystem aka msdos for interoperability.
It has however some limitations like maximum size of file 4GB.
I also use tar to make sure that characters from my language (Polish language) are not devastated during copying to Windows's FAT filesystem.
Tar however also have some limitations like maximum file name length.

In my case, compatibility with MS-Windows isn't a requirement. My environment is entirely OpenBSD and Linux, with occasional [and disappointing] dabbling with FreeBSD. So the limitations of FAT32 are significant influences in the file-system selection decision tree.

Wikipedia says this about UFS:

Linux includes a UFS implementation for binary compatibility at the read level with other Unixes, but since there is no standard implementation for the vendor extensions to UFS, Linux does not have full support for writing to UFS.

So UFS doesn't meet my requirements: both, Linux and OpenBSD systems should have read and write capabilities for the portable 1TB USB hard-drive.

And it says this about EXT2:

The canonical implementation of ext2 is the "ext2fs" filesystem driver in the Linux kernel. Other implementations (of varying quality and completeness) exist in GNU Hurd, MINIX 3, some BSD kernels, in MiNT, and as third-party Microsoft Windows and OS X drivers.

I suppose what's left to do is test the "quality and completeness" of the ext2fs file-system driver and tools in OpenBSD and it's interoperability with the Linux implementation.

Here it goes:
$ doas pkg_add -i e2fsprogs

Then use fdisk to change the Master Boot Record partition id to 85 Linux ext.
$ doas fdisk -e sd1

After some interactive dialog and commands to make the changes, check with:

$ doas fdisk sd1

Disk: sd1       geometry: 121601/255/63 [1953525164 Sectors]
Offset: 0       Signature: 0xAA55
            Starting         Ending         LBA Info:
 #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
*0: 85      0  32  33 - 121601  44  27 [        2048:  1953520816 ] Linux ext.  
 1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused      
 2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused      
 3: 00      0   0   0 -      0   0   0 [           0:           0 ] unused

Use disklabel to create the filesystem partition:

$ doas disklabel -E sd1

OpenBSD area: 0-1953525164; size: 1953525164; free: 0
#                size           offset  fstype [fsize bsize  cpg]
  a:       1953525164                0  ext2fs                   
  c:       1953525164                0  unused

Then make the file-system with newfs_ext2fs:
$ doas newfs_ext2fs -O1 -m1 /dev/rsd1a

Once that completes, I will move some data around, check for derangement or distortion of filenames, permissions, timestamps, etc. and report back.

[hanzer]

Wow, that didn't work nearly as well as I had hoped. The method in the previous post allowed OpenBSD to read and write the ext2 USB disk but Linux couldn't mount it. So I used GParted on Ubuntu Linux to create a new partition table and ext2 filesystem. Now Linux can read and write the disk but OpenBSD says:

$ mount_ext2fs -o rw,nosuid,nodev /dev/sd1a mnt
$ df -h

/dev/sd1a      917G   71.7M    908G     0%    /home/hanzer/mnt

$ ls mnt

ls: mnt: Bad file descriptor

Surely I've done something wrong. Does anyone see it?

BTW - I followed some of HOWTO: mounting an USB device as normal non-root user in OpenBSD

[e1-531g]

FAT is also available in Linux. Actually after migration of the PC from BIOS to UEFI FAT is even more common, because bootloaders on hard drive are stored on designated by UEFI partition containing FAT filesystem.

[jggimi]

Originally Posted by hanzer

Does anyone see it?

Yes. "a" is not valid for a foreign filesystem that is is imported into a virtual disklabel via MBR. Try # disklabel sd1 and you should see the foreign filesystem as disklabel partition "i".