Bug 436752 - editing using VIM on USB stick causes editor to hang frequently
Summary: editing using VIM on USB stick causes editor to hang frequently
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: vim
Version: 7
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-10 08:56 UTC by John Pye
Modified: 2008-03-11 16:22 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-03-11 16:22:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description John Pye 2008-03-10 08:56:50 UTC
Description of problem:
I am using vim to edit files on a USB stick (my little sneakernet when I'm away
from the net). Every so often (perhaps every minute or two?) VIM hangs and won't
respond for about 15-20 seconds. During this time my panel applet indicates that
the CPU is doing a lot of I/O waiting.

Version-Release number of selected component (if applicable):
[john@jdpipe ascend]$ vim --version
VIM - Vi IMproved 7.1 (2007 May 12, compiled Jan  9 2008 08:28:18)
Included patches: 1-211
Modified by <bugzilla>
Compiled by <bugzilla>
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent 
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic 
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path 
+folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist
 +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu 
+mksession +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm 
-mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme 
-netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile 
+python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent 
-sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static 
-tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar 
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace 
+wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp 
-xterm_clipboard -xterm_save 
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2    -D_REENTRANT -D_GNU_SOURCE  
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm  -I/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE 
-I/usr/include/python2.5 -pthread   
Linking: gcc   -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE   -L/usr/local/lib
-o vim       -lselinux  -lncurses -lacl -lgpm   -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE  -L/usr/local/lib
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -lperl -lresolv -lutil -lc
-L/usr/lib/python2.5/config -lpython2.5 -lutil -lm -Xlinker -export-dynamic    



How reproducible:
Always. Seems to also occur using Ubuntu, so this might be an upstream bug.

Steps to Reproduce:
1. open a file on your USB stick using vim
2. just keep on editing it for a while
  
Actual results:
Every so often VIM locks up and my CPU monitor shows that the CPU is waiting for
I/O.

Expected results:
If VIM's got to do background writes (backup files, I present) then it should
perhaps being doing them in a background thread or something like that? Or
perhaps it could be made to be sensitive to the fact that it's writing to a
medium that shouldn't be flushed frequently because it's slow. I'm guessing.

Additional info:

Comment 1 Karsten Hopp 2008-03-10 12:34:45 UTC
vim is writing a swap file with your changes to the directory containing the
edited file. You can force vim to write the swap file to p.e. /tmp by the vim
command
   set dir=/tmp           (or better 'set dir=~/tmp')
Unfortunately there's no way how vim could detect the kind of media and change
the directory setting based on that.

btw:
This looks more like a kernel/USB problem as you're probably not editing very
large files. Please make sure you have the latest update kernel installed and
running.


Comment 2 John Pye 2008-03-11 01:03:28 UTC
Hi Karsten,

Do you have reason to think that recent kernel changes have fixed this? I see
this problem both on Fedora 7 and Ubuntu 7.10. If that's the case then perhaps
that's where I need to report the error.

On the other hand something that VIM could implement might for example be a
blacklist of folders (in a configuration file somewhere) that are not to be used
for swap files. This would be useful also for example when using FUSE to access
remote filesystems, for example.

I reopened this just to make sure you see it (did I need to do that?). Close it
again if none of these comments change anything :-)


Cheers
JP


Comment 3 Karsten Hopp 2008-03-11 11:12:19 UTC
I get a notification mail when you add a comment, it doesn't matter if you
change the bugzilla state. 
USB is getting improvements in the kernel all the time, there wasn't any special
reason to think that this issue has been fixed in a recent release, but chances
are good that that'll be the case.
Blacklisting p.e. /mnt and /media might be an improvement, but it obviously
doesn't work when someone mounts the USB stick to a different location.
I think I'll try that as it at least fixes this issue for most common cases.

Comment 4 Karsten Hopp 2008-03-11 16:22:32 UTC
please try vim 7.1.270 when it shows up on your preferred mirror. It has an
autocmd which set the swap file location differently for files in /media and /mnt


Note You need to log in before you can comment on or make changes to this bug.