linux project dir with many (15k) files un-guard-able

[eps]

I'm using guard with rspec and spork in a on ubuntu 12.04, rails
3.2.3, ruby 1.9.3

I have a directory in public/ in the rails project directory with
around 15,000 files in it. When I fire up guard, the disk gets
thrashed to the point where the workstation is effectively unusable.
I *have* added ignore_paths 'public' to the Guardfile, which makes no
difference.

Guard works fine with this project on other developers' MacOS
workstations, this disk-grinding only seems to happen on Linux.

I have bumped up max_user_watches:

$ cat /proc/sys/fs/inotify/max_user_watches
65536

I've tried moving the dir containing the 15k files out of the project
dir, and then symlinking to it; this doesn't fix the problem.

-----------------------------------------
Relevant snippet of Gemfile:
-----------------------------------------
group :development, :test do
gem 'thin'
gem 'rspec-rails'
gem 'capybara'
gem 'fuubar'
gem 'nifty-generators'
gem 'nokogiri'
gem 'sqlite3'
gem 'rails_best_practices'
gem 'rb-fsevent'
gem 'guard-rspec'
end

--------------
Guardfile:
--------------


# -*- ruby -
*-
# A sample
Guardfile
# More info at https://github.com/guard/guard#readme

ignore_paths 'public'

# NOTE: spork section needs to come
first.
guard 'spork', :rspec_env => { 'RAILS_ENV' => 'test' } do
watch('config/application.rb')
watch('config/environment.rb')
watch(%r{^config/environments/.+\.rb$})
watch(%r{^config/initializers/.+\.rb$})
watch('Gemfile')
watch('Gemfile.lock')
watch('spec/factories.rb')
watch('spec/spec_helper.rb') { :rspec }
watch(%r{^app/(.+)\.rb$})
end

guard 'rspec', :version => 2, :cli => "--drb", :all_on_start =>
false, :all_after_pass => false do
watch(%r{^spec/.+_spec\.rb$})
watch(%r{^lib/(.+)\.rb$}) { |m| "spec/lib/#{m[1]}_spec.rb" }
watch('spec/spec_helper.rb') { "spec" }

# Rails
example
watch(%r{^app/(.+)\.rb$}) { |m| "spec/
#{m[1]}_spec.rb" }
watch(%r{^app/(.*)(\.erb|\.haml)$}) { |m| "spec/
#{m[1]}#{m[2]}_spec.rb" }
watch(%r{^app/controllers/(.+)_(controller)\.rb$}) { |m| ["spec/
routing/#{m[1]}_routing_spec.rb",
"spec/
#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb",
"spec/
acceptance/#{m[1]}_spec.rb"] }
watch('spec/factories.rb') { "spec" }
watch('config/routes.rb') { "spec/
routing" }
watch('app/controllers/application_controller.rb') { "spec/
controllers" }

# Request
specs
watch(%r{^app/views/(.+)/}) { |m| "spec/requests/#{m[1]}
_request_spec.rb" }
end

[Thibaud Guillaume-Gentil]

Maybe 65536 isn't enough, we have a good wiki page about that: https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers

You can also give a try to Guard 1.1.0.beta that use the Listen gem.

[eps]

I guess I should have been clearer; I don't need or want to watch any
of the 15k files that guard is thrashing. I want to ignore them; I
want to eliminate the disk activity that is slowing down the system.

Moving the dir with the 15k files in it (without symlinking back)
accomplishes this, but I do need those files in place in the project
to do development work. I just don't need (or want) guard to watch
(or even seek/stat) them for rspec testing.

I am not experiencing the resource allocation problem ("user limit on
the total number of inotify watches was reached") that I encountered
prior to increasing max_user_watches.

I thought ignore_paths would do what I want, but it doesn't seem to
help.


On May 25, 12:11 am, Thibaud Guillaume-Gentil <thib...@thibaud.me>
wrote:
> Maybe 65536 isn't enough, we have a good wiki page about that:https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify...

> > # More info athttps://github.com/guard/guard#readme

[Rémy Coutable]

Hi,

Could you give a try to Guard 1.1.0.beta [http://rubygems.org/gems/guard/versions/1.1.0.beta], it uses the new Listen gem.

Thanks for letting us know if that works better.

Regards,
Rémy

[eps]

I have upgraded to 1.1.0-beta and I am seeing the same runaway disk-
access behavior.

rspec ~> 2.10.0, rails-rspec ~> 2.10.0, guard-rspec ~> 0.7.0

The workstation is perhaps slightly more responsive while the disk is
thrashing, but guard is still pounding the heck out of it.

I've changed:

ignore_paths 'public'
to
ignore 'public'

but that might not be correct? Neither one prevents the disk from
thrashing. Is there any documentation yet for the new 'ignore' and
'filter' methods mentioned in the ignore_paths deprecation warning?

[Abe Kinney]

how do i get off the mailing list?

[Thibaud Guillaume-Gentil]

@abe just leave the guard-dev google group

[Thibaud Guillaume-Gentil]

the ignore method is the same that Listen gem and you need to provide a regex. ignore 'public' shouldn't work.

https://github.com/guard/listen#the-patterns-for-filtering-and-ignoring-paths

[eps]

I have tried the following, without success:

ignore %r{public/}
ignore '%r{public/}'
ignore %r{public}
ignore %r{.*public.*}


The Guardfile DSL, of course, does not understand the key-value hash
syntax one would employ when using the Listen gem directly, so my
guesses look a little different from the documented syntax.

Is guard not converting the string it gets from the Guardfile into a
regex (via eval, presumably)?

Once I do get basic functionality working, what is the correct way to
match the project root in the regex? i.e., should I use
'%r{^public/}', '%r{^./public/}', '%r{^/home/user/Projects/
some_project/public}' or...?



On May 25, 11:40 am, Thibaud Guillaume-Gentil <thib...@thibaud.me>
wrote:

> the ignore method is the same that Listen gem and you need to provide a regex. ignore 'public' shouldn't work.
>

> https://github.com/guard/listen#the-patterns-for-filtering-and-ignori...

[Thibaud Guillaume-Gentil]

Like describe in https://github.com/guard/listen#the-patterns-for-filtering-and-ignoring-paths

ignore %r{public/}

should work fine, have you also try:

ignore /build\//