public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Wang Yugui <wangyugui@e16-tech.com>
Cc: Carlos Maiolino <cem@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	linux-xfs@vger.kernel.org
Subject: Re: questions about hybird xfs wih ssd/hdd  by realtime subvol
Date: Mon, 29 Aug 2022 19:28:11 -0700	[thread overview]
Message-ID: <Yw11u/2ghadMfLMd@magnolia> (raw)
In-Reply-To: <20220830085718.9391.409509F4@e16-tech.com>

On Tue, Aug 30, 2022 at 08:57:21AM +0800, Wang Yugui wrote:
> Hi,
> 
> > On Mon, Aug 29, 2022 at 10:26:20AM +0800, Wang Yugui wrote:
> > > Hi,
> > > 
> > > I saw some info about hybird xfs wih ssd/hdd  by realtime subvol.
> > > 
> > > Hybrid XFS—Using SSDs to Supercharge HDDs at Facebook
> > > https://www.usenix.org/conference/srecon19asia/presentation/shamasunder
> > > 
> > > There are some questions about how to control the data to save into
> > > normal vol or realtime subvol firstly.
> > > 
> > > 1, man xfsctl
> > > here is XFS_XFLAG_REALTIME in man xfsctl of xfsprogs 5.0 ,
> > > but there is no XFS_XFLAG_REALTIME in xfsprogs 5.14/5.19.
> > > xfsctl(XFS_XFLAG_REALTIME) will be removed in the further?
> > 
> > It's been a while since XFS uses FS_XFLAG features directly, so, what you're
> > specifically looking for is FS_XFLAG_REALTIME. xfsprogs today only has a
> > preprocessor define:
> > 
> > #define XFS_XFLAG_REALTIME	FS_XFLAG_REALTIME
> > 
> > FS_XFLAG_REALTIME is part of the xfs realtime, unlikely it's going away without
> > the realtime filesystems going first, so, unlikely it's gonna happen.
> > 
> > > 
> > > 2, Is there some tool to do xfsctl(XFS_XFLAG_REALTIME)?
> > 
> > You can use xfs_io's chattr command to add/remote the REALTIME attribute of a
> > file.
> > 
> > 
> > > 
> > > 3, we build a xfs filesystem with 1G device and 1G rtdev device. and
> > > then we can save 2G data into this xfs filesystem.
> 
> Sorry, I cheched again.
> This is a xfs filesystem with 2G device and 2G rtdev device
> 
> > > Is there any tool/kernel option/kernel patch to control the data to save
> > > into normal vol or realtime subvol firstly?
> > 
> > I didn't watch the talk you mentioned above, but when use an rt device, you
> > don't use the 'normal' one then the rt later, or vice-versa, the rt-device is
> > used to store data blocks for those files marked with the xattr above. For those
> > files you want to store in the realtime device, you should add the above xattr
> > to them.
> 
> Although I still fail to check/set the attr by 'lsattr/chattr', but I
> can check the free space of 'normal' and realtime subvol now.
> 
> # xfs_db -c sb -c p /dev/sdb8 |grep 'fdblocks\|frextents'
> typedef struct xfs_sb {
> ...
> 	uint64_t	sb_fdblocks;	/* free data blocks */
> 	uint64_t	sb_frextents;	/* free realtime extents */
> ...
> }
> 
> And based the info from Carlos Maiolino
> 
> FB were running a modified kernel that selected the rt dev based on
> the initial allocation size. Behaviour for them was predictable
> because they also controlled the application that was storing the
> data. See:
> 
> https://lore.kernel.org/linux-xfs/20171128215527.2510350-1-rwareing@fb.com/
> 
> With a dirty patch below for test only , Now realtime subvol will be used
> as I expected, and that can be confirmed by
> #xfs_db -c sb -c p /dev/sdb8 |grep 'fdblocks\|frextents'.

mkfs.xfs -d rtinherit=1...

--D

> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> index f4cc8a1aaeb4..d19e0fa34c1a 100644
> --- a/fs/xfs/xfs_inode.c
> +++ b/fs/xfs/xfs_inode.c
> @@ -868,6 +868,9 @@ xfs_init_new_inode(
>                 flags |= XFS_ILOG_DEV;
>                 break;
>         case S_IFREG:
> +               if (xfs_has_realtime(ip->i_mount))
> +                       ip->i_diflags |= XFS_DIFLAG_REALTIME;
> +               fallthrough;
>         case S_IFDIR:
>                 if (pip && (pip->i_diflags & XFS_DIFLAG_ANY))
>                         xfs_inode_inherit_flags(ip, pip);
> 
> Thanks a lot.
> 
> Best Regards
> Wang Yugui (wangyugui@e16-tech.com)
> 2022/08/30
> 

  reply	other threads:[~2022-08-30  2:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cra8LsdEma_cTwegy_oY4sLK9oYZOVv-VzyNw2y5Azvj_cPt5Fx3AyINvXKkQFhNXwB6-xMP4wVI67KS0eru1w==@protonmail.internalid>
2022-08-29  2:26 ` questions about hybird xfs wih ssd/hdd by realtime subvol Wang Yugui
2022-08-29  8:24   ` Carlos Maiolino
2022-08-30  0:57     ` Wang Yugui
2022-08-30  2:28       ` Darrick J. Wong [this message]
2022-08-31  0:50         ` Wang Yugui
2022-08-31  1:20           ` Darrick J. Wong
2022-08-29 22:10   ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yw11u/2ghadMfLMd@magnolia \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=wangyugui@e16-tech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox