[RFC,v2,03/83] Add super.h.

Commit Message

Andiry Xu March 10, 2018, 6:17 p.m. UTC

From: Andiry Xu <[e-mail]>

This header file defines NOVA persistent and volatile superblock
data structures.

It also defines NOVA block layout:

Page 0: Superblock
Page 1: Reserved inodes
Page 2 - 15: Reserved
Page 16 - 31: Inode table pointers
Page 32 - 47: Journal address pointers
Page 48 - 63: Reserved
Pages n-2: Replicate reserved inodes
Pages n-1: Replicate superblock

Other pages are for normal inodes, logs and data.

Signed-off-by: Andiry Xu <[e-mail]>
---
 fs/nova/super.h | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 fs/nova/super.h

Comments

Darrick J. Wong March 15, 2018, 4:54 a.m. UTC | #1

On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:
> From: Andiry Xu <[e-mail]>
> 
> This header file defines NOVA persistent and volatile superblock
> data structures.
> 
> It also defines NOVA block layout:
> 
> Page 0: Superblock
> Page 1: Reserved inodes
> Page 2 - 15: Reserved
> Page 16 - 31: Inode table pointers
> Page 32 - 47: Journal address pointers
> Page 48 - 63: Reserved
> Pages n-2: Replicate reserved inodes
> Pages n-1: Replicate superblock
> 
> Other pages are for normal inodes, logs and data.
> 
> Signed-off-by: Andiry Xu <[e-mail]>
> ---
>  fs/nova/super.h | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 149 insertions(+)
>  create mode 100644 fs/nova/super.h
> 
> diff --git a/fs/nova/super.h b/fs/nova/super.h
> new file mode 100644
> index 0000000..cb53908
> --- /dev/null
> +++ b/fs/nova/super.h
> @@ -0,0 +1,149 @@
> +#ifndef __SUPER_H
> +#define __SUPER_H
> +/*
> + * Structure of the NOVA super block in PMEM
> + *
> + * The fields are partitioned into static and dynamic fields. The static fields
> + * never change after file system creation. This was primarily done because
> + * nova_get_block() returns NULL if the block offset is 0 (helps in catching
> + * bugs). So if we modify any field using journaling (for consistency), we
> + * will have to modify s_sum which is at offset 0. So journaling code fails.
> + * This (static+dynamic fields) is a temporary solution and can be avoided
> + * once the file system becomes stable and nova_get_block() returns correct
> + * pointers even for offset 0.
> + */
> +struct nova_super_block {
> +	/* static fields. they never change after file system creation.
> +	 * checksum only validates up to s_start_dynamic field below
> +	 */
> +	__le32		s_sum;			/* checksum of this sb */
> +	__le32		s_magic;		/* magic signature */
> +	__le32		s_padding32;
> +	__le32		s_blocksize;		/* blocksize in bytes */
> +	__le64		s_size;			/* total size of fs in bytes */
> +	char		s_volume_name[16];	/* volume name */
> +
> +	/* all the dynamic fields should go here */
> +	__le64		s_epoch_id;		/* Epoch ID */
> +
> +	/* s_mtime and s_wtime should be together and their order should not be
> +	 * changed. we use an 8 byte write to update both of them atomically
> +	 */
> +	__le32		s_mtime;		/* mount time */
> +	__le32		s_wtime;		/* write time */

Hmmm, 32-bit timestamps?  2038 isn't that far away...

> +} __attribute((__packed__));
> +
> +#define NOVA_SB_SIZE 512       /* must be power of two */
> +
> +/* ======================= Reserved blocks ========================= */
> +
> +/*
> + * Page 0 contains super blocks;
> + * Page 1 contains reserved inodes;
> + * Page 2 - 15 are reserved.
> + * Page 16 - 31 contain pointers to inode tables.
> + * Page 32 - 47 contain pointers to journal pages.
> + */
> +#define	HEAD_RESERVED_BLOCKS	64
> +#define	NUM_JOURNAL_PAGES	16
> +
> +#define	SUPER_BLOCK_START       0 // Superblock
> +#define	RESERVE_INODE_START	1 // Reserved inodes
> +#define	INODE_TABLE_START	16 // inode table pointers
> +#define	JOURNAL_START		32 // journal pointer table
> +
> +/* For replica super block and replica reserved inodes */
> +#define	TAIL_RESERVED_BLOCKS	2
> +
> +/* ======================= Reserved inodes ========================= */
> +
> +/* We have space for 31 reserved inodes */
> +#define NOVA_ROOT_INO		(1)
> +#define NOVA_INODETABLE_INO	(2)	/* Fake inode associated with inode
> +					 * stroage.  We need this because our
> +					 * allocator requires inode to be
> +					 * associated with each allocation.
> +					 * The data actually lives in linked
> +					 * lists in INODE_TABLE_START. */
> +#define NOVA_BLOCKNODE_INO	(3)     /* Storage for allocator state */
> +#define NOVA_LITEJOURNAL_INO	(4)     /* Storage for lightweight journals */
> +#define NOVA_INODELIST_INO	(5)     /* Storage for Inode free list */
> +
> +
> +/* Normal inode starts at 32 */
> +#define NOVA_NORMAL_INODE_START      (32)

I've been wondering this whole time, why not make the inode number the
byte offset into the pmem?  Then you don't have to lose the last 8 bytes
of each inode block to point to the next one.

--D

> +
> +
> +
> +/*
> + * NOVA super-block data in DRAM
> + */
> +struct nova_sb_info {
> +	struct super_block *sb;			/* VFS super block */
> +	struct nova_super_block *nova_sb;	/* DRAM copy of SB */
> +	struct block_device *s_bdev;
> +	struct dax_device *s_dax_dev;
> +
> +	/*
> +	 * base physical and virtual address of NOVA (which is also
> +	 * the pointer to the super block)
> +	 */
> +	phys_addr_t	phys_addr;
> +	void		*virt_addr;
> +	void		*replica_reserved_inodes_addr;
> +	void		*replica_sb_addr;
> +
> +	unsigned long	num_blocks;
> +
> +	/* Mount options */
> +	unsigned long	bpi;
> +	unsigned long	blocksize;
> +	unsigned long	initsize;
> +	unsigned long	s_mount_opt;
> +	kuid_t		uid;    /* Mount uid for root directory */
> +	kgid_t		gid;    /* Mount gid for root directory */
> +	umode_t		mode;   /* Mount mode for root directory */
> +	atomic_t	next_generation;
> +	/* inode tracking */
> +	unsigned long	s_inodes_used_count;
> +	unsigned long	head_reserved_blocks;
> +	unsigned long	tail_reserved_blocks;
> +
> +	struct mutex	s_lock;	/* protects the SB's buffer-head */
> +
> +	int cpus;
> +
> +	/* Current epoch. volatile guarantees visibility */
> +	volatile u64 s_epoch_id;
> +
> +	/* ZEROED page for cache page initialized */
> +	void *zeroed_page;
> +};
> +
> +static inline struct nova_sb_info *NOVA_SB(struct super_block *sb)
> +{
> +	return sb->s_fs_info;
> +}
> +
> +static inline struct nova_super_block
> +*nova_get_redund_super(struct super_block *sb)
> +{
> +	struct nova_sb_info *sbi = NOVA_SB(sb);
> +
> +	return (struct nova_super_block *)(sbi->replica_sb_addr);
> +}
> +
> +
> +/* If this is part of a read-modify-write of the super block,
> + * nova_memunlock_super() before calling!
> + */
> +static inline struct nova_super_block *nova_get_super(struct super_block *sb)
> +{
> +	struct nova_sb_info *sbi = NOVA_SB(sb);
> +
> +	return (struct nova_super_block *)sbi->virt_addr;
> +}
> +
> +extern void nova_error_mng(struct super_block *sb, const char *fmt, ...);
> +
> +#endif
> -- 
> 2.7.4
>

Andiry Xu March 15, 2018, 6:11 a.m. UTC | #2

