I'm trying to find all large files on my Centos server. To do that I'm using:

find / -maxdepth 10 -size +100000 -ls

I tried changing -ls to -lsh but it is not allowed.

How can I display these results with human-readable sizes (using suffixes k, M, …)?

  • What's your definition for human readable? For me that's human readable enough.
    – manatwork
    Apr 11, 2014 at 15:26
  • You should try file utility with find.
    – Ramesh
    Apr 11, 2014 at 15:28
  • @manatwork kb, mb, gb
    – blarg
    Apr 11, 2014 at 15:34
  • Damn, I too would have found this useful. Jun 30, 2021 at 0:55

4 Answers 4


find doesn't have sophisticated options like ls. If you want ls -h, you need to call ls.

find / -maxdepth 10 -size +100000 -exec ls -lh {} +

I recommend the -xdev option to avoid recursing into other filesystems, which would be useless if you're concerned about disk space.

find / -xdev -maxdepth 10 -size +100000 -exec ls -lh {} +

If you use zsh as your shell, then instead of using find, you can use glob qualifiers. Limiting the file size is simple: L followed by a size; the size can have an optional unit before the number. If you don't care about the maximum depth, you can use **/ to recurse into subdirectories. If you care about maximum depth, it's more cumbersome as zsh glob patterns lack a way to express “at most n occurrences”. To avoid cross-device recursion, use the d glob qualifier; you need to find the device number, which you can display with the stat command under Linux (stat -c %d / to display just the number) or with zsh's own stat builtin (run zmodload zsh/stat to load it).

ls -lh /**/*(L+M99d$(stat -c %d /))

The command you are trying is readable to me. However, you can make use of the file utility with the find as below.

find / -maxdepth 10 -size +100000 -exec sh -c 'file -b {} | grep text &>/dev/null' \; -print

Another way to do this is using the below command.

du -BM / | sort -nr

The above command will give you the files in the sorted file size.

If you are using coreutils > 7.5, you can issue the below command to list the files by sizes.

du -ah / | grep -v "/$" | sort -h

In my machine, I did not had the sort -h option available.

As you had mentioned in the comment, your human readable format is the file should have the size in kb, mb or gb. I would go with the second command that I had posted as the answer. The output that I got when I used it in my system is,

du -BM /home/ramesh/chk1/ | sort -nr

50M     /home/ramesh/chk1/
21M     /home/ramesh/chk1/Hierarchical_Clustering_Working
3M      /home/ramesh/chk1/checking_files
1M      /home/ramesh/chk1/checking/checking2
1M      /home/ramesh/chk1/checking/checking1
1M      /home/ramesh/chk1/checking/asdf
1M      /home/ramesh/chk1/checking
  • Is there a way to set a lower limit on your second command? The largest files appear at the top and quickly disappear off the top of the shell EDIT - I see you just have to remove the r
    – blarg
    Apr 11, 2014 at 15:51
  • You can redirect the output to a file by adding > output to the command. Then, you can open the file and view the output as you wish :)
    – Ramesh
    Apr 11, 2014 at 15:52
  • I see this displays folders too, whereas I'm only after files
    – blarg
    Apr 11, 2014 at 15:54
  • du -a --max-depth=10 / | sort -rn is the close I could come up with. However, in this case, it won't display the size in KB, MB or GB.
    – Ramesh
    Apr 11, 2014 at 16:19

I think what you are after is more like the following.

find / -maxdepth 10 -size +100000 -exec ls -lah {} + 

The -exec allows you to execute a command and the {} is substituted with the result of the the find. Lastly the + is to tell find it is the end of the command and it is required.

  • 2
    It is in fact completely unnecessary to quote the {} here. The single quotes in the command are for the shell but the shell is never going to see the ls -lah <args...> command at all - it sees {}, which does not need to be quoted. It is find that sees the ls -lah {} and it is find that expands the {}, and as implied by the name of the -exec option, find uses an exec* system call on the arguments directly, so there will not be any issues with spaces because find isn't going to do word-splitting on your filenames.
    – jw013
    Apr 11, 2014 at 20:36
  • 2
    The -a option to ls is unnecessary since the arguments are expected to be files and not directories. GNU find uses ls -dils for the -ls option, so to replicate that most closely it would be ls -dilsh.
    – jw013
    Apr 11, 2014 at 20:43
  • man find gives the following for the first example of using -exec: find . -type f -exec file '{}' \; Runs file on every file in or below the current directory. Notice that the braces are enclosed in single quote marks to protect them from interpretation as shell script punctuation. The semicolon is similarly protected by the use of a backslash, though single quotes could have been used in that case also.
    – Tim Hughes
    Apr 14, 2014 at 9:04
  • 1
    The man page is simply advocating some unnecessary caution. It won't hurt, but I am not aware of any shell that requires {} to be quoted.
    – jw013
    Apr 14, 2014 at 14:43

I prefer the cleaner output of du -bah over ls -hl (wish I could use du -hab for memorability but the order makes a difference):

find / -maxdepth 10 -size +100000 -exec du -bah {} + 2> /dev/null

du's -b, --bytes or --apparent-size --block-size=1 option is needed as du usually shows disk block sizes instead of exact file size.

Note that the du -b option might not exist in du on macOS systems.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .