Thread (13 messages) 13 messages, 4 authors, 2017-01-05

Re: [PATCH] recursive defrag cleanup

From: Anand Jain <hidden>
Date: 2017-01-03 10:12:25


  Thanks for the comments.

  We are in the midst of making defrag better. For now, -r option picks
  up files of the dir specified, there is no way to defrag all subvol
  tree with out scripting, something like this.

  If /mnt is mounted with subvolid=5 (default).
  for all s subvol in /mnt
  do
	btrfs fi defrag /mnt/$s
  done
  btrfs fi defrag /mnt
  btrfs fi defrag -vr /mnt (file defrag)
In my personal experience Btrfs filesystems tend to get slower over
time, up to the point where it takes several minutes to mount them or
to delete some big files (observed on HDDs, not on SSDs where the
sheer speed might masks the problem and filesystem tends to be smaller
anyway). When it gets really bad, Gentoo's localmount script starts to
time out on boot and Samba based network file deletions tend to freeze
the client Windows machine's file explorer.
It only takes 3-6 months and/or roughly 10-20 times of the total
disk(s) capacity's worth of write load to get there.
  IMO. The solution has to be reviewed against the use case here,
  and certainly it takes a lot of time.

  In some cases the access pattern for write may be different
  from accessed for read-only. Need to understand the context in
  which the the access leads to the timeout. And then tuning
  might help.

Defrag doesn't
seem to help with that but running a balance on each and every
metadata blocks (data and system blocks can be skipped) seems to
"renew" it (no more timeouts or noticeable delays on mount, metadata
operation are as fast as expected, it works like a young
filesystem...).
  Whats the defrag command you found didn't help but the above
  balance command helped ?

Thanks Anand
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help