On Nov 25, 2019 / 15:37, Chao Yu wrote:
> On 2019/11/14 16:19, Shin'ichiro Kawasaki wrote:
> > To catch f2fs bugs in write pointer handling code for zoned block
> > devices, check write pointers of non-open zones that current segments do
> > not point to. Do this check at mount time, after the fsyn
On Nov 25, 2019 / 14:59, Chao Yu wrote:
> On 2019/11/14 16:19, Shin'ichiro Kawasaki wrote:
> > On sudden f2fs shutdown, write pointers of zoned block devices can go
> > further but f2fs meta data keeps current segments at positions before the
> > write operations. After remounting the f2fs, this in
On Nov 26, 2019 / 15:44, Jaegeuk Kim wrote:
> On 11/26, Damien Le Moal wrote:
> > f2fs_preallocate_blocks() identifies direct IOs using the IOCB_DIRECT
> > flag for a kiocb structure. However, the file system direct IO handler
> > function f2fs_direct_IO() may have decided that a direct IO has to b
On 2019/11/26 17:34, Ritesh Harjani wrote:
> Hello Damien,
>
> IIUC, you are trying to fix a stale data read by DIO read for the case
> you explained in your patch w.r.t. DIO-write forced to write as buffIO.
>
> Coincidentally I was just looking at the same code path just now.
> So I do have a qu
Hi Linus,
Could you please consider this pull request?
The following changes since commit b145b0eb2031a620ca010174240963e4d2c6ce26:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
(2019-10-04 11:17:51 -0700)
are available in the Git repository at:
git://git.kernel.org/p
On 11/27/19 10:18 AM, Jaegeuk Kim wrote:
Previously, there was a bug where user could see stale buffer cache (e.g, 512B)
attached in the 4KB-sized pager cache, when the block size was changed from
512B to 4KB. That was fixed by:
commit 5db470e229e2 ("loop: drop caches if offset or block_size are
Hi,
On 11/27, Stephanos Mallouris wrote:
> Dear Kim ,
>
> Regarding the question:
>
> "Hmm, # of valid blocks is 0, which is really impossible.
> Do you have original backed up image? I think at some point the image
> was overwritten when fsck.f2fs tried to fix.
> "
>
> I do have the origina
Previously, there was a bug where user could see stale buffer cache (e.g, 512B)
attached in the 4KB-sized pager cache, when the block size was changed from
512B to 4KB. That was fixed by:
commit 5db470e229e2 ("loop: drop caches if offset or block_size are changed")
But, there were some regression
On Wed, Nov 27, 2019 at 04:18:11PM +0100, Andreas Gruenbacher wrote:
> Fix a check in block_page_mkwrite meant to determine whether an offset
> is within the inode size. This error has spread to several filesystems
> and to iomap_page_mkwrite, so fix those instances as well.
Seeing how this has g
Fix a check in block_page_mkwrite meant to determine whether an offset
is within the inode size. This error has spread to several filesystems
and to iomap_page_mkwrite, so fix those instances as well.
Signed-off-by: Andreas Gruenbacher
---
This patch has a trivial conflict with commit "iomap:
Dear Kim ,
Regarding the question:
"Hmm, # of valid blocks is 0, which is really impossible.
Do you have original backed up image? I think at some point the image
was overwritten when fsck.f2fs tried to fix.
"
I do have the original dump raw image. Please advice actions
to assist in recoverin
11 matches
Mail list logo