On Wed, Mar 14, 2018 at 9:54 PM, Darrick J. Wong
<[e-mail]> wrote:
> On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:
>> From: Andiry Xu <[e-mail]>
>>
>> This header file defines NOVA persistent and volatile superblock
>> data structures.
>>
>> It also defines NOVA block layout:
>>
>> Page 0: Superblock
>> Page 1: Reserved inodes
>> Page 2 - 15: Reserved
>> Page 16 - 31: Inode table pointers
>> Page 32 - 47: Journal address pointers
>> Page 48 - 63: Reserved
>> Pages n-2: Replicate reserved inodes
>> Pages n-1: Replicate superblock
>>
>> Other pages are for normal inodes, logs and data.
>>
>> Signed-off-by: Andiry Xu <[e-mail]>
>> ---
>>  fs/nova/super.h | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 149 insertions(+)
>>  create mode 100644 fs/nova/super.h
>>
>> diff --git a/fs/nova/super.h b/fs/nova/super.h
>> new file mode 100644
>> index 0000000..cb53908
>> --- /dev/null
>> +++ b/fs/nova/super.h
>> @@ -0,0 +1,149 @@
>> +#ifndef __SUPER_H
>> +#define __SUPER_H
>> +/*
>> + * Structure of the NOVA super block in PMEM
>> + *
>> + * The fields are partitioned into static and dynamic fields. The static fields
>> + * never change after file system creation. This was primarily done because
>> + * nova_get_block() returns NULL if the block offset is 0 (helps in catching
>> + * bugs). So if we modify any field using journaling (for consistency), we
>> + * will have to modify s_sum which is at offset 0. So journaling code fails.
>> + * This (static+dynamic fields) is a temporary solution and can be avoided
>> + * once the file system becomes stable and nova_get_block() returns correct
>> + * pointers even for offset 0.
>> + */
>> +struct nova_super_block {
>> +     /* static fields. they never change after file system creation.
>> +      * checksum only validates up to s_start_dynamic field below
>> +      */
>> +     __le32          s_sum;                  /* checksum of this sb */
>> +     __le32          s_magic;                /* magic signature */
>> +     __le32          s_padding32;
>> +     __le32          s_blocksize;            /* blocksize in bytes */
>> +     __le64          s_size;                 /* total size of fs in bytes */
>> +     char            s_volume_name[16];      /* volume name */
>> +
>> +     /* all the dynamic fields should go here */
>> +     __le64          s_epoch_id;             /* Epoch ID */
>> +
>> +     /* s_mtime and s_wtime should be together and their order should not be
>> +      * changed. we use an 8 byte write to update both of them atomically
>> +      */
>> +     __le32          s_mtime;                /* mount time */
>> +     __le32          s_wtime;                /* write time */
>
> Hmmm, 32-bit timestamps?  2038 isn't that far away...
>

I will try fixing this in the next version.

>> +} __attribute((__packed__));
>> +
>> +#define NOVA_SB_SIZE 512       /* must be power of two */
>> +
>> +/* ======================= Reserved blocks ========================= */
>> +
>> +/*
>> + * Page 0 contains super blocks;
>> + * Page 1 contains reserved inodes;
>> + * Page 2 - 15 are reserved.
>> + * Page 16 - 31 contain pointers to inode tables.
>> + * Page 32 - 47 contain pointers to journal pages.
>> + */
>> +#define      HEAD_RESERVED_BLOCKS    64
>> +#define      NUM_JOURNAL_PAGES       16
>> +
>> +#define      SUPER_BLOCK_START       0 // Superblock
>> +#define      RESERVE_INODE_START     1 // Reserved inodes
>> +#define      INODE_TABLE_START       16 // inode table pointers
>> +#define      JOURNAL_START           32 // journal pointer table
>> +
>> +/* For replica super block and replica reserved inodes */
>> +#define      TAIL_RESERVED_BLOCKS    2
>> +
>> +/* ======================= Reserved inodes ========================= */
>> +
>> +/* We have space for 31 reserved inodes */
>> +#define NOVA_ROOT_INO                (1)
>> +#define NOVA_INODETABLE_INO  (2)     /* Fake inode associated with inode
>> +                                      * stroage.  We need this because our
>> +                                      * allocator requires inode to be
>> +                                      * associated with each allocation.
>> +                                      * The data actually lives in linked
>> +                                      * lists in INODE_TABLE_START. */
>> +#define NOVA_BLOCKNODE_INO   (3)     /* Storage for allocator state */
>> +#define NOVA_LITEJOURNAL_INO (4)     /* Storage for lightweight journals */
>> +#define NOVA_INODELIST_INO   (5)     /* Storage for Inode free list */
>> +
>> +
>> +/* Normal inode starts at 32 */
>> +#define NOVA_NORMAL_INODE_START      (32)
>
> I've been wondering this whole time, why not make the inode number the
> byte offset into the pmem?  Then you don't have to lose the last 8 bytes
> of each inode block to point to the next one.
>

