summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Stan <Stan@web>2016-07-02 21:46:59 +0000
committerGravatar admin <admin@branchable.com>2016-07-02 21:46:59 +0000
commite06dda9501b3e990c2d6a8b249787520d08ba6fe (patch)
treec58af43bd9350ebafb5e7041ca81384ebdeed2bc
parentca9f54da397c1d9eb1e649d0de1a68d0aa90c234 (diff)
-rw-r--r--doc/bugs/v6_appears_to_not_thin.mdwn65
1 files changed, 65 insertions, 0 deletions
diff --git a/doc/bugs/v6_appears_to_not_thin.mdwn b/doc/bugs/v6_appears_to_not_thin.mdwn
new file mode 100644
index 000000000..7d9deb5ef
--- /dev/null
+++ b/doc/bugs/v6_appears_to_not_thin.mdwn
@@ -0,0 +1,65 @@
+### Please describe the problem.
+
+First of all, I don't really believe the following is a good bug report, from my own career in SW development. I know what to do. However, this is a start to test the waters; I received no response in the general forum (not a complaint), but I am not sure if this is simply one of those issues for which the solution is so simple, that no one can bring themselves to reply.
+
+I can provide further detail, like console copies, but I figured that providing the config output to be a good first step. Apologies for the format of the config file: it was copied fine, but pasted on one line.
+
+
+It seems thinning is not doing what I expected:
+
+Which is: unlocking a file creates a hard link in the working directory, linked to the annex file, with the resulting dir size being the size of the one big file.
+
+Are my expectations correct?
+
+Is there something I am missing?
+
+
+
+### What steps will reproduce the problem?
+
+copied a big file to the working directory
+
+git add; git commit
+
+Locking the big file creates the symlink, with the file in the annex.
+
+Unlocking the big file creates a real file in the working dir, and the annex file stays there.
+
+The total dir is therefore twice the size of the big file.
+
+ls -li shows a unique inode for each file. Therefore it appears to not be a hard link.
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20160524+gitg2b7b2c4-1~ndall+1
+
+Debian 8.5
+
+
+### Please provide any additional information below.
+
+repo config file:
+
+[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [annex] uuid = c5c203ec-9353-4213-8af5-6fcb8de36ca2 version = 6 thin = true [filter "annex"] smudge = git-annex smudge %f clean = git-annex smudge --clean %f
+
+
+
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+You bet. It is simply great. I am in the process of migrating all my big data. I have roughly 6TB, and it is taking me many weeks.
+
+I am creating a typical duplicate topology. 2 remotes, 2 backup nodes. Multiple clients, each connected to the 2 remotes. Each client will only clone the repos or parts thereof that are relevant to that client.
+
+I have multiple clients on multiple VMs. I generally separate functions to VMs. I.e. postgresql to a pair of VMs; etc. Poorly behaving apps like iTunes to its very own penalty box win VM. HA to its own VM. etc.
+
+