Am Montag, 25. August 2014, 14:45:39 schrieb Chris Murphy:
> On Aug 25, 2014, at 6:00 AM, Martin Steigerwald wrote:
> > What is the latest stuff that stills supposed to work okay?
>
> I'm new to git so take this with a grain of salt, but this returns no
> differences:
>
Am Montag, 25. August 2014, 10:58:13 schrieb Chris Mason:
> On 08/15/2014 11:36 AM, Liu Bo wrote:
> > This has been reported and discussed for a long time, and this hang occurs
> > in both 3.15 and 3.16.
>
> [ great description ]
>
> I ran this through tests last week, and an overnight test over
Hello!
I am a bit confused about btrfs-progs git repo URLs and branches.
What is the latest stuff that stills supposed to work okay?
My /home BTRFS RAID 1 on two SSDs filesystem has an error with btrfs check that
btrfs-tools 3.14.1 cannot repair.
The repo I found on git.kernel.org
git://git.k
Am Freitag, 22. August 2014, 17:29:29 schrieb Shriramana Sharma:
> Hello. I've seen repeated advices to use the latest kernel. While
> hearing of the recent compression bug affecting recent kernels does
> somewhat warn one off the previous advice, I would like to know what
> people who are running
Hello!
Am Donnerstag, 21. August 2014, 08:52:52 schrieb Shriramana Sharma:
> Hello. People on this list have been kind enough to reply to my
> technical questions. However, seeing the high number of mails on this
> list, esp with the title PATCH, I have a question about the
> development itself:
>
Am Donnerstag, 14. August 2014, 11:27:06 schrieb Martin Steigerwald:
> Am Mittwoch, 13. August 2014, 23:20:46 schrieb Liu Bo:
> > On Wed, Aug 13, 2014 at 01:54:40PM +0200, Martin Steigerwald wrote:
> > > Am Dienstag, 12. August 2014, 15:44:59 schrieb Liu Bo:
> > > &
Am Freitag, 15. August 2014, 15:52:15 schrieb Valdis Voronin:
> Hi Martin,
>
> В письме от 15 августа 2014 12:25:36 пользователь Martin Steigerwald
написал:
> > Please include outputs of
> >
> > btrfs fi sh /
>
> # btrfs fi sh /
> Label: none uuid:
Hi Valdis,
Am Freitag, 15. August 2014, 14:10:37 schrieb Valdis Voronin:
> System freeze after IO chaos. See attached image.
>
> В письме от 13 августа 2014 20:40:49 пользователь Valdis Voronin написал:
> > Sorry subject should be btrfs 3.14-2-amd64 btrfs_file_aio_write problem.
> >
> > On Wed
Am Mittwoch, 13. August 2014, 23:20:46 schrieb Liu Bo:
> On Wed, Aug 13, 2014 at 01:54:40PM +0200, Martin Steigerwald wrote:
> > Am Dienstag, 12. August 2014, 15:44:59 schrieb Liu Bo:
> > > This has been reported and discussed for a long time, and this hang
> > > occurs
Am Dienstag, 12. August 2014, 15:44:59 schrieb Liu Bo:
> This has been reported and discussed for a long time, and this hang occurs
> in both 3.15 and 3.16.
Liu, is this safe for testing yet?
Thanks,
Martin
> Btrfs now migrates to use kernel workqueue, but it introduces this hang
> problem.
>
>
Am Montag, 4. August 2014, 11:09:23 schrieb Peter Waller:
> On 4 August 2014 10:39, Chris Samuel wrote:
> > On Mon, 4 Aug 2014 09:14:19 AM Peter Waller wrote:
> >> All of this is *very* surprising.
> >
> > Hmm, it shouldn't be, the ENOSPC issues are well known and have been
> > discussed here for
Am Dienstag, 5. August 2014, 14:58:34 schrieb Clemens Eisserer:
> Hi Russel,
>
> > The Debian installer has BTRFS in a list of filesystems to choose with no
> > special notice about it. I'm thinking of filing a Debian bug requesting
> > that they put a warning against it.
>
> As long as it is no
Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
> >> I think this should go to stable. Thanks, Liu.
>
> I'm definitely tagging this for stable.
>
> > Unfortunately this fix does not seem to fix all lo
Am Mittwoch, 6. August 2014, 11:29:19 schrieb Hugo Mills:
> On Wed, Aug 06, 2014 at 12:21:59PM +0200, Martin Steigerwald wrote:
> > It basically happened on about the first heavy write I/O occasion after
> > the BTRFS trees filled the complete device:
> >
> > I am now
Am Montag, 4. August 2014, 14:50:29 schrieb Martin Steigerwald:
> Am Freitag, 25. Juli 2014, 11:54:37 schrieb Martin Steigerwald:
> > Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> > > When failing to allocate space for the whole compressed extent, we'll
> >
Am Montag, 4. August 2014, 14:50:29 schrieb Martin Steigerwald:
> Am Freitag, 25. Juli 2014, 11:54:37 schrieb Martin Steigerwald:
> > Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> > > When failing to allocate space for the whole compressed extent, we'll
> >
Am Freitag, 25. Juli 2014, 11:54:37 schrieb Martin Steigerwald:
> Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> > When failing to allocate space for the whole compressed extent, we'll
> > fallback to uncompressed IO, but we've forgotten to redirty the pages
Am Donnerstag, 24. Juli 2014, 16:04:22 schrieb Chris Mason:
> On 07/24/2014 02:49 PM, Martin Steigerwald wrote:
> > Am Donnerstag, 24. Juli 2014, 10:58:51 schrieb Chris Mason:
> >> On 07/23/2014 06:47 PM, Martin Steigerwald wrote:
> >>> Am Dienstag, 15. Juli
Hi Hugo,
Am Samstag, 26. Juli 2014, 11:05:03 schrieb Hugo Mills:
> > I am not asking to hold my hand
>
>You are, though. Something like using grep to find code that (might
> be) related to the thing you're trying to work with is _fundamental_.
> You should expect to be reading the code -- sev
Am Freitag, 25. Juli 2014, 02:32:17 schrieb Duncan:
> Martin Steigerwald posted on Thu, 24 Jul 2014 20:49:37 +0200 as excerpted:
> > It may take some time tough cause during compiling the kernel BTRFS hung
> > again, which caused loss of KDE Baloo desktop search file index and
>
Am Freitag, 25. Juli 2014, 09:00:19 schrieb Liu Bo:
> On Thu, Jul 24, 2014 at 10:55:47AM -0400, Chris Mason wrote:
> > On 07/24/2014 10:48 AM, Liu Bo wrote:
> > > When failing to allocate space for the whole compressed extent, we'll
> > > fallback to uncompressed IO, but we've forgotten to redirty
Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> When failing to allocate space for the whole compressed extent, we'll
> fallback to uncompressed IO, but we've forgotten to redirty the pages
> which belong to this compressed extent, and these 'clean' pages will
> simply skip 'submit' part an
Am Donnerstag, 24. Juli 2014, 10:58:51 schrieb Chris Mason:
> On 07/23/2014 06:47 PM, Martin Steigerwald wrote:
> > Am Dienstag, 15. Juli 2014, 17:08:27 schrieb Martin Steigerwald:
> >> Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
> >>> On 07/14/2014 05:5
Am Donnerstag, 24. Juli 2014, 10:58:51 schrieb Chris Mason:
> On 07/23/2014 06:47 PM, Martin Steigerwald wrote:
> > Am Dienstag, 15. Juli 2014, 17:08:27 schrieb Martin Steigerwald:
> >> Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
> >>> On 07/14/2014 05:5
Am Dienstag, 15. Juli 2014, 17:08:27 schrieb Martin Steigerwald:
> Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
> > On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
> > > Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
> > >> On 07/14/2014 11:1
Am Dienstag, 22. Juli 2014, 17:15:21 schrieb Chris Mason:
> On 07/22/2014 05:13 PM, Martin Steigerwald wrote:
> > Am Dienstag, 22. Juli 2014, 10:53:03 schrieb Chris Mason:
> >> On 07/19/2014 02:23 PM, Martin Steigerwald wrote:
> >>>> Running 3.15.6 with this patc
Am Dienstag, 22. Juli 2014, 10:53:03 schrieb Chris Mason:
> On 07/19/2014 02:23 PM, Martin Steigerwald wrote:
> >> Running 3.15.6 with this patch applied on top:
> >> - still causes a hang with `rsync -hPaHAXx --del /mnt/home/nyx/
> >> /home/nyx/`
> >>
Am Samstag, 19. Juli 2014, 14:39:51 schrieb Chris Mason:
> On 07/19/2014 01:59 PM, Martin Steigerwald wrote:
> > Am Freitag, 18. Juli 2014, 09:36:06 schrieb Chris Mason:
> >> On 07/18/2014 03:51 AM, Martin Steigerwald wrote:
> >>> Am Dienstag, 15. Juli 2014, 09:21:40
Am Samstag, 19. Juli 2014, 12:38:53 schrieb Cody P Schafer:
> On Thu, Jul 17, 2014 at 8:18 AM, Chris Mason wrote:
> > [ deadlocks during rsync in 3.15 with compression enabled ]
> >
> > Hi everyone,
> >
> > I still haven't been able to reproduce this one here, but I'm going
> > through a series
Am Freitag, 18. Juli 2014, 09:36:06 schrieb Chris Mason:
> On 07/18/2014 03:51 AM, Martin Steigerwald wrote:
> > Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
> >> On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
> >>> Am Montag, 14. Juli 2014, 16:12:22
Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
> On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
> > Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
> >> On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
> >>> Am Montag, 14. Juli 2014, 17:
Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
> On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
> > Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
> >> On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
> >>> Am Montag, 14. Juli 2014, 17:
Am Dienstag, 15. Juli 2014, 11:25:15 schrieb Torbjørn:
> On 15. juli 2014 11:09, Martin Steigerwald wrote:
> > Hello!
> >
> > This is with 3.16-rc4 – stepped back to this one after having two hangs in
> > one day with 3.16-rc5, see other thread started by me:
>
Hello!
This is with 3.16-rc4 – stepped back to this one after having two hangs in one
day with 3.16-rc5, see other thread started by me:
martin@merkaba:~/Zeit/undeletable/db_data> ls -lid akonadi
450598 drwx-- 1 martin martin 1232 Jun 22 14:11 akonadi
martin@merkaba:~/Zeit/undeletable/db_dat
Am Montag, 14. Juli 2014, 17:51:37 schrieben Sie:
> Martin Steigerwald posted on Mon, 14 Jul 2014 17:10:30 +0200 as excerpted:
> > Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
> >> Hi!
> >>
> >> While with 3.16-rc3 and rc4 I didn´t have a BTRFS hang in s
Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
> On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
> > Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
> >> Hi!
> >>
> >> While with 3.16-rc3 and rc4 I didn´t have a BTRFS hang in several days of
&g
Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
> Hi!
>
> While with 3.16-rc3 and rc4 I didn´t have a BTRFS hang in several days of
> usage, with 3-16-rc5 I had a hang again. Less than a hour since booting it.
>
> Since the hang bug I and others had with 3.15 and upto 3.16-rc2 usually
> didn´t
Hi!
While with 3.16-rc3 and rc4 I didn´t have a BTRFS hang in several days of
usage, with 3-16-rc5 I had a hang again. Less than a hour since booting it.
Since the hang bug I and others had with 3.15 and upto 3.16-rc2 usually
didn´t happen that quickly after boot and since backtrace looks a bit
d
Am Donnerstag, 10. Juli 2014, 11:05:10 schrieb Qu Wenruo:
> When calling find_mount_root(), caller in fact wants to find the mount
> point of *BTRFS*.
>
> So also check ent->fstype in find_mount_root() and output proper error
> messages if needed.
> This will suppress a lot of "Inapproiate ioctl f
Am Donnerstag, 10. Juli 2014, 12:10:46 schrieb Russell Coker:
> On Wed, 9 Jul 2014 16:48:05 Martin Steigerwald wrote:
> > > - for someone using SAS or enterprise SATA drives with Linux, I
> > > understand btrfs gives the extra benefit of checksums, are there any
> > >
possible AFAIK:
- Different RAID levels on same filesystem yet different subvolumes, more
flexibility as subvolumes are dynamically allocated, instead of statically
sized
Ciao,
Martin
--
Martin Steigerwald
Consultant / Trainer
teamix GmbH
Südwestpark 43
90449 Nürnberg
fon: +49 911 309
Am Samstag, 28. Juni 2014, 16:28:23 schrieb Russell Coker:
> > So look for N-way-mirroring when you go RAID shopping, and no, btrfs does
> > not have it at this time, altho it is roadmapped for implementation after
> > completion of the raid5/6 code.
> >
> >
> >
> > FWIW, N-way-mirroring is my #1
Am Samstag, 14. Juni 2014, 12:59:31 schrieb Kai Krakow:
> Well, how did I accomblish that?
Setting no cow and defragmenting regularily?
Quite a complex setup for a casual Linux user.
Any solution should be automatic. I´d suggest by a combination of sane
application behaviour and measures within
Am Samstag, 14. Juni 2014, 02:53:20 schrieb Duncan:
> > I am reaching the conclusion that fallocate is not the problem. The
> > fallocate increase the filesize of about 8MB, which is enough for some
> > logging. So it is not called very often.
>
> But...
>
> If a file isn't (properly[1]) set NOC
Am Donnerstag, 5. Juni 2014, 15:30:26 schrieb Swâmi Petaramesh:
> Hi,
>
> I just received a new laptop with a Micron 256GB SSD, and I plan to install
> Fedora 20 onto it.
>
> I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this
> machine, but I'm afraid BTRFS might generate t
Hi!
I am getting BTRFS hangs unregularily on SSD based BTRFS RAID 1.
Any hints?
If you need additional data please tell.
Raid is
merkaba:~> lsblk /dev/sda4 /dev/sdb3
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda48:40 279G 0 part
├─sata-home (dm-4)
[keeping dropped CC although not customary on this list]
Am Mittwoch, 30. April 2014, 00:42:44 schrieb Duncan:
> Holger Hoffstätte posted on Tue, 29 Apr 2014 17:33:09 + as excerpted:
> >> On Tue, Apr 29, 2014 at 05:10:31PM +, Duncan wrote:
> >>> David Sterba posted on Tue, 29 Apr 2014 17:5
Am Freitag, 25. April 2014, 11:40:28 schrieben Sie:
> On Fri, Apr 18, 2014 at 7:18 PM, Martin Steigerwald
wrote:
> > Hello,
> >
> > I have:
> >
> > merkaba:/mnt#1> btrfs scrub status -d /home
> > scrub status for […]
> > scrub device /dev/dm-0
Hello,
I have:
merkaba:/mnt#1> btrfs scrub status -d /home
scrub status for […]
scrub device /dev/dm-0 (id 1) status
scrub started at Fri Apr 18 17:48:10 2014, running for 335 seconds
total bytes scrubbed: 74.80GiB with 0 errors
scrub device /dev/mapper/sata-home (id 2) status
Hi Liu,
Am Donnerstag, 10. April 2014, 23:55:21 schrieb Liu Bo:
> Hi,
>
> Just FYI, these patches are also available on the following site,
>
> kernel:
> https://github.com/liubogithub/btrfs-work.git dedup-on-3.14-linux
>
> progs:
> https://github.com/liubogithub/btrfs-progs.git dedup
I bet it
Am Donnerstag, 10. April 2014, 17:51:26 schrieb Michael Schuerig:
> On Thursday 10 April 2014 15:15:02 Duncan wrote:
> > Meanwhile (2), given the existence of those tested backups, there's
> > yet another way to accomplish things. Simply restore from the
> > backups the same way you would if the
Hi,
[not cc´ing you as you didn´t cc anyone and I think you do not like to be CC
´d, note that usual on kernel related mailing lists this is a convention, so I
may miss it at some time. not restoring other cc´s as I am lazy right now]
Am Samstag, 5. April 2014, 15:06:26 schrieb Duncan:
> Garry T
Am Sonntag, 23. März 2014, 15:51:34 schrieben Sie:
> I was expecting either a speed improvement after rebalance, or no
> noticeable effect, but I am extremely disappointed to see that now (and
> after having rebooted), my system has become slow like hell, takes at least
> 10x longer to boot and op
Hi!
On 3.14.0-rc4-tp520 (compiled with gcc 4.8.2) shrinking my /home from about
260 GiB to 150 GiB resulted in a BTRFS hang.
First it relocated block groups, but then on one the btrfs command was
blocked for more than 120 seconds.
A second attempt after a reboot quickly had the same result.
I d
Hi!
Since a few days this ThinkPad T520 has 780 GB SSD capacity. The 300 GB of
the Intel SSD 320 were almost full and that 480 GB Crucial m500 mSATA SSD
was cheap enough to just buy it.
I created a new logical volume for big and not that often changed files that
is just on the msata and moved all
Am Sonntag, 9. März 2014, 11:33:50 schrieb Hugo Mills:
> On Sun, Mar 09, 2014 at 11:23:29AM +0100, Swâmi Petaramesh wrote:
> > Le dimanche 9 mars 2014 11:01:17 vous avez écrit :
> > > This ThinkPad T520 has been with BTRFS since installation of the Debian
> > > sid system on it with Kernel 2.6.39 o
Am Sonntag, 9. März 2014, 09:17:24 schrieb Swâmi Petaramesh:
> Le dimanche 9 mars 2014 08:48:20 KC a écrit :
> > I am experiencing massive performance degradation on my BTRFS root
> > partition on SSD.
>
> BTW, is BTRFS still a SSD-killer ? It had this reputation a while ago, and
> I'm not sure if
Am Montag, 17. Februar 2014, 08:06:50 schrieb Chris Mason:
> On 02/17/2014 05:35 AM, Martin Steigerwald wrote:
> > Am Dienstag, 11. Februar 2014, 15:50:12 schrieb Dave:
> >> On Tue, Feb 11, 2014 at 10:36 AM, Martin Steigerwald
> >>
> >> wrote:
> >>&g
Am Dienstag, 11. Februar 2014, 15:50:12 schrieb Dave:
> On Tue, Feb 11, 2014 at 10:36 AM, Martin Steigerwald
>
> wrote:
> > Today I started getting those on 3.14-rc. One core as displayed as 100%
> > system CPU. I rebooted cause the system didn´t respond consistently to
&
Hi!
Today I started getting those on 3.14-rc. One core as displayed as 100%
system CPU. I rebooted cause the system didn´t respond consistently to
user input anymore.
I "solved" this by adding about the last 13,5 GiB of free space on this
Intel SSD 320 to it:
merkaba:~> df -hT /home
Dateisystem
Am Donnerstag, 6. Februar 2014, 22:30:46 schrieb Chris Murphy:
> On Feb 6, 2014, at 9:40 PM, Roman Mamedov wrote:
> > On Thu, 06 Feb 2014 20:54:19 +0100
> >
> > Goffredo Baroncelli wrote:
> >
> >
> >> I agree with you about the needing of a solution. However your patch to
> >> me seems even wors
Am Montag, 27. Januar 2014, 14:28:28 schrieb Gerhard Heift:
> To prevent unexpectet values in the unused fields of the search key fail
unexpected
> early. Otherwise future extensions would break the behavior of the search
> if current implementations in userspace set them to values other than zer
Am Samstag, 25. Januar 2014, 15:06:24 schrieb Kai Krakow:
> Martin Steigerwald schrieb:
> > Okay, I have seen 260 MB/s. But frankly I am pretty sure that Virtuoso
> > isn´t doing this kind of large scale I/O on a highly fragmented file. Its
> > a database. Its random access
Am Samstag, 25. Januar 2014, 15:33:08 schrieb Imran Geriskovan:
> Every write on a SSD block reduces its data retension capability.
>
> No concrete figures but it is assumed to be
> - 10 years for new devices
> - 1 year at rated usage. (There are much lower figures around)
Where do you have these
Am Freitag, 24. Januar 2014, 21:14:21 schrieben Sie:
> KC schrieb:
> > I was wondering about whether using options like "autodefrag" and
> > "inode_cache" on SSDs.
> >
> >
> >
> > On one hand, one always hears that defragmentation of SSD is a no-no,
> > does that apply to BTRFS's autodefrag?
> >
Hi Duncan,
Am Freitag, 24. Januar 2014, 06:54:31 schrieb Duncan:
> Anyway, yes, I turned autodefrag on for my SSDs, here, but there are
> arguments to be made in either direction, so I can understand people
> choosing not to do that.
Do you have numbers to back up that this gives any advantage?
Am Sonntag, 12. Januar 2014, 23:31:43 schrieb Hendrik Friedel:
> > It mounts OK with no kernel messages?
>
> Yes. Here I mount the three subvolumes:
Does scrubbing the volume give any errors?
I´d test this. If scrubbing runs through without errors at least your data is
currently safe.
As to th
Am Samstag, 18. Januar 2014, 07:16:42 schrieb Duncan:
> Ian Hinder posted on Sat, 18 Jan 2014 01:23:41 +0100 as excerpted:
> > I have been reading a lot of articles online about the dangers of using
> > ZFS with non-ECC RAM. Specifically, the fact that when good data is
> > read from disk and comp
Am Freitag, 17. Januar 2014, 19:30:49 schrieben Sie:
> To start off, I have an encrypted LVM setup with a root logical volume and a
> home logical volume. Today decided to upgrade my home LV to btrfs for
> compression. I installed btrfs-progs, unmounted /home, and ran
> btrfs-convert /dev/MyVolumeG
Am Mittwoch, 15. Januar 2014, 19:05:41 schrieb Duncan:
> But just as my already allocated mixed-mode chunks were just about full
> and I needed another one allocated to complete the job, so your data
> chunks are full or very close, according to btrfs fi df, and you need a
> new one allocated (a
Am Montag, 30. Dezember 2013, 16:12:55 schrieben Sie:
> This adds deduplication subcommands, 'btrfs dedup command ',
> including enable/disable/on/off.
Nice. Looking forward to test it.
> - btrfs dedup enable
> Create the dedup tree, and it's the very first step when you're going to use
> the de
Hi!
Today I started my backup script which rsync´s my system to an external 3,5
inch 2 TB harddisk with the wrong destination dir which I notices more than
150 GiB of data has been copied twice instead of diffing with an existing
subvolume.
Thus I rm -rf the misplaced backup and started the ba
Am Samstag, 21. September 2013, 10:54:55 schrieb Martin Steigerwald:
> Am Freitag, 20. September 2013, 22:34:15 schrieb Josef Bacik:
> > On Sat, Sep 21, 2013 at 12:25:02AM +0200, Martin Steigerwald wrote:
> > > Hi!
> > >
> > > I tried to create a snapshot t
Am Freitag, 20. September 2013, 22:34:15 schrieb Josef Bacik:
> On Sat, Sep 21, 2013 at 12:25:02AM +0200, Martin Steigerwald wrote:
> > Hi!
> >
> > I tried to create a snapshot today like this:
> >
> > merkaba:/mnt/debian-zeit> ls -l
> > insgesamt 0
&
Hi!
I tried to create a snapshot today like this:
merkaba:/mnt/debian-zeit> ls -l
insgesamt 0
drwxr-xr-x 1 root root 210 Sep 20 11:48 root
merkaba:/mnt/debian-zeit> btrfs subvol list /
ID 256 gen 21382 top level 5 path root
merkaba:/mnt/debian-zeit> btrfs subvol snap -r root root-2013-09-20
merka
12
drives can fail? And can this provide an advantage over regular replication?
Ciao,
--
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the
Am Freitag, 23. August 2013, 12:29:42 schrieb Xavier Bassery:
> On Fri, 23 Aug 2013 11:38:56 +0200
>
> David Kofler wrote:
> > Hi,
> > can someone tell me which mount options are included in "defaults"
> > mount option? Couldn't find this in BTRFS Wiki. I'm using Debian
> > Wheezy 7.1 and Linux k
Am Dienstag, 6. August 2013, 16:05:50 schrieb Eric Sandeen:
> On 8/6/13 3:45 PM, Filipe David Manana wrote:
> > On Tue, Aug 6, 2013 at 9:37 PM, Eric Sandeen wrote:
> >> On 8/6/13 1:27 PM, Filipe David Borba Manana wrote:
> >>> This change allows for most mount options to be persisted in
> >>> the
Am Samstag, 25. Mai 2013, 23:29:41 schrieb Leonidas Spyropoulos:
> On Sat, May 25, 2013 at 1:13 PM, Martin Steigerwald
> wrote:
> > Am Samstag, 25. Mai 2013, 03:58:12 schrieb Duncan:
> > [...]
> > And can be verified by:
> >
> > martin@merkaba:~> grep s
Am Samstag, 25. Mai 2013, 14:13:07 schrieb Martin Steigerwald:
> The SSD is in use for about 2 years. I left about 25 GiB free of the 300 GB
> it
> has.
>
> merkaba:~> smartctl -a /dev/sda | grep Host
> 225 Host_Writes_32MiB 0x0032 100 100 00
Am Samstag, 25. Mai 2013, 19:36:03 schrieb Martin Steigerwald:
> Hi!
>
> Now I got it myself what I read again and again on this mailinglist: During
> apt-get upgrade I get no space left on device.
>
> But there is:
>
> merkaba:~> df -hT /
> Dateisystem
Hi!
Now I got it myself what I read again and again on this mailinglist: During
apt-get upgrade I get no space left on device.
But there is:
merkaba:~> df -hT /
DateisystemTyp Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/merkaba-debian btrfs 19G 14G 4,6G 76% /
Am Samstag, 25. Mai 2013, 03:58:12 schrieb Duncan:
> Leonidas Spyropoulos posted on Fri, 24 May 2013 23:38:17 +0100 as
>
> excerpted:
> > On 24 May 2013 21:07, "cwillu" wrote:
> >> No need to specify ssd, it's automatically detected.
> >
> > I'm not so sure it did detected. When I manually set i
Am Freitag, 24. Mai 2013, 06:13:04 schrieb Duncan:
> > 2) Due to snapshots I know have well snapshots for my backup. And even
> > on SSD for my /home. I am not yet creating those in an automated way,
> > but well I do use them.
>
> As I already mentioned the warning on the wiki, do be aware of the
Am Donnerstag, 23. Mai 2013, 18:41:11 schrieb George Mitchell:
> On 05/23/2013 09:08 AM, Martin Steigerwald wrote:
> > 3) As to my knowledge mount times of large partitions can be quite
> > long with ReiserFS 3.
>
> That may well be, but I certainly wouldn't consider btr
Am Dienstag, 21. Mai 2013, 13:19:31 schrieb Martin:
> Yep, ReiserFS has stood the test of time very well and I'm still using
> and abusing it still on various servers all the way from something like
> a decade ago!
Very interesting. I only used it for a short time and it worked.
But co-workers lo
Am Sonntag, 19. Mai 2013, 21:43:14 schrieb Zhi Yong Wu:
> On Sun, May 19, 2013 at 6:41 PM, Martin Steigerwald
wrote:
> > Am Donnerstag, 9. Mai 2013, 07:13:56 schrieb Zhi Yong Wu:
[…]
> > ZFS and BTRFS have shown that RAID support within the filesystem can make
> > a lot
Am Donnerstag, 9. Mai 2013, 07:13:56 schrieb Zhi Yong Wu:
> HI, all
Hi!
>I saw that bcache will be merged into kernel upstream soon, so i
> want to know if btrfs hot relocation support is still meanful, if no,
> i will not continue to work on it. can anyone let me know this?
> thanks.
I real
Am Samstag, 11. Mai 2013, 17:57:11 schrieb Tim Eggleston:
> > Yes. The command just triggers the defragmentation which takes place
> > in the
> > background. Try a "sync" afterwards :)
>
> Sorry Martin, I should have specified that I wondered if it was like
> the scrub operation in that respect, s
Am Samstag, 11. Mai 2013, 12:27:09 schrieb Tim Eggleston:
> Hi list,
>
> I have a few large image files (VMware workstation VMDKs and TrueCrypt
> containers) which I routinely back up over the network to a btrfs raid10
> volume via bigsync (https://code.google.com/p/bigsync/).
>
> The VM images i
Hi George!
Am Samstag, 4. Mai 2013, 11:39:59 schrieb George Mitchell:
> the next update. I am using btrfs raid 1 across five 500GB Seagate
> nearline drives and btrfs single on a Seagate 4TB backup drive. I am
> absolutely delighted with how this system is working. This is my
> primary day i
Am Montag, 22. April 2013 schrieb Martin Steigerwald:
> Am Samstag, 20. April 2013 schrieb Josef Bacik:
> > So I found your bug on the plane ride, as soon as I get home I'll email
> > it. Thanks,
>
> Did you get home yet?
>
> I would like to know the impact
errors, but still.
I also still have the backup dd image available for testing.
Thanks,
Martin
> Josef
>
> On Apr 20, 2013 4:43 AM, "Martin Steigerwald" wrote:
> > Am Samstag, 20. April 2013 schrieb Josef Bacik:
> > > On Fri, Apr 19, 2013 at 03:15:30AM -0600, Mart
Am Samstag, 20. April 2013 schrieb Josef Bacik:
> So I found your bug on the plane ride, as soon as I get home I'll email
> it. Thanks,
I have redone my BTRFS now.
But I have a dd image copy on my backup drive in case you have something to
try out for me.
Thanks,
--
Martin 'Helios' Steigerwal
Am Samstag, 20. April 2013 schrieb Josef Bacik:
> On Fri, Apr 19, 2013 at 03:15:30AM -0600, Martin Steigerwald wrote:
> > Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
> > > On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
> > > > Hi!
>
Am Samstag, 20. April 2013 schrieb Josef Bacik:
> On Fri, Apr 19, 2013 at 03:15:30AM -0600, Martin Steigerwald wrote:
> > Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
> > > On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
> > > > Hi!
>
Am Freitag, 19. April 2013 schrieb Liu Bo:
> On Fri, Apr 19, 2013 at 11:15:30AM +0200, Martin Steigerwald wrote:
> > Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
> > > On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
> > > > Hi!
> > > &
Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
> On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
> > Hi!
> >
> > Please answer soon whether it would be a good idea to replay a backup
> > right now as I am leaving to Berlin tomorrow for a week witho
On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
> Hi!
>
> Please answer soon whether it would be a good idea to replay a backup
> right now as I am leaving to Berlin tomorrow for a week without my backup
> drive with me. Well, I made space on an external 2,5 inch driv
On Saturday 13 April 2013 17:48:31 you wrote:
> Hi!
>
> Please answer soon whether it would be a good idea to replay a backup
> right now as I am leaving to Berlin tomorrow for a week without my backup
> drive with me. Well, I made space on an external 2,5 inch drive, that I
> can take with me. I
201 - 300 of 514 matches
Mail list logo