During failure recovery, NOVA scans the inode logs. To find all the
inodes, it follows the inode block list. Making inode number the byte
offset cannot locate all the inodes during recovery.

One option is to organize the inodes in a B+tree, which makes the code
more complex.

Thanks,
Andiry

> --D
>
>> +
>> +
>> +
>> +/*
>> + * NOVA super-block data in DRAM
>> + */
>> +struct nova_sb_info {
>> +     struct super_block *sb;                 /* VFS super block */
>> +     struct nova_super_block *nova_sb;       /* DRAM copy of SB */
>> +     struct block_device *s_bdev;
>> +     struct dax_device *s_dax_dev;
>> +
>> +     /*
>> +      * base physical and virtual address of NOVA (which is also
>> +      * the pointer to the super block)
>> +      */
>> +     phys_addr_t     phys_addr;
>> +     void            *virt_addr;
>> +     void            *replica_reserved_inodes_addr;
>> +     void            *replica_sb_addr;
>> +
>> +     unsigned long   num_blocks;
>> +
>> +     /* Mount options */
>> +     unsigned long   bpi;
>> +     unsigned long   blocksize;
>> +     unsigned long   initsize;
>> +     unsigned long   s_mount_opt;
>> +     kuid_t          uid;    /* Mount uid for root directory */
>> +     kgid_t          gid;    /* Mount gid for root directory */
>> +     umode_t         mode;   /* Mount mode for root directory */
>> +     atomic_t        next_generation;
>> +     /* inode tracking */
>> +     unsigned long   s_inodes_used_count;
>> +     unsigned long   head_reserved_blocks;
>> +     unsigned long   tail_reserved_blocks;
>> +
>> +     struct mutex    s_lock; /* protects the SB's buffer-head */
>> +
>> +     int cpus;
>> +
>> +     /* Current epoch. volatile guarantees visibility */
>> +     volatile u64 s_epoch_id;
>> +
>> +     /* ZEROED page for cache page initialized */
>> +     void *zeroed_page;
>> +};
>> +
>> +static inline struct nova_sb_info *NOVA_SB(struct super_block *sb)
>> +{
>> +     return sb->s_fs_info;
>> +}
>> +
>> +static inline struct nova_super_block
>> +*nova_get_redund_super(struct super_block *sb)
>> +{
>> +     struct nova_sb_info *sbi = NOVA_SB(sb);
>> +
>> +     return (struct nova_super_block *)(sbi->replica_sb_addr);
>> +}
>> +
>> +
>> +/* If this is part of a read-modify-write of the super block,
>> + * nova_memunlock_super() before calling!
>> + */
>> +static inline struct nova_super_block *nova_get_super(struct super_block *sb)
>> +{
>> +     struct nova_sb_info *sbi = NOVA_SB(sb);
>> +
>> +     return (struct nova_super_block *)sbi->virt_addr;
>> +}
>> +
>> +extern void nova_error_mng(struct super_block *sb, const char *fmt, ...);
>> +
>> +#endif
>> --
>> 2.7.4
>>

Arnd Bergmann March 15, 2018, 9:05 a.m. UTC | #3

