Oh, thanks Elliott for the explanation! I had no idea about that little tidbit
concerning ctime. Now it all makes sense!
- Max
> On May 28, 2018, at 10:24 pm, Elliott Sims wrote:
>
> Unix timestamps are a bit odd. "mtime/Modify" is file changes,
> "ctime/Change/(sometimes called create)"
Unix timestamps are a bit odd. "mtime/Modify" is file changes,
"ctime/Change/(sometimes called create)" is file metadata changes, and a
link count change is a metadata change. This seems like an odd decision on
the part of GNU tar, but presumably there's a good reason for it.
When the original
I looked at the source code for GNU tar, and it looks for a change in the
create time or (more likely) a change in the size.
This seems very strange to me — I would think that creating a snapshot would
cause a flush and then once the SSTables are written, hardlinks would be
created and the
I've run across this problem before - it seems like GNU tar interprets
changes in the link count as changes to the file, so if the file gets
compacted mid-backup it freaks out even if the file contents are
unchanged. I worked around it by just using bsdtar instead.
On Thu, May 24, 2018 at 6:08
Jeff,
Shouldn't Snapshot get consistent state of sstables? -tmp file shouldn't
impact backup operation right?
Regards,
Nitan K.
Cassandra and Oracle Architect/SME
Datastax Certified Cassandra expert
Oracle 10g Certified
On Wed, May 23, 2018 at 6:26 PM, Jeff Jirsa wrote:
>
In versions before 3.0, sstables were written with a -tmp filename and
copied/moved to the final filename when complete. This changes in 3.0 - we
write into the file with the final name, and have a journal/log to let uss
know when it's done/final/live.
Therefore, you can no longer just watch for
Hi Everyone,
We’ve noticed a few times in the last few weeks that when we’re doing backups,
tar has complained with messages like this:
tar:
/var/lib/cassandra/data/mars/test_instances_by_test_id-6a9440a04cc111e8878675f1041d7e1c/snapshots/backup_20180523_024502/mb-63-big-Data.db:
file changed