Contribute to Open Source. Search issue labels to find the right project for you!

repo fsck doesn't remove badger lockfile

ipfs/go-ipfs

<!– Output From ipfs version --all –>

Version information:

go-ipfs version: 0.4.12-dev-e7acb96c6 Repo version: 6 System version: amd64/windows Golang version: go1.9.1 <!– Bug, Feature, Enhancement, Etc –>

Type:

Bug <!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>

Severity:

Medium

Description:

Running ipfs repo fsck reports that lockfiles were successfully removed but they’re not.

ipfs repo fsck not clearing

Updated 13/10/2017 02:48

Garbage collection doesn't free up space when using badger

ipfs/go-ipfs

<!– Output From ipfs version --all –>

Version information:

go-ipfs version: 0.4.11- Repo version: 6 System version: amd64/linux Golang version: go1.9

<!– Bug, Feature, Enhancement, Etc –>

Type:

Bug

<!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>

Severity:

Medium/High

Description:

When running garbage collection on a repo using the badger datastore, local storage is not freed up after running ipfs repo gc.

Updated 13/10/2017 02:49 1 Comments

Document tarball signing keys

PowerDNS/pdns

pdns(-recursor)/dnsdist tarballs come with a detached signature, but neither powerdns.com or dnsdist.org have a list of official signing keys.

Please provide such a list on the webpages.

It’d also be nice if all keys were bundled together in a pgp public key block.

Updated 21/08/2017 16:38

consider reordering repo.powerdns.com to favor newer stuff

PowerDNS/pdns