On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu <[e-mail]> wrote:
> On Wed, Mar 14, 2018 at 9:54 PM, Darrick J. Wong
> <[e-mail]> wrote:
>> On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:

>>> +     /* s_mtime and s_wtime should be together and their order should not be
>>> +      * changed. we use an 8 byte write to update both of them atomically
>>> +      */
>>> +     __le32          s_mtime;                /* mount time */
>>> +     __le32          s_wtime;                /* write time */
>>
>> Hmmm, 32-bit timestamps?  2038 isn't that far away...
>>
>
> I will try fixing this in the next version.

I would also recommend adding nanosecond-resolution timestamps.
In theory, a signed 64-bit nanosecond field is sufficient for each timestamp
(it's good for several hundred years), but the more common format uses
64-bit seconds and 32-bit nanoseconds in other file systems.

Unfortunately it looks, you will have to come up with a more sophisticated
update method above, even if you leave out the nanoseconds, you can't
easily rely on a 16-byte atomic update across architectures to deal with
the two 64-bit timestamps. For the superblock fields, you might be able
to get away with using second resolution, and then encoding the
timestamps as a signed 64-bit 'mkfs time' along with two unsigned
32-bit times added on top, which gives you a range of 136 years mount
a file system after its creation.

      Arnd

Andiry Xu March 15, 2018, 5:51 p.m. UTC | #4

On Thu, Mar 15, 2018 at 2:05 AM, Arnd Bergmann <[e-mail]> wrote:
> On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu <[e-mail]> wrote:
>> On Wed, Mar 14, 2018 at 9:54 PM, Darrick J. Wong
>> <[e-mail]> wrote:
>>> On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:
>
>>>> +     /* s_mtime and s_wtime should be together and their order should not be
>>>> +      * changed. we use an 8 byte write to update both of them atomically
>>>> +      */
>>>> +     __le32          s_mtime;                /* mount time */
>>>> +     __le32          s_wtime;                /* write time */
>>>
>>> Hmmm, 32-bit timestamps?  2038 isn't that far away...
>>>
>>
>> I will try fixing this in the next version.
>
> I would also recommend adding nanosecond-resolution timestamps.
> In theory, a signed 64-bit nanosecond field is sufficient for each timestamp
> (it's good for several hundred years), but the more common format uses
> 64-bit seconds and 32-bit nanoseconds in other file systems.
>
> Unfortunately it looks, you will have to come up with a more sophisticated
> update method above, even if you leave out the nanoseconds, you can't
> easily rely on a 16-byte atomic update across architectures to deal with
> the two 64-bit timestamps. For the superblock fields, you might be able
> to get away with using second resolution, and then encoding the
> timestamps as a signed 64-bit 'mkfs time' along with two unsigned
> 32-bit times added on top, which gives you a range of 136 years mount
> a file system after its creation.
>

I will take a look at other file systems.

Superblock mtime is not a big problem as it is updated rarely. 64-bit
seconds and 32-bit nanoseconds make the inode and log entry bigger,
and updating file->atime cannot be done with a single 64bit update.
That may be annoying and needs to use journaling.

Thanks,
Andiry

>       Arnd

Arnd Bergmann March 15, 2018, 8:38 p.m. UTC | #5

On Thu, Mar 15, 2018 at 6:51 PM, Andiry Xu <[e-mail]> wrote:
> On Thu, Mar 15, 2018 at 2:05 AM, Arnd Bergmann <[e-mail]> wrote:
>> On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu <[e-mail]> wrote:
>
> Superblock mtime is not a big problem as it is updated rarely. 64-bit
> seconds and 32-bit nanoseconds make the inode and log entry bigger,
> and updating file->atime cannot be done with a single 64bit update.
> That may be annoying and needs to use journaling.

If this is a big concern, you could use a format similar to what ext4 has:
30 bits of nanoseconds, and 34 bits of seconds, where the upper two
bits count the epoch. That gives you a time range from years 1902 to
2446.

You could also have a resolution of less than a nanosecond. Note
that today, the file time stamps generated by the kernel are in
jiffies resolution, so at best one millisecond. However, most modern
file systems go with the 64+32 bit timestamps because it's not all
that expensive.

      Arnd

Theodore Ts'o March 16, 2018, 2:59 a.m. UTC | #6

On Thu, Mar 15, 2018 at 09:38:29PM +0100, Arnd Bergmann wrote:
> 
> You could also have a resolution of less than a nanosecond. Note
> that today, the file time stamps generated by the kernel are in
> jiffies resolution, so at best one millisecond. However, most modern
> file systems go with the 64+32 bit timestamps because it's not all
> that expensive.

It actually depends on the architecture and the accuracy/granularity
of the timekeeping hardware available to the system, but it's possible
for the granularity of file time stamps to be up to one nanosecond.
So you can get results like this:

% stat unix_io.o 
  File: unix_io.o
  Size: 55000     	Blocks: 112        IO Block: 4096   regular file
Device: fc01h/64513d	Inode: 19931278    Links: 1
Access: (0644/-rw-r--r--)  Uid: (15806/   tytso)   Gid: (15806/   tytso)
Access: 2018-03-15 18:09:21.679914182 -0400
Modify: 2018-03-15 18:09:21.639914089 -0400
Change: 2018-03-15 18:09:21.639914089 -0400

Cheers,

					- Ted

Andiry Xu March 16, 2018, 6:17 a.m. UTC | #7

On Thu, Mar 15, 2018 at 7:59 PM, Theodore Y. Ts'o <[e-mail]> wrote:
> On Thu, Mar 15, 2018 at 09:38:29PM +0100, Arnd Bergmann wrote:
>>
>> You could also have a resolution of less than a nanosecond. Note
>> that today, the file time stamps generated by the kernel are in
>> jiffies resolution, so at best one millisecond. However, most modern
>> file systems go with the 64+32 bit timestamps because it's not all
>> that expensive.
>
> It actually depends on the architecture and the accuracy/granularity
> of the timekeeping hardware available to the system, but it's possible
> for the granularity of file time stamps to be up to one nanosecond.
> So you can get results like this:
>
> % stat unix_io.o
>   File: unix_io.o
>   Size: 55000           Blocks: 112        IO Block: 4096   regular file
> Device: fc01h/64513d    Inode: 19931278    Links: 1
> Access: (0644/-rw-r--r--)  Uid: (15806/   tytso)   Gid: (15806/   tytso)
> Access: 2018-03-15 18:09:21.679914182 -0400
> Modify: 2018-03-15 18:09:21.639914089 -0400
> Change: 2018-03-15 18:09:21.639914089 -0400
>

Thanks for all the suggestions. I think I will follow ext4's time
format. 2446 should be far away enough.

Thanks,
Andiry

Darrick J. Wong March 16, 2018, 6:30 a.m. UTC | #8

On Thu, Mar 15, 2018 at 11:17:54PM -0700, Andiry Xu wrote:
> On Thu, Mar 15, 2018 at 7:59 PM, Theodore Y. Ts'o <[e-mail]> wrote:
> > On Thu, Mar 15, 2018 at 09:38:29PM +0100, Arnd Bergmann wrote:
> >>
> >> You could also have a resolution of less than a nanosecond. Note
> >> that today, the file time stamps generated by the kernel are in
> >> jiffies resolution, so at best one millisecond. However, most modern
> >> file systems go with the 64+32 bit timestamps because it's not all
> >> that expensive.
> >
> > It actually depends on the architecture and the accuracy/granularity
> > of the timekeeping hardware available to the system, but it's possible
> > for the granularity of file time stamps to be up to one nanosecond.
> > So you can get results like this:
> >
> > % stat unix_io.o
> >   File: unix_io.o
> >   Size: 55000           Blocks: 112        IO Block: 4096   regular file
> > Device: fc01h/64513d    Inode: 19931278    Links: 1
> > Access: (0644/-rw-r--r--)  Uid: (15806/   tytso)   Gid: (15806/   tytso)
> > Access: 2018-03-15 18:09:21.679914182 -0400
> > Modify: 2018-03-15 18:09:21.639914089 -0400
> > Change: 2018-03-15 18:09:21.639914089 -0400
> >
> 
> Thanks for all the suggestions. I think I will follow ext4's time
> format. 2446 should be far away enough.

If you do, try to avoid the encoding problems that ext4 (still) has:

Not-fixed-by: a4dad1ae24f8 ("ext4: Fix handling of extended tv_sec")

--D

> Thanks,
> Andiry

Arnd Bergmann March 16, 2018, 9:19 a.m. UTC | #9

On Fri, Mar 16, 2018 at 3:59 AM, Theodore Y. Ts'o <[e-mail]> wrote:
> On Thu, Mar 15, 2018 at 09:38:29PM +0100, Arnd Bergmann wrote:
>>
>> You could also have a resolution of less than a nanosecond. Note
>> that today, the file time stamps generated by the kernel are in
>> jiffies resolution, so at best one millisecond. However, most modern
>> file systems go with the 64+32 bit timestamps because it's not all
>> that expensive.
>
> It actually depends on the architecture and the accuracy/granularity
> of the timekeeping hardware available to the system, but it's possible
> for the granularity of file time stamps to be up to one nanosecond.
> So you can get results like this:
>
> % stat unix_io.o
>   File: unix_io.o
>   Size: 55000           Blocks: 112        IO Block: 4096   regular file
> Device: fc01h/64513d    Inode: 19931278    Links: 1
> Access: (0644/-rw-r--r--)  Uid: (15806/   tytso)   Gid: (15806/   tytso)
> Access: 2018-03-15 18:09:21.679914182 -0400
> Modify: 2018-03-15 18:09:21.639914089 -0400
> Change: 2018-03-15 18:09:21.639914089 -0400

Note how the nanoseconds only differ in digits 2, 7, 8, and 9 though:

The atime update happened 4 jiffies (at HZ=100) after the mtime,
the low digits are presumably jitter or ntp adjustments.

This is the result of current_time() using the plain tk_xtime
rather than reading the highres clocksource as ktime_get_real_ts64()
does.

This was a performance optimization a long time ago. We could
make the current_time() behavior configurable if we want though,
e.g. at compile time, or as a per-mount option. It's probably more
common these days to have a highres clocksource that can
be read efficiently than it was back when current_fs_time()
was first introduced.

       Arnd

Patch

diff --git a/fs/nova/super.h b/fs/nova/super.h
new file mode 100644
index 0000000..cb53908
--- /dev/null
+++ b/fs/nova/super.h
@@ -0,0 +1,149 @@ 
+#ifndef __SUPER_H
+#define __SUPER_H
+/*
+ * Structure of the NOVA super block in PMEM
+ *
+ * The fields are partitioned into static and dynamic fields. The static fields
+ * never change after file system creation. This was primarily done because
+ * nova_get_block() returns NULL if the block offset is 0 (helps in catching
+ * bugs). So if we modify any field using journaling (for consistency), we
+ * will have to modify s_sum which is at offset 0. So journaling code fails.
+ * This (static+dynamic fields) is a temporary solution and can be avoided
+ * once the file system becomes stable and nova_get_block() returns correct
+ * pointers even for offset 0.
+ */
+struct nova_super_block {
+	/* static fields. they never change after file system creation.
+	 * checksum only validates up to s_start_dynamic field below
+	 */
+	__le32		s_sum;			/* checksum of this sb */
+	__le32		s_magic;		/* magic signature */
+	__le32		s_padding32;
+	__le32		s_blocksize;		/* blocksize in bytes */
+	__le64		s_size;			/* total size of fs in bytes */
+	char		s_volume_name[16];	/* volume name */
+
+	/* all the dynamic fields should go here */
+	__le64		s_epoch_id;		/* Epoch ID */
+
+	/* s_mtime and s_wtime should be together and their order should not be
+	 * changed. we use an 8 byte write to update both of them atomically
+	 */
+	__le32		s_mtime;		/* mount time */
+	__le32		s_wtime;		/* write time */
+} __attribute((__packed__));
+
+#define NOVA_SB_SIZE 512       /* must be power of two */
+
+/* ======================= Reserved blocks ========================= */
+
+/*
+ * Page 0 contains super blocks;
+ * Page 1 contains reserved inodes;
+ * Page 2 - 15 are reserved.
+ * Page 16 - 31 contain pointers to inode tables.
+ * Page 32 - 47 contain pointers to journal pages.
+ */
+#define	HEAD_RESERVED_BLOCKS	64
+#define	NUM_JOURNAL_PAGES	16
+
+#define	SUPER_BLOCK_START       0 // Superblock
+#define	RESERVE_INODE_START	1 // Reserved inodes
+#define	INODE_TABLE_START	16 // inode table pointers
+#define	JOURNAL_START		32 // journal pointer table
+
+/* For replica super block and replica reserved inodes */
+#define	TAIL_RESERVED_BLOCKS	2
+
+/* ======================= Reserved inodes ========================= */
+
+/* We have space for 31 reserved inodes */
+#define NOVA_ROOT_INO		(1)
+#define NOVA_INODETABLE_INO	(2)	/* Fake inode associated with inode
+					 * stroage.  We need this because our
+					 * allocator requires inode to be
+					 * associated with each allocation.
+					 * The data actually lives in linked
+					 * lists in INODE_TABLE_START. */
+#define NOVA_BLOCKNODE_INO	(3)     /* Storage for allocator state */
+#define NOVA_LITEJOURNAL_INO	(4)     /* Storage for lightweight journals */
+#define NOVA_INODELIST_INO	(5)     /* Storage for Inode free list */
+
+
+/* Normal inode starts at 32 */
+#define NOVA_NORMAL_INODE_START      (32)
+
+
+
+/*
+ * NOVA super-block data in DRAM
+ */
+struct nova_sb_info {
+	struct super_block *sb;			/* VFS super block */
+	struct nova_super_block *nova_sb;	/* DRAM copy of SB */
+	struct block_device *s_bdev;
+	struct dax_device *s_dax_dev;
+
+	/*
+	 * base physical and virtual address of NOVA (which is also
+	 * the pointer to the super block)
+	 */
+	phys_addr_t	phys_addr;
+	void		*virt_addr;
+	void		*replica_reserved_inodes_addr;
+	void		*replica_sb_addr;
+
+	unsigned long	num_blocks;
+
+	/* Mount options */
+	unsigned long	bpi;
+	unsigned long	blocksize;
+	unsigned long	initsize;
+	unsigned long	s_mount_opt;
+	kuid_t		uid;    /* Mount uid for root directory */
+	kgid_t		gid;    /* Mount gid for root directory */
+	umode_t		mode;   /* Mount mode for root directory */
+	atomic_t	next_generation;
+	/* inode tracking */
+	unsigned long	s_inodes_used_count;
+	unsigned long	head_reserved_blocks;
+	unsigned long	tail_reserved_blocks;
+
+	struct mutex	s_lock;	/* protects the SB's buffer-head */
+
+	int cpus;
+
+	/* Current epoch. volatile guarantees visibility */
+	volatile u64 s_epoch_id;
+
+	/* ZEROED page for cache page initialized */
+	void *zeroed_page;
+};
+
+static inline struct nova_sb_info *NOVA_SB(struct super_block *sb)
+{
+	return sb->s_fs_info;
+}
+
+static inline struct nova_super_block
+*nova_get_redund_super(struct super_block *sb)
+{
+	struct nova_sb_info *sbi = NOVA_SB(sb);
+
+	return (struct nova_super_block *)(sbi->replica_sb_addr);
+}
+
+
+/* If this is part of a read-modify-write of the super block,
+ * nova_memunlock_super() before calling!
+ */
+static inline struct nova_super_block *nova_get_super(struct super_block *sb)
+{
+	struct nova_sb_info *sbi = NOVA_SB(sb);
+
+	return (struct nova_super_block *)sbi->virt_addr;
+}
+
+extern void nova_error_mng(struct super_block *sb, const char *fmt, ...);
+
+#endif