From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/ioctl_loop05: Get the logic_block_size dynamically
Date: Tue, 9 Jun 2020 06:16:42 -0400 (EDT) [thread overview]
Message-ID: <1837993622.15296660.1591697802060.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <b1a7a025-3875-86db-222d-5a1e40737b24@cn.fujitsu.com>
----- Original Message -----
> Hi Jan
>
> >
> > ----- Original Message -----
> >> In loop driver code, the sb_bsize was calculated as below
> >> sb_bsize = bdev_logical_block_size(inode->i_sb->s_bdev),
> >>
> >> it is the super block's block size that the backing file's inode belongs
> >> to,
> >> not by using the st_blksize member of stat struct(it uses
> >> inode->i_blkbits).
> > I'm not sure I follow the above, are you saying the difference is bdev
> > blksize
> > vs. filesystem blksize?
>
> I said the loop driver used dev_logical_block_size(inode->i_sb->s_bdev) but
> not using
> st_blksize.
I know, but I'm trying to understand what the difference is between those two.
> > Would BLKSSZGET work? It returns bdev_logical_block_size().
>
> But it needs a blockdev, in user space, we can specify bdev, but how can we
> figure out this inode->i_sb->s_bdev block dev.
Isn't that the block device "test.img" is on?
next prev parent reply other threads:[~2020-06-09 10:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-09 8:33 [LTP] [PATCH] syscalls/ioctl_loop05: Get the logic_block_size dynamically Yang Xu
2020-06-09 9:24 ` Jan Stancek
2020-06-09 9:48 ` Yang Xu
2020-06-09 10:16 ` Jan Stancek [this message]
2020-06-09 10:46 ` Yang Xu
2020-06-09 11:01 ` Jan Stancek
2020-06-10 1:19 ` Yang Xu
2020-06-10 5:37 ` [LTP] [PATCH v2] syscalls/ioctl_loop05: Use correct blockdev to get logical_block_size Yang Xu
2020-06-10 10:13 ` Jan Stancek
2020-06-10 10:42 ` Yang Xu
2020-06-10 12:19 ` Yang Xu
2020-06-10 13:04 ` Jan Stancek
2020-06-11 4:56 ` Yang Xu
2020-06-11 5:32 ` [LTP] [PATCH v3] " Yang Xu
2020-06-11 11:09 ` Jan Stancek
2020-06-12 2:57 ` Yang Xu
2020-06-24 5:07 ` Yang Xu
2020-06-24 11:32 ` Cyril Hrubis
2020-06-24 13:06 ` Jan Stancek
2020-06-25 17:10 ` Yang Xu
2020-06-28 7:42 ` [LTP] [PATCH v4 1/2] tst_device: Add new api tst_find_backing_dev(path, dev) Yang Xu
2020-06-28 7:42 ` [LTP] [PATCH v4 2/2] syscalls/ioctl_loop05: Use correct blockdev to get logical_block_size Yang Xu
2020-06-29 7:56 ` [LTP] [PATCH v4 1/2] tst_device: Add new api tst_find_backing_dev(path, dev) Jan Stancek
2020-06-29 10:37 ` Yang Xu
2020-06-29 11:08 ` Jan Stancek
2020-06-29 11:41 ` [LTP] [PATCH v5 " Yang Xu
2020-06-29 11:41 ` [LTP] [PATCH v5 2/2] syscalls/ioctl_loop05: Use correct blockdev to get logical_block_size Yang Xu
2020-07-02 9:18 ` [LTP] [PATCH v5 1/2] tst_device: Add new api tst_find_backing_dev(path, dev) Jan Stancek
2020-07-02 12:27 ` Cyril Hrubis
2020-07-02 13:17 ` Jan Stancek
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=1837993622.15296660.1591697802060.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=ltp@lists.linux.it \
/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