Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1614614
| From | Dave Chinner <david@fromorbit.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization |
| Date | 2017-04-02 01:10 +0200 |
| Message-ID | <trAjE-Kq-3@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <tqjNT-63S-7@gated-at.bofh.it> <tqq30-1Wd-27@gated-at.bofh.it> <tqC49-2hn-9@gated-at.bofh.it> <tqGhs-5vQ-15@gated-at.bofh.it> <tqKXN-ry-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Mar 30, 2017 at 12:12:31PM -0400, J. Bruce Fields wrote: > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote: > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote: > > > Because if above is acceptable we could make reported i_version to be a sum > > > of "superblock crash counter" and "inode i_version". We increment > > > "superblock crash counter" whenever we detect unclean filesystem shutdown. > > > That way after a crash we are guaranteed each inode will report new > > > i_version (the sum would probably have to look like "superblock crash > > > counter" * 65536 + "inode i_version" so that we avoid reusing possible > > > i_version numbers we gave away but did not write to disk but still...). > > > Thoughts? > > How hard is this for filesystems to support? Do they need an on-disk > format change to keep track of the crash counter? Yes. We'll need version counter in the superblock, and we'll need to know what the increment semantics are. The big question is how do we know there was a crash? The only thing a journalling filesystem knows at mount time is whether it is clean or requires recovery. Filesystems can require recovery for many reasons that don't involve a crash (e.g. root fs is never unmounted cleanly, so always requires recovery). Further, some filesystems may not even know there was a crash at mount time because their architecture always leaves a consistent filesystem on disk (e.g. COW filesystems).... > I wonder if repeated crashes can lead to any odd corner cases. WIthout defined, locked down behavour of the superblock counter, the almost certainly corner cases will exist... Cheers, Dave. -- Dave Chinner david@fromorbit.com
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jan Kara <jack@suse.cz> - 2017-03-29 13:20 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jeff Layton <jlayton@redhat.com> - 2017-03-29 20:00 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Dave Chinner <david@fromorbit.com> - 2017-03-30 01:50 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jeff Layton <jlayton@redhat.com> - 2017-03-30 13:30 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-04-04 20:40 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jan Kara <jack@suse.cz> - 2017-03-30 08:50 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jeff Layton <jlayton@redhat.com> - 2017-03-30 13:20 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-03-30 18:20 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jeff Layton <jlayton@redhat.com> - 2017-03-30 20:40 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Boaz Harrosh <openosd@gmail.com> - 2017-03-30 23:20 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-04-04 20:40 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization NeilBrown <neil@brown.name> - 2017-04-05 03:50 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jan Kara <jack@suse.cz> - 2017-04-05 10:10 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-04-05 20:20 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization NeilBrown <neil@brown.name> - 2017-04-06 03:20 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jan Kara <jack@suse.cz> - 2017-04-06 09:30 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-04-05 19:50 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Dave Chinner <david@fromorbit.com> - 2017-04-02 01:10 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Jan Kara <jack@suse.cz> - 2017-04-03 16:10 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Dave Chinner <david@fromorbit.com> - 2017-04-04 14:40 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-04-04 20:00 +0200
Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization NeilBrown <neil@brown.name> - 2017-04-05 03:30 +0200
csiph-web