* [Chris Mason]
> Excerpts from Erik Logtenberg's message of 2010-12-15 14:26:49 -0500:
>>
>> The use case is a filesystem used for backups, which are rsynced
>> nightly, after which a new snapshot is made. After something like 45
>> days, the old snapshots are removed. I am assuming that this w
Hi,
In btrfs, inode number is increased each time a new file or directory
is made.
Therefore, if the making deletion of the file is repeated, value of
'i_ino' increases rapidly.
For example, inode number changes as follows.
$ touch foo
$ ls -i foo
266 foo
$ rm foo
$ touch bar
$ ls -
Excerpts from Dave Chinner's message of 2010-12-15 22:37:18 -0500:
> On Wed, Dec 08, 2010 at 07:20:24AM -0500, Chris Mason wrote:
> >
> > Usually the trick to reproducing filesystem corruptions is adding memory
> > pressure. The corruption is probably a bad interaction between reads
> > and write
Hi,
I have a btrfs that conains many hardlinks. I'm using rsync to create
backups. It creates the backup of a day by (hard‐)linking the files
(inodes) they haven't changed with the files from a former day.
% find 2010-12-1[10]-00 -maxdepth 1
2010-12-10-00
2010-12-10-00/etc
2010-12-10-00/home
2010
On Wed, Dec 15, 2010 at 1:20 PM, Chris Mason wrote:
>>
>> Is there a decent way to have btrfs compress already existing files
>> (that were written before compression was enabled) without hurting any
>> of the internal structures such as snapshots?
>
> I'm afraid not yet. There is code for this
Hi,
I'm not really answering your question, but may I suggest you change
your backup strategy to leverage one of btrfs main features: instead of
using the hardlink-feature of rsync, use snapshots. Btrfs snapshots are
way better than a hardlink-tree, for multiple reasons:
- It uses less diskspace,
Hi!
Last week I crashed a btrfs file system. I didn't lose a lot of data because I
had current backups of most data and a full backup from a month ago.
But I thought it would be a nice idea to have a rescue tool! Currently I have a
first release of this tool (surely buggy and runnning on little e
Excerpts from Michael Niederle's message of 2010-12-16 18:18:49 -0500:
> Hi!
>
> Last week I crashed a btrfs file system. I didn't lose a lot of data because I
> had current backups of most data and a full backup from a month ago.
>
> But I thought it would be a nice idea to have a rescue tool! C
Andreas Philipp hat am Thu 16. Dec, 14:03 (+0100) geschrieben:
> On 16.12.2010 13:31, Jörg Sommer wrote:
> > When running rm -r to remove an old backup or running rsync I see the
> > average size of a read or a write request ist 4k. This leads to a very
> > bad throughput of fewer than 2MByte/s. I'
Excerpts from Ian! D. Allen's message of 2010-12-13 21:23:24 -0500:
> I can reliably get btrfs 0.19 to hang in btrfs_commit_transaction.
> Below is another case where it hung after creating just 110 snapshots
> of /var/log/. Here is an excerpt from the script log file showing the
> last good snaps
On Thu, Dec 16, 2010 at 08:47:05PM -0500, Chris Mason wrote:
> I think this hang is something that sage fixed. Which kernel is this
> ubuntu including?
All that detail is posted in the second message in the thread you quoted:
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg07448.html
11 matches
Mail list logo