<!– Before filing an issue, please search the existing issues (both open and closed) to see if your report might be duplicate –> <!– Please don’t file an issue when you have a support question, send support questions to the mailinglist or ask them on IRC (https://www.powerdns.com/opensource.html) –>

<!– Tell us what is issue is about –> - Program: Authoritative, Recursor, dnsdist - Issue type: Feature request

Short description

<!– Explain in a few sentences what the issue/request is –> The order of linux distributions (especially Debian and Ubuntu) is really not ideal. It favors old things for no particular reason.

Environment

Web Browser

Steps to reproduce

I was looking for the repo info for Debian 9 Stretch (but half the time i’m looking for an Ubuntu or a different Debian, or potentially a RHEL).

  1. visit https://repo.powerdns.com/
  2. Click Debian
  3. See “powerdns authoritative server version 4.0.x” and expand it

Expected behaviour

There are a number of ways to improve this 1. Don’t auto expand the second level (distro releases) when someone expands the first level (distro brands) 2. Change the order to favor newer releases over older releases 3. Possibly split LTS out of the normal flow (they’re in a lot of ways a distinct product from normal releases – with a distinct customer base – consider RHEL vs. Fedora – they’re very related, but practically unrelated customers – same for CentOS, very related, but distinct customers) 4. Switch to a series of [ |v] drop downs instead of a tree, an example of that is used by the PPA system, as in: https://launchpad.net/~laurent-boulard/+archive/ubuntu/vim a. click “Technical details about this PPA” b. select an item in: Display sources.list entries for:

Actual behaviour

Tree auto expanded to show Debian 8 children which obscured the presence of Debian 9.

Note that it’s much worse for Ubuntu, the first entry expanded is 14.04 (the older LTS), the second is 16.04 (the latest LTS), the third is 16.10 (obsolete), the last is 17.04 (the current release).

Note: the behavior is also not very helpful at the next tier: If a user is looking for something, they probably only care about a single product (auth, dnsdist, recursor, metronome) – showing them all of the various versions of all the products they don’t want isn’t helpful.

w/ a dropdown, I’d probably preselect the latest release branch but have “master” above and all the older things below.

Other information

Usecase

Make it easy for customers to pick the right product.

Description

Updated 21/08/2017 17:19 2 Comments

Incorrect `repoSize` when using symbolic links

ipfs/go-ipfs

Version information:

go-ipfs version: 0.4.10-
Repo version: 5
System version: amd64/linux
Golang version: go1.8.3

Type:

Bug

Severity:

Low

Description:

If the .ipfs directory is a symbolic link the repoSize as returned by ipfs repo stat or ipfs stats repo will always return 9 bytes regardless of actual data stored

With symlink ``` ~$ ls -al lrwxrwxrwx 1 ipfs ipfs 9 Jun 22 2016 .ipfs -> ipfs_data drwxrwxr-x 5 ipfs ipfs 4096 Jul 12 01:25 ipfs_data

~$ ipfs repo stat NumObjects: 204114 RepoSize: 9 StorageMax: 800000000000 RepoPath: /home/ipfs/.ipfs Version: fs-repo@5 ```

Without symlink ~$ ipfs repo stat NumObjects: 204114 RepoSize: 49450734482 StorageMax: 800000000000 RepoPath: /home/ipfs/.ipfs Version: fs-repo@5

Updated 30/08/2017 01:30 1 Comments

Error writing block to datastore: Access is denied.

ipfs/go-ipfs

Version information:

go-ipfs version: 0.4.9- Repo version: 5 System version: amd64/windows Golang version: go1.8.1

Type: Bug

<!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>

Severity: Medium

Description:

Started ipfs daemon: ipfs daemon Runs for a bit and connects to peers. Starts throwing errors in the console. [0;37m16:48:35.891 [31mERROR [0;34m bitswap: [0mError writing block to datastore: Access is denied. [0;37mbitswap.go:322[0m and [0;37m16:48:39.904 [31mERROR [0;34mcommands/h: [0merr: write tcp4 127.0.0.1:5001->127.0.0.1:56762: wsasend: An established connection was aborted by the software in your host machine. [0;37mhandler.go:288[0m

Updated 11/10/2017 09:49 31 Comments

datastore: `ipfs repo stat` seems to hang with large repos on Windows

ipfs/go-ipfs

<!– Output From ipfs version --all) –>

Version information:

0.4.5-dev, 56058c1 with HAMT sharding merged in (unrelated)

<!– Bug, Feature, Enhancement, Etc –>

Type: bug

<!– from P0 “Critical” to P5 “Relatively Unimportant”) –>

Priority: P2

Description:

On a repo with 312695 objects, on a HDD formatted with NTFS, ipfs repo stat seems to take forever to finish. I assume it’s doing something inefficient when checking for filesizes, as ipfs refs local finishes in 18 seconds.

C:\Users\matin>sh -c "time ipfs repo stat"

Error: request canceled

real    12m41.638s
user    0m0.000s
sys     0m0.031s
C:\Users\matin>sh -c "time ipfs refs local | wc"
 312695  312695 14728215

real    0m18.022s
user    0m0.375s
sys     0m0.952s

(on a side note, refs local also seems slightly slow, but that might just be an IO bound)

<!– This is for you! Please read, and then delete this text before posting it. The go-ipfs issues are only for bug reports and directly actionable features. Read https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if your issue doesn’t fit either of those categories. Read https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md if you are not sure how to fill in this issue. –>

Updated 02/09/2017 21:42

Gateway and readonly repo

ipfs/go-ipfs

The gateway tries to fetch, store, and serve any hash that is requested. It would be useful to be able to refine this behavior, e.g. for repos in readonly environments. The naming is the best I could come up with adhoc.

  • [ ] Gateway.Fetch ||= true config option: whether a hash that has been requested should be fetched from the network if it isn’t stored locally yet. If set to false, the gateway will immediately respond with a client error (4xx) if the requested stuff isn’t stored locally.
  • [ ] Datastore.Readonly ||= false config option: whether stuff that has been fetched (as in the above) should be stored locally, or discarded after sending it with the response.
Updated 02/09/2017 21:40

Slowly handling large number of files

ipfs/go-ipfs

<!– Output From ipfs version --all) –>

Version information:

% ./ipfs version –all
go-ipfs version: 0.4.4- Repo version: 4 System version: amd64/freebsd Golang version: go1.7

<!– Bug, Feature, Enhancement, Etc –>

Type:

./ipfs add became very slow when handling large number of files.

<!– from P0 “Critical” to P5 “Relatively Unimportant”) –>

Priority:P1

Description:

./ipfs add became very slow when handling about 45K files(~300GB), it took about 3+ seconds to wait after the process bar finished.

But we can run several IPFS in the same machine to deal with this issue.

About the machine: CPU:E3-1230V2, RAM:16G, storage:8T with 240G SSD cache@ZFS

Thanks for the amazing project!

<!– This is for you! Please read, and then delete this text before posting it. The go-ipfs issues are only for bug reports and directly actionable features. Read https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if your issue doesn’t fit either of those categories. Read https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md if you are not sure how to fill in this issue. –>

Updated 02/09/2017 22:54 1 Comments

Investigate add/pin/gc locking

ipfs/go-ipfs

While looking into #3470 and #3436, I found that the locks around adding/pinning/GC look really wonky and inconsistent.

This issue is a reminder that we need to:

  • [ ] Look very closely at which locks are in play
  • [ ] Document in detail how these locks work
  • [ ] Write stress tests which make sure we don’t end deadlock ourselves
Updated 02/09/2017 22:53 1 Comments

Broadwell - Problem adding packages.synocommunity.com repository to rs3617xs+

SynoCommunity/spksrc

Hello, it seems there is a problem adding packages.synocommunity.com repository to rs3617xs+ - it reports “Invalid location”. The same procedure on RS2211 works well.

Here are the http request and reply sniffed from the network … (packages.synocommunity.com was resolved to 104.31.94.179)

GET /?package_update_channel=beta&unique=synology_broadwell_rs3617xs%2B&build=8451&language=csy&major=6&arch=broadwell&minor=0&timezone=Amsterdam HTTP/1.1
Host: packages.synocommunity.com
User-Agent: synology_broadwell_rs3617xs+ DSM6.0-8451 Update 2 (package)
Accept: */*
HTTP/1.1 422 UNPROCESSABLE ENTITY
Date: Wed, 02 Nov 2016 11:47:48 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d1523eb3770083bbc6dad219f752ed3ab1478087268; expires=Thu, 02-Nov-17 11:47:48 GMT; path=/; domain=.synocommunity.com; HttpOnly
Server: cloudflare-nginx
CF-RAY: 2fb75a9440222348-FRA

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>422 Unprocessable Entity</title>
<h1>Unprocessable Entity</h1>
<p>The request was well-formed but was unable to be followed due to semantic errors.</p>

(and one more POST request using the same parameters)

Updated 16/10/2017 04:39 35 Comments

Performance: ipfs add I/O (rotational disks)

ipfs/go-ipfs

Version information:

go-ipfs version: 0.4.5-dev-634005a Repo version: 4 System version: amd64/linux Golang version: go1.7.1

Type: Enhancement

Area: Core

Priority: P4/P5

Description:

Improve performance of addition/hashing of files by using file extents on filesystems applicable to. Does slightly up to massively increase throughput on rotational disks, based on device performance and I/O load by rest of the system.

This would likely be done per directory level. Can be further improved by doing traversal first (increase of memory usage for large datasets, therefore should be a command flag).

Updated 02/09/2017 23:10 2 Comments

Fork me on GitHub