Kernel 3.x patches with EL7 issues
HP-UX LVM and vxfs support for Linux
Status: Alpha
Brought to you by:
kblaszkowski
Menu
▾
▴
1 Attachments
#1 Kernel 3.x patches with EL7 issues
I did my best in re-factoring the Kernel 3.x patches for EL7 (RHEL) and was able to successfully compile freevxfs without warnings but when trying to mount a VXFS volume from HP-UX v11.31 (Itanium) I get:
dmesg:
[116414.364798] vxfs: WRONG superblock magic 00000000 at 1 [116414.365108] vxfs: unable to set final block size
I've attached my patch which may be incomplete as admittedly I'm not a C developer. I'm running RHEL 7.7 with kernel 3.10.0-1062.1.2.el7.x86_64. I formatted VXFS on HPUX as version 4 and tried varying blocksizes (newfs -F vxfs -b 8192 -o largefiles,version=4 /dev/rdisk/disk#),
fsdb -F vxfs /dev/rdisk/disk# > 8192B.p S super-block at 00000001.0000 magic a501fcf5 version 4 ctime 1590014986 764239 (Wed May 20 16:49:46 2020 MDT) log_version 12 logstart 0 logend 0 bsize 8192 size 655360 dsize 655360 ninode 0 nau 0 defiextsize 0 oilbsize 0 immedlen 96 ndaddr 10 aufirst 0 emap 0 imap 0 iextop 0 istart 0 bstart 0 femap 0 fimap 0 fiextop 0 fistart 0 fbstart 0 nindir 2048 aulen 32768 auimlen 0 auemlen 1 auilen 0 aupad 0 aublocks 32768 maxtier 15 inopb 32 inopau 0 ndiripau 0 iaddrlen 1 bshift 13 inoshift 5 bmask ffffe000 boffmask 1fff checksum 3e882fe free 386616 ifree 0 efree 2 1 1 2 2 2 3 2 0 0 1 0 0 1 1 1 1 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 flags 0 mod 0 clean 3c time 1590015365 826604 (Wed May 20 16:56:05 2020 MDT) oltext[0] 11 oltext[1] 2308 oltsize 1 iauimlen 1 iausize 4 dinosize 256 checksum2 a17 checksum3 0
Any suggestions? I realize this module was tested on and older version of HP-UX but was hoping that by formatting VXFS as version 4 (lowest supported version) I could get it to work.
It is sad to hear that your effort was wasted. I will describe background of this kernel module more detailed. Me and maybe w few others in the World use this facility to maintain user file system created by logic analyzer tool which runs hp ux 10.
(see ref. https://www.techtravels.org/2020/03/mount_hpux_in_linux/)
If there are any changes to SB layout in hp ux 11 then adding support for them in the kernel module will require further reverse engineering and working on raw fs images.
Unfortunately I do not have any image file of vxfs created by hp ux 11 neither technical specification of vxfs internals. There was a kernel module available which supported little endian order only. The module was created by Christoph Hellwig originally and some way I was lucky that adding BE order (and fixing minor things) was sufficiently enough thus it was possible to mount vxfs came from hp ux 10.
I was thinking that you may consider using VM and give a try to some more recent Linux, e.g. that one which uses kernel 4.9 and above so you will save your time on porting uncertain thing back to kernel 3.10-rhel7 for a moment. This step will verify also if there happened some porting mistakes.
Like I sad I do not have an image of vxfs created by hp ux 11, using fsdb from hp ux 10 does not make too much sense I reckon and I haven't logged into my hp16702 for long time so forgot credentials - this stands for "massive action" on recovering them.
So it is up to you if you want to collaborate on this or I will close this ticket as "won't fix".
Thanks for the response, suggestion and background. Some background on this effort, it was a long shot in reducing migration time for Oracle DB running on HP-UX, exporting directly to a FC attached LUN formatted with VXFS then re-attaching onto Linux. While this approach would have cut down migration time, I'll have to settle with exporting to an NFS mount from the target migration environment on Linux (Network is a bottleneck) and work on enhancing that as much as possible.
I installed the latest stable Kernel from elrepo (5.6.14-1.el7.elrepo.x86_64) then compiled FreeVXFS from 5.6.14 source but I ended up with the same error:
You can close this as "won't fix" but I've attached a 100MB VXFSv4 image (from HP-UX v11.31) in case someone want's to take a look. If it somehow interests you then I could collaborate on it, however it's not really an area of my expertise and I have another (slower) viable option available. I couldn't loop mount the file though after creating it in HP-UX, odd they have an option to create the filesystem on a file but not mount it, at least not that I could see. So I guess this is only useful on Linux (fsdb from Veritas maybe will help).
For reference, created with:
You are welcome. That's interesting because I used to develop scsi tape drive emulations years ago.
So you want to have this solved likely and it seems you can create vxfs image with ease.
That is good idea on creating some test image however if you create more test images then these images may help sorting this out better. It is not about image size but rather diversity and let's have this done:
image #1 : empty 10MB
image #2 : empty 20MB
image #3 : 10MB with one file of a few kB size (whatever content, maybe GPL text ?)
image #4: 20MB with 10 files of 1M each size in directory "10files" and 300 files of 10k size each in directory "300files" (dd if=/dev/urandom ? - whatever)
please provide statistics reported by fsdb for every image and e.g. cksum (*sum) output for every file.
These images with files can be used as test data to verify correctness of directory and file services to the extent read-only mode allows.
If you do this then I will try to have a look at them this week (so maybe on Monday will let you know how it is going) and even if I did not make this done then it would be easier for someone else always.
Let's try to sort this out
BR
Great, I'm glad you're willing to take a look, if we get it going it will help out a lot and the community can benefit at the same time.
I formatted the filesystems with a 1k blocksize, I can provide more samples formatted up to 8k if you'd like. With an 8k block size though the default logsize is 8MB (1024 blocks @ 8k) so we'd have to change the 20M test, increase the filesystem size, or decrease the logsize to accommodate. http://nixdoc.net/man-pages/HP-UX/man1/mkfs_vxfs.1m.html
Here's a description of the files in the kvxfs.7z archive attached:
vxfs.log - Log of commands ran
e10M.vxfs.gz - Gzipped empty 10M image
e20M.vxfs.gz - Gzipped empty 20M image
p10M.vxfs.gz - Gzipped populated 10M image
p20M.vxfs.gz - Gzipped populated 20M image
10files.cksum - cksum of the 10 files in the 10files directory
300files.cksum - cksum of the 300 files in the 300files directory
Note: The files in the directories are names file{1..10}.rand and file{1..300}.rand
I ran into an attachment size limit so I created a 7z archive.
Sure, I don't like to give up for poor or no reason.
Splendid.
So, let me share my conclusion.
Well, I mounted the p20M.vxfs and also the very 1st one 100M image successfully.
Double checked cksums of files and all remained intact.
Please see attached test script and screenshot for reference. I worked on 4.4 kernel with backported vxfs module.
I had to use sort before calling final cksum on cksums because Linux bash and HP-UX use slightly different file sorting order by default.
I must admit that I regret that I followed genuine logging style which is very basic and thus mounting vxfs may be confusing apart from kernel 3.10 rhel 7 case - I will write later. The kernel module supports two vxfs formats: x86 unixware and HP-UX (10.x is recognized to be working decent so far). These formats differ in endianess and location of super block, unixware places SB (LE formatted) at +1k offset while the latter one at +8k offset and SB uses BE.
So the int vxfs_fill_super() calls twice vxfs_try_sb_magic() for these two cases and unixware case takes precedence thus the module writes to kernel log that magic number is invalid for HP-UX vxfs image.
However if this is the only one kernel log message that there was invalid magic at +1k block then everything is good very likely and the log message may confuse only.
More important is exit code of mount process.
I do not check it in attached script either however I do call mount to double check if the loop device has been mounted properly and it was.
I reckon that your last attempt to mount the image (on 5.x kernel) was successful and you missed it because of the kernel log warning for unixware case.
Back to the kernel 3.10-rhel7 - there is something odd indeed because of the log like "unable to set final block size"
and if double checked the sb_min_blocksize() then it turns out that it may fail for following reasons:
2nd arg is less than 512, larger then page size or it is not power of two or the underlying block device does not support it.
Kernel 3.10.63 sets macro BLOCK_SIZE to 1k (ref.: include/uapi/linux/fs.h)
I haven't tried kernel 3.10 but it is possible that 3.10's loop module does not support 1k block and that's why vxfs_fill_super() failed under kernel 3.10-rhel7. It's weird and difficult to find right reason without using some VM running rhel7.
I've done my work on kernel 3.16 originally so 3.16 is known to be good but 3.10 which requires further investigation.
So can you give a try to e.g. the script ? I wonder if it will be possible to mount the p20M image under kernel 5. I have not verified this yet.
I may try to sort 3.10-rhel7 out later.
Ugh, I can't believe I missed that when using the 5.x kernel! There was another error about selinux, but I was running in permissive mode and didn't think it was blocking mount, so I didn't think anything of it:
Completely disabling SELinux works and checksums are good too! It turns out RHEL added VxFS support in selinux-policy for 7.6, and because of that upgrade VxFS filesystems need to be able to store the extended attribute "security.selinux".
I also found out today that RHEL8 is supported with Oracle DB 19c and comes with a 4.18.x Kernel, so now that this is working I have a couple of options:
-Temporarily use unsupported 5.x kernel for the import and switch back
-Use RHEL8 and compile the FreeVXFS module for 4.18
I'm assuming your changes are in 4.18 mainline, if not, I can merge them. You don't need to mess around with 3.10 (CentOS/RHEL7) anymore unless you really want to.
Thank you for your time, so glad it's working now!
Glad to see it works, it seems we have done it.
yes, you are right about 4.18. These changes have been merged into mainline since 4.9 kernel.
CentOS/Rhel7 - good enough, I don't miss it. I was thinking that loop device may require to set block size up explicitly for this kernel otherwise a change requested by the module on-the-fly fails. It's just a guess so I can be wrong.
You are welcome and I'm glad too we have done good job on this. I'm going to close the ticket on Friday. It will have resolved status for sure.
Resolved. Mainline kernel's (4.9 and later) freevxfs and HP-UX 11 vxfs rev 4 image seem to work