NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/54470: Adapt FFS to work with HP-UX UFS1 variant



The following reply was made to PR kern/54470; it has been noted by GNATS.

From: Konrad Schroder <perseant%hhhh.org@localhost>
To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, perseant%netbsd.org@localhost
Cc: 
Subject: Re: kern/54470: Adapt FFS to work with HP-UX UFS1 variant
Date: Sat, 17 Aug 2019 17:30:46 -0700

 Do we have a way to construct a file system that works with NetBSD, 
 which has a physical sector size other than DEV_BSIZE?  If so, I can 
 test against it.
 
 Note too that the macros in question exist only within the scope of the 
 fsck_ffs utility.  The other userland programs that I adapted didn't 
 need them, and the kernel uses macros that depend on struct ump and 
 could easily be special-cased for HP-UX or other old file systems if 
 need be.  Come to think of it, in fsck_ffs we could just do something like
 
      exter daddr_t dev_bshift;
 
      daddr_t dev_bshift = DEV_BSHIFT;
 
      #define BTODB(size) ((size) >> dev_bshift)
      #define DBTOB(size) ((size) << dev_bshift)
 
 and change the value of dev_bsize, if necessary, in the setup.  The 
 kernel would do the same, but storing the dev_bshift value in struct 
 ump.  Would this address your concern?
 
 Thanks,
 
 -Konrad
 
 On 8/17/2019 4:20 AM, Michael van Elst wrote:
 > The following reply was made to PR kern/54470; it has been noted by GNATS.
 >
 > From: mlelstv%serpens.de@localhost (Michael van Elst)
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/54470: Adapt FFS to work with HP-UX UFS1 variant
 > Date: Sat, 17 Aug 2019 11:15:28 -0000 (UTC)
 >
 >   perseant%hhhh.org@localhost (Konrad Schroder) writes:
 >   
 >   >Can you be more specific?�  It gives the right values for my HP-UX image,
 >   >and for existing NetBSD file systems.
 >   
 >   >>   >+#define BTODB(fs, size) ((size) >> ((fs)->fs_fshift - (fs)->fs_fsbtodb))
 >   >>   >+#define DBTOB(fs, bc)   ((bc) << ((fs)->fs_fshift - (fs)->fs_fsbtodb))
 >   
 >   The original BSD code used definitions like these above as a 'disk offset'
 >   referred to physical block numbers. This is still used that way in
 >   userland.
 >   
 >   NetBSD disk drivers always use logical block numbers for a block size
 >   of 512 bytes (DEV_BSIZE) and filesystems ignore the superblock values when
 >   translating between filesystem block numbers and disk block numbers.
 >   
 >   For FFS the macros FFS_FSBTODB / FFS_DBTOFSB are used to do this conversion.
 >   They are differently defined for kernel and userland to address the different
 >   views.
 >   
 >   btodb / dbtob are originally MD macros (then unified) that always used
 >   a platform specific unit, i.e. DEV_BSIZE, to specify disk offsets. This
 >   unit is independent of a particular filesystem and the physical blocks of
 >   a specific device.
 >   
 >   Now what unit does di_blocks use, it's only used for reporting and quota
 >   calculations ? The original code used btodb(file_length), i.e. the values
 >   used the platform-wide DEV_BSIZE as a unit and that's what we still use
 >   today.
 >   
 >   Your patch changes that and di_blocks is now using the physical block
 >   size of the particular disk (recorded in the superblock) as the unit.
 >   Apparently that's what HP-UX is doing.
 >   
 >   I see two issues: you added another view on disk offsets and you break
 >   existing filesystems that use a physical sector size != 512.
 >   
 >   Apparently we need conditional code to handle di_blocks for the
 >   different systems.
 >   
 >   
 >   --
 >   --
 >                                   Michael van Elst
 >   Internet: mlelstv%serpens.de@localhost
 >                                   "A potential Snark may lurk in every tree."
 >   
 


Home | Main Index | Thread Index | Old Index