GNU bug report logs - #45887
buffer cache flushed after excute 'parted -s print' command

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45887 in the body.
You can then email your comments to 45887 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hyun Ha <hfamily15 <at> gmail.com>
To: bug-parted <at> gnu.org
Subject: buffer cache flushed after excute 'parted -s print' command
Date: Fri, 15 Jan 2021 12:32:42 +0900

[Message part 1 (text/plain, inline)]

Hi,
I have a strange issue with parted.
After execute parted command, buffer cache flushed and I don't know why.
I have nvme device to set bcache and HDD device for backing block device of
bcache and writeback mode.

System informations:
 - OS: CentOS Linux release 7.4.1708 (Core)
 - Kernel version: 4.18.16-1.el7.elrepo.x86_64
 - parted version: parted (GNU parted) 3.1

Reproduce:
 - create nvme partition
 - make bcache
 - execute parted command

Test:
$ free ; parted /dev/nvme0n1p10 -s print;free
              total        used        free      shared  buff/cache
available
Mem:      131463788    27276308    74617372        3064    29570108
102167828
Swap:       4194300           0     4194300
Error: /dev/nvme0n1p10: unrecognised disk label
Model: Unknown (unknown)
Disk /dev/nvme0n1p10: 50.0GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
              total        used        free      shared  buff/cache
available
Mem:      131463788    27276784    75484216        3064    28702788
102167836
Swap:       4194300           0     4194300

$ free ; parted /dev/nvme0n1p11 -s print;free
              total        used        free      shared  buff/cache
available
Mem:      131463788    27324028    75436544        3128    28703216
102119460
Swap:       4194300           0     4194300
Error: /dev/nvme0n1p11: unrecognised disk label
Model: Unknown (unknown)
Disk /dev/nvme0n1p11: 50.0GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
              total        used        free      shared  buff/cache
available
Mem:      131463788    27321968    76610612        3128    27531208
102121764
Swap:       4194300           0     4194300

gdisk and fdisk does not flush buffer cache with execute command.
Is this a bug or normal?
thank you in advance.

[Message part 2 (text/html, inline)]

Message #10 received at 45887-close <at> debbugs.gnu.org (full text, mbox):

From: "Brian C. Lane" <bcl <at> redhat.com>
To: 45887-close <at> debbugs.gnu.org
Subject: Re: bug#45887: buffer cache flushed after excute 'parted -s print'
 command
Date: Fri, 15 Jan 2021 09:37:59 -0800

On Fri, Jan 15, 2021 at 12:32:42PM +0900, Hyun Ha wrote:
> Hi,
> I have a strange issue with parted.
> After execute parted command, buffer cache flushed and I don't know why.
> I have nvme device to set bcache and HDD device for backing block device of
> bcache and writeback mode.

Yes, parted calls fsync when it is done with the device. It always opens
the device in RW mode and always fsync's it when closing it to make sure
any changes make it to disk.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

Message #13 received at 45887 <at> debbugs.gnu.org (full text, mbox):

From: Hyun Ha <hfamily15 <at> gmail.com>
To: 45887 <at> debbugs.gnu.org
Date: Tue, 19 Jan 2021 11:13:38 +0900

[Message part 1 (text/plain, inline)]

Thanks a lot for reply.

I think it make sense calling fsync when parted is done with device.
but I'm confusing because buffer cache was flushed with 'print' command in
parted also.

I think 'parted [device partitoin] -s print'  is just for getting
information about device, not for making any changes to device.

Is this also normal?

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.