По моему, он проверят только метадату. (Я почти уверен).
Но в как бы то ни было — последовательный скан — это не тот юзкейс, под который надо оптимизировать. Это очень низкоприоритетная, и, к тому же крайне редкая, задача. Что надо оптимизировать — это случайное чтение нескольких, из миллионов маленьких, <4к файлов, раскиданных по терабайтовому полю. Современные файловые системы с этим справляются отлично: добавлением еще одного уровня абстракции можно только все замедлить, (метадата уже в кеше а файлы нет; лезть внутрь файла чтоб выковырять кусочки просто добавит лишнее IO) но ни как не ускорить: если бы был способ это ускорить хитрыми структурами данных — это было бы уже сделано, в рамках существующей программы, под названием «файловая система» 
Edit (расставил кучу запятых…)
Люди которые жалуются на скорость filewalker на самом деле не видят леса за деревьями: медленный файлвокер это не причина, а симптом. Симптом того, что метадата не помещается в свободную память. А это значит, что время до первого байта включает в себя десятки миллисекунд задержки чтения жесткого диска каждый раз клиент запрашиват файл, и в результате увеличенная вероятность проиграть гонку за первые 29 кусочков другой ноде, которая закешировала метадату (где лежат все куски) в рам и начинает посылать нужный кусочек со значительно меньшей задержкой.
Вот буквально недавно то же самое обсуждалось: How do I empty the trash? - #20 by arrogantrabbit