I am using:

debugfs -R 'stat <7473635>' /dev/sda7

to get the file creation time (crtime).

Inode: 7473635   Type: regular    Mode:  0664   Flags: 0x80000
Generation: 1874934325    Version: 0x00000000:00000001
User:  1000   Group:  1000   Size: 34
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x55b65ebc:98040bc4 -- Mon Jul 27 22:09:24 2015
 atime: 0x55da0168:60b33f74 -- Sun Aug 23 22:52:48 2015
 mtime: 0x55b65ebc:98040bc4 -- Mon Jul 27 22:09:24 2015
crtime: 0x55b65ebc:970fe7cc -- Mon Jul 27 22:09:24 2015
Size of extra inode fields: 28

Why am I not getting crtime in nanoseconds even though ext4 supports nanosecond resolution?


It does show the timestamp (with nanoseconds precision) but in hex; it's the field after crtime:, e.g. in your output 0x55b65ebc:970fe7cc. The part after the colon is the nanoseconds.
This article gives more details and explains how to calculate the timestamp/nanoseconds. So, e.g. to convert the hex values to a timestamp a la stat you could run:

date -d @$(printf %d 0x55b65ebc).$(( $(printf %d 0x970fe7cc) / 4 )) +'%F %T.%N %z'
2015-07-27 19:39:24.633600499 +0300
  • Wow, thanks! After reading @Mark Plotnick's answer I was just about to ask what those hex meant! – Ron Aug 24 '15 at 17:26

It looks like debugfs does not yet support printing out the sub-second portion (the upper 30 bits of i_xtime_extra) of timestamps in its asctime-based format. From http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/debugfs/debugfs.c :

if (is_large_inode && large_inode->i_extra_isize >= 24) {
        fprintf(out, "%s ctime: 0x%08x:%08x -- %s", prefix,
            inode->i_ctime, large_inode->i_ctime_extra,
        fprintf(out, "%s atime: 0x%08x:%08x -- %s", prefix,
            inode->i_atime, large_inode->i_atime_extra,
        fprintf(out, "%s mtime: 0x%08x:%08x -- %s", prefix,
            inode->i_mtime, large_inode->i_mtime_extra,
        fprintf(out, "%scrtime: 0x%08x:%08x -- %s", prefix,
            large_inode->i_crtime, large_inode->i_crtime_extra,
  • Thanks for the link, but I've to accept @don_crissti's post as the answer because it provided the solution. – Ron Aug 24 '15 at 17:28
  • 1
    Fair enough. At some point, I'll write a patch that takes the i_*time_extra field into account. The field provides not only nanosecond precision but also gives extended range for the date, by adding bits to i_*time to make it a 34-bit number. – Mark Plotnick Aug 24 '15 at 18:45
  • That would be great! – Ron Aug 25 '15 at 4:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.