ork with the feature matrix already there and fill in
information about stability. I think it makes sense tough to discuss first on
how to do it with still keeping it manageable.
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the
Am Mittwoch, 7. September 2016, 11:53:04 CEST schrieb Christian Rohmann:
> On 03/20/2016 12:24 PM, Martin Steigerwald wrote:
> >> btrfs kworker thread uses up 100% of a Sandybridge core for minutes on
> >>
> >> > random write into big file
> >> > http
> That really is the case, there's currently no way to do this with BTRFS.
> You have to keep in mind that the raid5/6 code only went into the mainline
> kernel a few versions ago, and it's still pretty immature as far as kernel
> code goes. I don't know when (if ever) such a feature might get
> Looking at the kernel log itself, you've got a ton of write errors on
> /dev/sdap. I would suggest checking that particular disk with smartctl, and
> possibly checking the other hardware involved (the storage controller and
> cabling).
>
> I would kind of expect BTRFS to crash with that many
>> The smallest disk of the 122 is 500GB. Is it possible to have btrfs
>> see each disk as only e.g. 10GB? That way I can corrupt and resilver
>> more disks over a month.
>
> Well, at least you can easily partition the devices for that to happen.
Can it be done with btrfs or should I do it with
>> I'm not sure what Arch does any differently to their kernels from
>> kernel.org kernels. But bugzilla.kernel.org offers a Mainline and
>> Fedora drop down for identifying the kernel source tree.
>
> IIRC, they're pretty close to mainline kernels. I don't think they have any
> patches in the
corrupt and resilver
more disks over a month.
On 4 August 2016 at 23:12, Chris Murphy <li...@colorremedies.com> wrote:
> On Thu, Aug 4, 2016 at 2:51 PM, Martin <rc6encryp...@gmail.com> wrote:
>> Thanks for the benchmark tools and tips on where the issues might be.
>&
Thanks for the benchmark tools and tips on where the issues might be.
Is Fedora 24 rawhide preferred over ArchLinux?
If I want to compile a mainline kernel. Are there anything I need to tune?
When I do the tests, how do I log the info you would like to see, if I
find a bug?
On 4 August 2016
snapshotting reducing metadata workload. Then you could create read-only
snapshots from the UrBackup sub-volumes and use e.g. buttersink to copy
those to another btrfs.
So maybe try that?
Regards,
Martin
smime.p7s
Description: S/MIME Cryptographic Signature
.btrfs, mkfs.xfs and so on. I´d like that, but that would be a suggestions
for the coreutils people.
Yes, Unix is for people who know what they are doing… unless they don´t. And
in the end even one of the most experienced admin could make such a mistake.
Goodnight,
--
Martin
--
To unsub
> I would say it is, but I also don't have quite as much experience with it as
> with BTRFS raid1 mode. The one thing I do know for certain about it is that
> even if it theoretically could recover from two failed disks (ie, if they're
> from different positions in the striping of each mirror),
> Make certain the kernel command timer value is greater than the driver
> error recovery timeout. The former is found in sysfs, per block
> device, the latter can be get and set with smartctl. Wrong
> configuration is common (it's actually the default) when using
> consumer drives, and inevitably
> In general, avoid Ubuntu LTS versions when dealing with BTRFS, as well as
> most enterprise distros, they all tend to back-port patches instead of using
> newer kernels, which means it's functionally impossible to provide good
> support for them here (because we can't know for sure what exactly
> Before trying RAID5/6 in production, be sure to read posts like these:
>
> http://www.spinics.net/lists/linux-btrfs/msg55642.html
Very interesting post and very recent even.
If I decide to try raid6 and of course everything is replicated each
day (for a bit of a safety net), and disks begin to
> Do you plan to use Snapshots? How many of them?
Yes, minimum 7 for each day of the week.
Nice to have would be 4 extra for each week of the month and then 12
for each month of the year.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
Hello,
We would like to use urBackup to make laptop backups, and they mention
btrfs as an option.
https://www.urbackup.org/administration_manual.html#x1-8400010.6
So if we go with btrfs and we need 100TB usable space in raid6, and to
have it replicated each night to another btrfs server for
o desktop environments wishing to make use of
snapshot functionality or advanced disk usage reporting for example can easily
make use of it without calling external commands.
Of course it would likely me more effort than to implement structured output.
Thanks,
--
Martin
--
To unsubscribe from t
ad the man page first. (Hint: Non-destructive
is slow, destructive write is fast...)
Good luck,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dne 22.4.2016 v 23:00 Nicholas D Steeves napsal(a):
> On 21 April 2016 at 18:44, Chris Murphy <li...@colorremedies.com> wrote:
>> On Thu, Apr 21, 2016 at 6:53 AM, Martin Svec <martin.s...@zoner.cz> wrote:
>>> Hello,
>>>
>>> we use btrfs subvolum
Dne 22.4.2016 v 0:44 Chris Murphy napsal(a):
> On Thu, Apr 21, 2016 at 6:53 AM, Martin Svec <martin.s...@zoner.cz> wrote:
>> Hello,
>>
>> we use btrfs subvolumes for rsync-based backups. During backups btrfs often
>> fails with "No space
>> left&qu
ultiple times:
https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg48061.html
https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg47355.html
Best regards
Martin Svec
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
On Freitag, 8. April 2016 11:12:54 CEST Hugo Mills wrote:
> On Fri, Apr 08, 2016 at 01:01:03PM +0200, Martin Steigerwald wrote:
> > Hello!
> >
> > As far as I understood, for differential btrfs send/receive – I didn´t use
> > it yet – I need to keep a snapshot on the
that generation number + the
destination snapshots.
Well, or get larger SSDs or get rid of some data on them.
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
ands
> like "du" and "df" hang until reboot.
>
> I've now restored the file from backup but it happens over and over
> again.
Just as another data point I am irregularily using a VM with Virtualbox in a
VDI file on a BTRFS RAID 1 on two SSDs and had no such issue
size back to max.
>
> It doesn't:
> [20/518]mh@fan:~$ sudo btrfs filesystem resize 300G /media/tempdisk/
> Resize '/media/tempdisk/' of '300G'
> [22/520]mh@fan:~$ sudo btrfs check /media/tempdisk/
> Superblock bytenr is larger than device size
> Couldn't open file system
> [23
Works for me, thanks.
Martin Volf
On Mon, Mar 21, 2016 at 1:23 PM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
> Currently, btrfs fi du uses open_file_or_dir(), which tries to open
> it's argument with o_RDWR. Because of POSIX semantics, this fails for
> non-root user
= 1
write(1, " Total Exclusive Set shar"..., 3161) = 3161
exit_group(1) = ?
+++ exited with 1 +++
Read-only snapshots give Unknown error -1 too, this time EROFS.
Is it expected?
--
Martin Volf
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body o
once about fs benchmarks running faster in Virtualbox than on
the physical system, which may point at an at least incomplete fsync()
implementation for writing into Virtualbox image files.
I never found any proof of this nor did I specificially seeked to research it.
So it may be
image
I use 4.3 backport kernel successfully on two server VMs which use BTRFS.
[1] http://backports.debian.org/
Thx,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hing that does file name encryption like ecryptfs or the Ext4/F2FS
approach, but if the subvolume specifics of BTRFS can be used to encrypted
more of the metadata then even better!
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a me
On Sonntag, 13. Dezember 2015 23:35:08 CET Martin Steigerwald wrote:
> Hi!
>
> For me it is still not production ready. Again I ran into:
>
> btrfs kworker thread uses up 100% of a Sandybridge core for minutes on
> random write into big file
> https://bugzilla.kernel.org/sho
nk you all for your help. Now I'm on 4.5.0-rc6-mainline with pointed
patch and issue seems to be resolved.
Thank you for your time!
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordo
On 5.3.2016 06:34, Duncan wrote:
Chris Murphy posted on Fri, 04 Mar 2016 19:46:34 -0700 as excerpted:
On Fri, Mar 4, 2016 at 4:16 PM, Martin Mlynář <ne...@smoula.net> wrote:
[Mount options line split/wrapped for followup]
rw,noatime,nodatasum,nodatacow,ssd,discard,space
72GiB
32 GiB chunks allocated, only 3,72 GiB used.
Maybe that way you can gain more free space to have a full balance run.
Also note that it is not necessary to do a full balance in case everything
works okayish.
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ng been re-written excessively too many times due to a fixed
repeatedly used filesystem block?)
Any other comparisons/thoughts for btrfs vs f2fs?
Thanks for any comment,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@
hink it doesn´t need to recreate the
filesystem.
I wonder what happened to the VFS hot data tracking stuff patchset floating
around here quite some time ago.
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
o be the case with storage
related commands in GNU/Linux.
I don´t have a clear oppinion about it other than I´d like to see some
standard too. coreutils / util-linux both them to have some kind of standard,
although not necessarily the same standard I bet. And I am not sure whether it
is docum
y the REQ_ prefix in bios since the flags were
consolidated a while back. When I attempted to fix the READ/WRITE mess I
used a BLK_ prefix as a result.
Anyway. Just bikeshedding...
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe l
ces and everything looks sensible to me.
I wonder what the best approach is to move a patch set with this many
stakeholders forward? Set a "speak now or forever hold your peace"
review deadline?
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list:
be wiped and recreated with a mkfs.btrfs
> without the bug, to fix.
btrfs check from btrfs tools 4.3.1 on kernel 4.4-rc6 has not been able to fix
these errors and I recreated the filesystem that had the errors. I think I
mentioned it also in this thread.
Thanks,
--
Martin
--
To unsubscribe
Am Sonntag, 3. Januar 2016, 17:33:03 CET schrieb John Center:
> Hi Martin,
Hi John,
> One thing I forgot, I did run btrfs-image & it appears to have successfully
> completed afaict. Do you think it would be useful to someone for future
> troubleshooting?
I leave that to th
Am Samstag, 2. Januar 2016, 18:27:16 CET schrieb John Center:
> Hi Martin,
>
> > On Jan 2, 2016, at 6:41 AM, Martin Steigerwald <mar...@lichtvoll.de>
>
> wrote:
> > Am Samstag, 2. Januar 2016, 11:35:51 CET schrieb Martin Steigerwald:
> >> Am Freitag, 1.
Am Sonntag, 3. Januar 2016, 02:02:12 CET schrieb John Center:
> Hi Martin & Duncan,
Hi John,
> Since I had a backup of my data, I first ran "btrfs check -p" on the
> unmounted array. It first found 3 parent transid errors:
>
> root@ubuntu:~# btrfs check -p /dev/
It refuses to rm -rf . or rm -rf .. and rm -rf / (unless you give special
argument, but there is not much it can do about rm -r /*, as the shell expands
this before handing it to the command.
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-bt
try to use btrfs restore for
restoring them.
5) Then, if you made sure you have an up-to-date backup run
btrfs --repair
Also watch out for other guidance you may receive her. My approach is based on
what I would do. I never had the need to repair a BTRFS filesystem so far.
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
n SSD to use for hot data.
Or is this something different?
Happy New Year and thanks,
Martin
> Signed-off-by: Sanidhya Solanki <jpage.l...@gmail.com>
> ---
> fs/btrfs/Makefile | 2 +-
> fs/btrfs/cache.c | 58
> +++ 2 files change
Am Samstag, 2. Januar 2016, 11:35:51 CET schrieb Martin Steigerwald:
> Am Freitag, 1. Januar 2016, 20:04:43 CET schrieb John Center:
> > Hi Duncan,
> >
> > On Fri, Jan 1, 2016 at 12:05 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> > > John Center poste
un a scrub
again after the repair attempt. And if its good I will play it safe and redo
the filesystem from scratch.
It may have been I used a mkfs.btrfs from 4.1.1 for creating it. Would be good
if it stored the version of the tool that created the fs into the fs itself to
be able to know
Am Freitag, 1. Januar 2016, 13:20:49 CET schrieb John Center:
> > On Jan 1, 2016, at 12:41 PM, Martin Steigerwald <mar...@lichtvoll.de>
> > wrote:
> > Am Freitag, 1. Januar 2016, 11:41:20 CET schrieb John Center:
[…]
> >>> On Jan 1, 2016, at 12:55 AM,
0:08:16AM +0800, Qu Wenruo wrote:
> >> Martin Steigerwald wrote on 2015/12/13 23:35 +0100:
> >>> Hi!
> >>>
> >>> For me it is still not production ready.
> >>
> >> Yes, this is the *FACT* and not everyone has a good reason to deny it.
>
ed in another thread here, until I
used 4.4 kernel. With 4.3 kernel scrub also didn´t work. I didn´t use the
debug options you used above and I am not sure whether I had this scrub issue
with 4.2 already, so I am not sure it has been the same issue. But you may
need to run 4.4 kernel in order to
nsists of a patch set to
add hot data tracking to VFS and a patch set for adding support in BTRFS. But
I didn´t see anything of these in quite some time.
Happy christmas,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Mittwoch, 16. Dezember 2015, 00:18:53 CET schrieb Martin Steigerwald:
> Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald:
> > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie:
> > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steig
Am Dienstag, 15. Dezember 2015, 16:59:58 CET schrieb Chris Mason:
> On Mon, Dec 14, 2015 at 10:08:16AM +0800, Qu Wenruo wrote:
> > Martin Steigerwald wrote on 2015/12/13 23:35 +0100:
> > >Hi!
> > >
> > >For me it is still not production ready.
> >
> &
Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald:
> Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie:
> > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald:
> > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin
Stei
Qu Wenruo:
> Martin Steigerwald wrote on 2015/12/14 09:18 +0100:
> > Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo:
> >> Martin Steigerwald wrote on 2015/12/13 23:35 +0100:
[…]
> >>> I am seriously consider to switch to XFS for my production laptop agai
Am Sonntag, 13. Dezember 2015, 15:19:14 CET schrieb Marc MERLIN:
> On Sun, Dec 13, 2015 at 11:35:08PM +0100, Martin Steigerwald wrote:
> > Hi!
> >
> > For me it is still not production ready. Again I ran into:
> >
> > btrfs kworker thread uses up 100%
Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie:
> Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald:
> > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald:
> > > I get this:
> > >
> > > merkaba:~> btr
Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo:
> Martin Steigerwald wrote on 2015/12/13 23:35 +0100:
> > Hi!
> >
> > For me it is still not production ready.
>
> Yes, this is the *FACT* and not everyone has a good reason to deny it.
>
> > Agai
Hi Qu.
I reply to the journal fs things in a mail with a different subject.
Am Montag, 14. Dezember 2015, 16:48:58 CET schrieb Qu Wenruo:
> Martin Steigerwald wrote on 2015/12/14 09:18 +0100:
> > Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo:
> >> Martin Steiger
on ready* filesystem.
I am seriously consider to switch to XFS for my production laptop again. Cause
I never saw any of these free space issues with any of the XFS or Ext4
filesystems I used in the last 10 years.
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "un
_need_killpriv+0x33/0x50
[414675.259029] [] btrfs_file_write_iter+0x171/0x560 [btrfs]
[414675.259035] [] __vfs_write+0xa7/0xf0
[414675.259040] [] vfs_write+0xa6/0x1a0
[414675.259046] [] ? __do_page_fault+0x1b4/0x400
[414675.259051] [] SyS_write+0x46/0xa0
[414675.259055] [] entry_SYSCAL
ardware a fsck run can report bogus data, i.e. problems
where they are none or vice versa. If I suspect defect memory or controller I
would check the device on different hardware only. Especially on attempts to
repair any possible issues.
--
Martin
--
To unsubscribe from this list: send the
Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald:
> Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald:
> > I get this:
> >
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /d
Am Dienstag, 24. November 2015, 00:13:08 CET schrieb Christoph Hellwig:
> On Fri, Nov 20, 2015 at 05:19:31PM +0100, Martin Steigerwald wrote:
> > I know its mostly relevant for just for FAT32, but on any account rather
> > than trying to write 4 GiB and then file, it would be
ile as argument and give a clearer error message
in this case?
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
give much of a
> benefit unless the target file is nocow.
>
> (Also I thought only certain other utilities had supercow powers, but well
> BTRFS seems to have them as well :)
Anyone any idea?
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald:
> I get this:
>
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/mapper/sata-debian (id 1) history
> scrub started at Thu Oct 22 10:05:49 2015 and was abor
No errors in dmesg, btrfs device stat or smartctl -a.
Any known issue?
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
– but it wouldn´t give much of a
benefit unless the target file is nocow.
(Also I thought only certain other utilities had supercow powers, but well
BTRFS seems to have them as well :)
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the
ation in btrfs - but I'm
lacking the bigger picture and the explicit use case for btrfs in this
setup?
hops.io looks very interesting through. Would be great if you could
clarify your ideas a little bit.
HTH & regards
Martin
--
To unsubscribe from this list: send the line "unsubscribe lin
Hi,
the commit "Btrfs: incremental send, check if orphanized dir inode needs
delayed rename" causes incremental send/receive to fail if a file is
unlinked and then reflinked to the same location from the parent
snapshot. An xfstest reproducing the issue is attached.
Regards,
M
randomly like some common ones do. But take care about the hard
disk write cache, which should be off.
http://xfs.org/index.php/
XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.
3F
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nd performance is not a top priority at this stage but I
don't see why it shouldn't perform at least equally good as ZFS/F2FS
on the same workloads. Is looking at performance problems on the
development roadmap?
regards
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-
4.55TiB used 7.38GiB path /dev/sde
*** Some devices missing
btrfs fi df
Data, RAID5: total=21.00GiB, used=18.30GiB
System, RAID5: total=96.00MiB, used=16.00KiB
Metadata, RAID5: total=1.03GiB, used=19.59MiB
GlobalReserve, single: total=16.00MiB, used=0.00B
dmesg attached.
Thanks,
Martin
Elasticsearch/Hadoop) when the OOM
killer is triggered.
Looks like you are using Linux 3.19 - but I've seen the issue also on
4.0 and 4.1.
regards
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info
!
And all still 'experimental'... ;-)
Carry on the good developments!
Regards,
Martin
On 17/08/15 23:44, George Mitchell wrote:
Two years ago I installed btrfs across 8 hard drives on my desktop
system with the entire system ending up on btrfs RAID 1. I did all of
this with btrfs-progs-0.20
good, but
generation/level doesn't match, want gen: 390924 level: 1
regards
Martin
1:
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#parent_transid_verify_failed
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
- or is the broken Image of
any use for anyone? It's a 4TB disk but I guess I could create a
compressed (partial) image if it's of interest to anyone.
regards
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
?
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
,
--
Martin
signature.asc
Description: This is a digitally signed message part.
Am Samstag, 11. Juli 2015, 10:40:29 schrieb erp...@gmail.com:
On Sat, Jul 11, 2015 at 4:12 AM, Martin Steigerwald mar...@lichtvoll.de
wrote:
Always do sync after a btrfs fi defrag and before measuring with
filefrag. The kernel may not have written everything. I have seen this
repeatedly
---
eric@europa:~/filefrag/2015-07-09$ filefrag
/home/.ecryptfs/eric/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWbZ4j3re5lQYkQsG5Uh
[…]
Nice, someone like me searching the correspondending file name in ecryptfs
for defragmenting :)
Thanks,
--
Martin
--
To unsubscribe from this list: send
, just in case.)
Also does blkid and/or file-sk onto each device show that the BTRFS
signatures are still there?
--
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
:
errno=-17 Object already exists
regards
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
:
errno=-17 Object already exists
regards
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
extent tree bytes: 243171328
btree space waste bytes: 253506582
file data blocks allocated: 724722012160
referenced 848544292864
btrfs-progs v4.0
regards
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
?
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
Do you know, where I can find this kernel-patch because I didn't find it. Then
I will build the patched kernel and send the devlist-output.
Thanks, Martin
Am Freitag, 12. Juni 2015, 18:38:18 schrieb Anand Jain:
On 06/11/2015 09:03 PM, Martin wrote:
It is reproduceable but the logs doesn't
[151214.513046] BTRFS: too many missing devices, writeable mount is not
allowed
[151214.548566] BTRFS: open_ctree failed
Can I get more info out of the kernel-module?
Thanks, Martin
Am Donnerstag, 11. Juni 2015, 08:04:04 schrieb Anand Jain:
On 10 Jun 2015, at 5:35 pm, Martin deve...@imagmbh.de wrote
an and was rebooted some times, mounting degraded,rw works
- suddentlym mounting degraded,rw stops working and only degraded,ro works.
Thanks, Martin
Am Mittwoch, 10. Juni 2015, 15:46:52 schrieb Anand Jain:
On 06/10/2015 02:58 PM, Martin wrote:
Hello Anand,
the
mount -o degraded good-disk
because all the btrfs-
commands need rw-access ...
Martin
Am Mittwoch, 10. Juni 2015, 14:38:38 schrieb Anand Jain:
Ah thanks David. So its 2 disks RAID1.
Martin,
disk pool error handle is primitive as of now. readonly is the only
action it would take. rest of recovery action is manual
the missing drive and add a new one?
Because there are many snapshots of the filesystem, copying the system would
be only the last alternative ;-)
Thanks
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
a newer kernel for that device, I would not use it
with BRFS.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
headache.
I am entirely in favor of this patch.
It was a big chunk of changes to read through but I did not spot any
obvious problems or polarity reversals. It would be nice to get the
respective fs/md/target driver folks to check their portions, though.
Reviewed-by: Martin K. Petersen martin.peter
100% of a Sandybridge core
for minutes on random write into big file
https://bugzilla.kernel.org/show_bug.cgi?id=90401
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line unsubscribe
Hi Duncan,
Beyond this corrupted file, is my disk dead?
Can I repair the file system or re-create a new one on the same disk?
A direct answer is beyond my knowledge level, certainly without SMART
status information, etc.
I attach the result of `smartctl -x` below.
Best regards,
--Martin
Hi Duncan,
The kernel log (dmesg, also logged to syslog/journald on most systems)
from during the scrub should capture more information on those errors.
Thanks. The dmesg log indeed contains the file path (see below).
The error is in /home/martin/X. It is related to a low-level error
errors: 0, uncorrectable errors: 13, unverified errors: 0
Before going to my backups, how can know the files impacted by those
uncorrectable errors?
Best regards,
--Martin
On 04/18/2015 09:45 AM, Martin Monperrus wrote:
Dear Btrfs developers,
For some unknown reasons, my BTRFS filesystem
Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills:
On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote:
Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer:
On 19 April 2015 at 22:28, Martin Steigerwald mar...@lichtvoll.de
wrote:
Am Sonntag, 19. April 2015
101 - 200 of 781 matches
Mail list logo
