[PATCH v5 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed

2018-01-09 Thread Jeff Layton
From: Jeff Layton At this point, we know that "now" and the file times may differ, and we suspect that the i_version has been flagged to be bumped. Attempt to bump the i_version, and only mark the inode dirty if that actually occurred or if one of the times was updated.

[PATCH v5 16/19] fs: only set S_VERSION when updating times if necessary

2018-01-09 Thread Jeff Layton
From: Jeff Layton We only really need to update i_version if someone has queried for it since we last incremented it. By doing that, we can avoid having to update the inode if the times haven't changed. If the times have changed, then we go ahead and forcibly increment the

[PATCH 6/6] btrfs: cleanup to make btrfs_free_stale_device() readable

2018-01-09 Thread Anand Jain
From: Anand Jain Now as the there is path in arg, so instead of reading the path from cur_device just get it from the caller, and so the purpose of cur_device is to skip the device, so rename it to skip_dev. Also drop the comment about different path being used for the

[PATCH v5 19/19] fs: handle inode->i_version more efficiently

2018-01-09 Thread Jeff Layton
From: Jeff Layton Since i_version is mostly treated as an opaque value, we can exploit that fact to avoid incrementing it when no one is watching. With that change, we can avoid incrementing the counter on writes, unless someone has queried for it since it was last

[PATCH 2/6] btrfs: no need to check for btrfs_fs_devices::seeding

2018-01-09 Thread Anand Jain
There is no need to check for btrfs_fs_devices::seeding when we have checked for btrfs_fs_devices::opened, because we can't sprout without its seed FS being opened. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH RESEND v3 0/6] preparatory work to add device forget

2018-01-09 Thread Anand Jain
v2->v3: @ 6/6: add btrfs_free_stale_device() fn description, suggested by Nikolay Fix line with longer than 80 char v1->v2: @ 6/6: btrfs_device::name is null when we have missing device and unmounted. So we still need to check for dev->name. We can reuse the function

Re: Recommendations for balancing as part of regular maintenance?

2018-01-09 Thread Austin S. Hemmelgarn
On 2018-01-09 03:33, Marat Khalili wrote: On 08/01/18 19:34, Austin S. Hemmelgarn wrote: A: While not strictly necessary, running regular filtered balances (for example `btrfs balance start -dusage=50 -dlimit=2 -musage=50 -mlimit=4`, see `man btrfs-balance` for more info on what the options

Re: Recommendations for balancing as part of regular maintenance?

2018-01-09 Thread Austin S. Hemmelgarn
On 2018-01-08 16:43, Tom Worster wrote: On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: On 2018-01-08 11:20, ein wrote: > On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: > > > [...] > > > > And here's the FAQ entry: > > > > Q: Do I need to run a balance regularly? > > > > A: In

Re: [PATCH 0/4] Btrfs: just bunch of patches to ioctl.c

2018-01-09 Thread Timofey Titovets
Gentle ping 2017-12-19 13:02 GMT+03:00 Timofey Titovets : > 1st patch, remove 16MiB restriction from extent_same ioctl(), > by doing iterations over passed range. > > I did not see much difference in performance, so it's just remove > logic restriction. > > 2-3 pathes,

Re: [Bug-tar] [PATCH] Re: Detection of sparse files is broken on btrfs

2018-01-09 Thread Joerg Schilling
Pavel Raiskup wrote: > On Tuesday, January 9, 2018 8:59:06 AM CET Paul Eggert wrote: > > Pavel Raiskup wrote: > > > So what about special casing that filesystem, where we can lseek() for > > > holes anyway? > > > > If we can lseek for holes, then why not just do that? > >

Re: [Bug-tar] [PATCH] Re: Detection of sparse files is broken on btrfs

2018-01-09 Thread Joerg Schilling
Paul Eggert wrote: > If we can lseek for holes, then why not just do that? We shouldn't need > special-case code for btrfs per se. Any filesystem where we can lseek for > holes > should take advantage of that optimization. This is what star uses since 13 years ;-) Jörg

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

2018-01-09 Thread Krzysztof Kozlowski
On Mon, Jan 8, 2018 at 10:39 PM, Jeff Layton wrote: >> > > Got it, that's helpful. Does this patch help (on top of the others) ? > > 8<-- > > SQUASH: nfs: compare raw iversion counter since that's what's > being stored > Did

Re: Recommendations for balancing as part of regular maintenance?

2018-01-09 Thread Marat Khalili
On 08/01/18 19:34, Austin S. Hemmelgarn wrote: A: While not strictly necessary, running regular filtered balances (for example `btrfs balance start -dusage=50 -dlimit=2 -musage=50 -mlimit=4`, see `man btrfs-balance` for more info on what the options mean) can help keep a volume healthy by

Re: [Bug-tar] [PATCH] Re: Detection of sparse files is broken on btrfs

2018-01-09 Thread Pavel Raiskup
On Tuesday, January 9, 2018 8:59:06 AM CET Paul Eggert wrote: > Pavel Raiskup wrote: > > So what about special casing that filesystem, where we can lseek() for > > holes anyway? > > If we can lseek for holes, then why not just do that? Checking whether lseek() actually works costs some

Re: [Bug-tar] [PATCH] Re: Detection of sparse files is broken on btrfs

2018-01-09 Thread Paul Eggert
Pavel Raiskup wrote: So what about special casing that filesystem, where we can lseek() for holes anyway? If we can lseek for holes, then why not just do that? We shouldn't need special-case code for btrfs per se. Any filesystem where we can lseek for holes should take advantage of that

<    1   2