[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191211160745.GA129186@mit.edu>
Date: Wed, 11 Dec 2019 11:07:45 -0500
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Ming Lei <ming.lei@...hat.com>
Cc: Andrea Vai <andrea.vai@...pv.it>,
"Schmid, Carsten" <Carsten_Schmid@...tor.com>,
Finn Thain <fthain@...egraphics.com.au>,
Damien Le Moal <Damien.LeMoal@....com>,
Alan Stern <stern@...land.harvard.edu>,
Jens Axboe <axboe@...nel.dk>,
Johannes Thumshirn <jthumshirn@...e.de>,
USB list <linux-usb@...r.kernel.org>,
SCSI development list <linux-scsi@...r.kernel.org>,
Himanshu Madhani <himanshu.madhani@...ium.com>,
Hannes Reinecke <hare@...e.com>,
Omar Sandoval <osandov@...com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Greg KH <gregkh@...uxfoundation.org>,
Hans Holmberg <Hans.Holmberg@....com>,
Kernel development list <linux-kernel@...r.kernel.org>,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: AW: Slow I/O on USB media after commit
f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
On Wed, Dec 11, 2019 at 12:00:58PM +0800, Ming Lei wrote:
> I didn't reproduce the issue in my test environment, and follows
> Andrea's test commands[1]:
>
> mount UUID=$uuid /mnt/pendrive 2>&1 |tee -a $logfile
> SECONDS=0
> cp $testfile /mnt/pendrive 2>&1 |tee -a $logfile
> umount /mnt/pendrive 2>&1 |tee -a $logfile
>
> The 'cp' command supposes to open/close the file just once, however
> ext4_release_file() & write pages is observed to run for 4358 times
> when executing the above 'cp' test.
Why are we sure the ext4_release_file() / _fput() is coming from the
cp command, as opposed to something else that might be running on the
system under test? _fput() is called by the kernel when the last
reference to a struct file is released. (Specifically, if you have a
fd which is dup'ed, it's only when the last fd corresponding to the
struct file is closed, and the struct file is about to be released,
does the file system's f_ops->release function get called.)
So the first question I'd ask is whether there is anything else going
on the system, and whether the writes are happening to the USB thumb
drive, or to some other storage device. And if there is something
else which is writing to the pendrive, maybe that's why no one else
has been able to reproduce the OP's complaint....
- Ted
Powered by blists - more mailing lists