Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 317391 Details for
Bug 454872
[NetApp 4.8 bug] online resize of filesystem does not work
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[patch]
call flush_disk after detecting an online resize
6-call-flush_disk-after-detecting-an-online-resize.patch (text/plain), 2.16 KB, created by
Jeff Moyer
on 2008-09-22 17:39:37 UTC
(
hide
)
Description:
call flush_disk after detecting an online resize
Filename:
MIME Type:
Creator:
Jeff Moyer
Created:
2008-09-22 17:39:37 UTC
Size:
2.16 KB
patch
obsolete
>Call flush_disk() after detecting an online resize. > >We call flush_disk() to make sure the buffer cache for the disk is >flushed after a disk resize. There are two resize cases, growing and >shrinking. Given that users can shrink/then grow a disk before >revalidate_disk() is called, we treat the grow case identically to >shrinking. We need to flush the buffer cache after an online shrink >because, as James Bottomley puts it, > > The two use cases for shrinking I can see are > > 1. planned: the fs is already shrunk to within the new boundaries > and all data is relocated, so invalidate is fine (any dirty > buffers that might exist in the shrunk region are there only > because they were relocated but not yet written to their > original location). > 2. unplanned: In this case, the fs is probably toast, so whether > we invalidate or not isn't going to make a whole lot of > difference; it's still going to try to read or write from > sectors beyond the new size and get I/O errors. > >Immediately invalidating shrunk disks will cause errors for outstanding >I/Os for reads/write beyond the new end of the disk to be generated >earlier then if we waited for the normal buffer cache operation. It also >removes a potential security hole where we might keep old data around >from beyond the end of the shrunk disk if the disk was not invalidated. > >diff -up linux-2.6.9/fs/block_dev.c.orig linux-2.6.9/fs/block_dev.c >--- linux-2.6.9/fs/block_dev.c.orig 2008-09-22 13:18:26.334730795 -0400 >+++ linux-2.6.9/fs/block_dev.c 2008-09-22 13:19:45.054729788 -0400 >@@ -528,8 +528,8 @@ static void flush_disk(struct block_devi > > if (bdev->bd_disk) > disk_name(bdev->bd_disk, 0, name); >- printk(KERN_WARNING "VFS: busy inodes on changed media %s\n", >- name); >+ printk(KERN_WARNING "VFS: busy inodes on changed media or " >+ "resized disk %s\n", name); > } > > if (!bdev->bd_disk) >@@ -562,6 +562,7 @@ void check_disk_size_change(struct gendi > "%s: detected capacity change from %lld to %lld\n", > name, bdev_size, disk_size); > i_size_write(bdev->bd_inode, disk_size); >+ flush_disk(bdev); > } > } > EXPORT_SYMBOL(check_disk_size_change);
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 454872
:
317386
|
317387
|
317388
|
317389
|
317390
| 317391