MSeedScan - Inode numbers from dirent and stat do not match

[znamy]

Hello, Chad!

Trying to set up ringserver for our seismic data archive. Got an issue around MSeedScan operation. Here is some part from ring.log

Sat Apr 04 11:05:22 2020 - ringserver version: 2020.075
Sat Apr 04 11:05:22 2020 - Ring initialized, ringsize: 1073741824, pktsize: 632 (512)
Sat Apr 04 11:05:22 2020 - [MSeedScan] Inode numbers from dirent and stat do not match for /home/max/DATA/2019/SP2019/DATA/mseed2/ALFA/NT.ALFA..HHE.D.2019.100

Sat Apr 04 11:05:22 2020 -   dirent: 48883  VS  stat: 1054

And the same for the rest of the data records in data directory. Those data was acquired via seiscom3 system. What's wrong with it? Meanwhile it's no problem reading this miniseed data with obspy library and other software dealing with miniseed.

[chad-earthscope]

Hello @znamy. Well, that's strange. The system readdir() call does the programmatic equivalent of listing a directory's contents. While scanning the file entries, a stat() is done. There is a sanity check that compares the inode values returned from readdir(), giving a 'dirent' and stat(). It is odd that these do not match.

What kind of file system are the files on (NFS? provided by a VM? Docker?). Are there any symbolic links involved? I would appreciate learning under what scenario this is occuring.

This sanity check is not actually needed, and can probably be safely removed. I can remove it from future releases if it seems like the scenario is going to be more common.

You may remove the check by commenting out the following code and see if the files are scanned as expected:

mseedscan.c:

    /* Sanity check that the dirent inode and stat inode are the same */
    if (st.st_ino != ede->d_ino)
    {
      lprintf (0, "[MSeedScan] Inode numbers from dirent and stat do not match for %s\n", fkey->filename);
      lprintf (0, "  dirent: %llu  VS  stat: %llu\n",
               (unsigned long long int)ede->d_ino, (unsigned long long int)st.st_ino);
      continue;
    }

[chad-earthscope]

Here's a test for the same thing in GNU coreutils (where the ls command comes from for many systems):

https://github.com/coreutils/coreutils/blob/master/tests/ls/stat-vs-dirent.sh

The error that comes out if the inode values do not match:

This may indicate a flaw in your kernel or file system implementation.
The flaw isn't serious for coreutils, but it might break other tools,
so you should report it to your operating system vendor.

[znamy]

Ok, it looks like you turned me to right direction and I've got the clue!

What kind of file system are the files on (NFS? provided by a VM? Docker?). Are there any symbolic links involved? I would appreciate learning under what scenario this is occuring.

I compiled and started ringserver under UBUNTU 18 SERVER inside VIRTUALBOX VM. And the access to the data archive was organized through shared folders system of VIRTUALBOX originally residing on NTFS volume of the host OS WIN10. It looks bit unusual, I assume. So I made a copy of some part of our data and located it on native LINUX ext4 FS of the guest OS. Since then it's all fine! May be I should change the way the data is shared between systems to SMB and try again.

Thank you for your rapid response! Your help was much appreciated!