I've got 10k+ files totaling over 20GB that I need to concatenate into one file.
Is there a faster way than
cat input_file* >> out
?
The preferred way would be a bash command, Python is acceptable too if not considerably slower.
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this communityI've got 10k+ files totaling over 20GB that I need to concatenate into one file.
Is there a faster way than
cat input_file* >> out
?
The preferred way would be a bash command, Python is acceptable too if not considerably slower.
Nope, cat is surely the best way to do this. Why use python when there is a program already written in C for this purpose? However, you might want to consider using xargs
in case the command line length exceeds ARG_MAX
and you need more than one cat
. Using GNU tools, this is equivalent to what you already have:
find . -maxdepth 1 -type f -name 'input_file*' -print0 |
sort -z |
xargs -0 cat -- >>out
find
is piped through sort
. Without this, the files would be listed in an arbitrary order (defined by the file system, which could be file creation order).
bash
glob. Otherwise I don't see any cases where xargs
or cat
would not behave as expected.
xargs
will call as may cat
as is necessary to avoid an E2BIG error of execve(2).
Mar 6, 2014 at 9:41
Allocating the space for the output file first may improve the overall speed as the system won't have to update the allocation for every write.
For instance, if on Linux:
size=$({ find . -maxdepth 1 -type f -name 'input_file*' -printf '%s+'; echo 0;} | bc)
fallocate -l "$size" out &&
find . -maxdepth 1 -type f -name 'input_file*' -print0 |
sort -z | xargs -r0 cat 1<> out
Another benefit is that if there's not enough free space, the copy will not be attempted.
If on btrfs
, you could copy --reflink=always
the first file (which implies no data copy and would therefore be almost instantaneous), and append the rest. If there are 10000 files, that probably won't make much difference though unless the first file is very big.
There's an API to generalise that to ref-copy all the files (the BTRFS_IOC_CLONE_RANGE
ioctl
), but I could not find any utility exposing that API, so you'd have to do it in C (or python
or other languages provided they can call arbitrary ioctl
s).
If the source files are sparse or have large sequences of NUL characters, you could make a sparse output file (saving time and disk space) with (on GNU systems):
find . -maxdepth 1 -type f -name 'input_file*' -print0 |
sort -z | xargs -r0 cat | cp --sparse=always /dev/stdin out
>
nor >>
, but 1<>
as I said to write into the file.
Mar 5, 2014 at 16:41
<>
is the standard Bourne/POSIX read+write redirection operator. See your shell manual or the POSIX spec for details. The default fd
is 0
for the <>
operator (<>
is short for 0<>
, like <
is short for 0<
and >
short for 1>
), so you need the 1
to explicitly redirect stdout. Here, it's not so much that we need read+write (O_RDWR
), but that we don't want O_TRUNC
(as in >
) which would deallocate what we've just allocated.
Mar 5, 2014 at 20:30
dd
or via reading.
Mar 5, 2014 at 21:15
fallocate
will negate the overhead of the extra find
, even though it will be faster the second time round. btrfs
certainly opens up some interesting possibilities though.
find
does not sort files the same as a shell glob.out
is located on another disk.