Red Hat Bugzilla – Bug 436752
editing using VIM on USB stick causes editor to hang frequently
Last modified: 2008-03-11 12:22:32 EDT
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@redhat.com> Compiled by <bugzilla@redhat.com> 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:
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.
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
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.
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