Adam Borowski posted on Sun, 08 May 2016 01:11:18 +0200 as excerpted:
> Duncan wrote:
>> > btrfs_destroy_inode
>
>> That's a known apparent false-positive warning on current 4.6-rc kernel
>> btrfs. The destroy-inode bit is related to a file deletion happening
>> in the normal order of things, wh
06.05.2016 22:27, Jeff Mahoney пишет:
> Systemd's btrfs rule runs btrfs dev ready on each device
> as it's discovered. The btrfs command is executed as a builtin
> command via an IMPORT{builtin} rule, which means it gets
> executed at rule evaluation time, not rule execution time. That
> means th
On 07/05/16 10:39, g6094...@freenet.de wrote:
> a brand new disk which has an upcounting raw error rate
Note that is the "raw error rate".
For a brand new disk being run for the first time at maximum data
writes, the "raw error rate" may well be expected to increase. Hard
disks deliberately make
On Sat, May 7, 2016 at 9:45 AM, Niccolò Belli wrote:
> btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
> So discard is not the culprit. Will try to remove compress=lzo and
> autodefrag and see if it still happens.
You're making the troubleshooting unnecessarily difficult by
Duncan wrote:
> > btrfs_destroy_inode
> That's a known apparent false-positive warning on current 4.6-rc kernel
> btrfs. The destroy-inode bit is related to a file deletion happening in
> the normal order of things, where this warning code is run, and
> apparently triggers even under normal op
Hello,
btrfs send puts a “At subvol …” on stderr, which is very annoying in
scripts, esp. cron-jobs. Piping stderr to /dev/null does suppress this
message, but also error-messages which one would probably want to
see. I added an option to not change the behavior of btrfs send
and possibly break ex
Il 2016-05-07 17:58 Clemens Eisserer ha scritto:
Hi Niccolo,
btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
Just to be curious - couldn't it be a hardware issue? I use almost the
same setup (compress-force=lzo instead of compress-force=lzo) on my
laptop for 2-3 years a
Hi Niccolo,
> btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
Just to be curious - couldn't it be a hardware issue? I use almost the
same setup (compress-force=lzo instead of compress-force=lzo) on my
laptop for 2-3 years and haven't experienced any issues since
~kernel-3.1
btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
So discard is not the culprit. Will try to remove compress=lzo and
autodefrag and see if it still happens.
[ 748.224346] BTRFS error (device dm-0): memmove bogus src_offset 5431
move len 4294962894 len 16384
[ 748.226206
Am Saturday 07 May 2016
schrieb Marc Joliet
>I'm thinking of filing
>a bug report with dovecot; perhaps none of their devs test with btrfs?
So I did this, and got a little bit of feedback. Quoting from the reply I
got:
"*.index.log files are always appended to using O_APPEND flag. Maybe this
Am Thu, 5 May 2016 08:35:37 +0200
schrieb Kai Krakow :
> Am Tue, 3 May 2016 08:48:14 +0200
> schrieb Kai Krakow :
>
> > Am Sun, 1 May 2016 20:39:31 -0400
> > schrieb Nicholas D Steeves :
> >
> > > On 1 May 2016 at 03:00, Kai Krakow
> > > wrote:
> [...]
> > >
> > > Out of curiosity, do
Thanks,
I hoped there was something like an hidden recursive flag to avoid the
tedious task of snapshotting all the nested subvolumes or deleting the
nested ones, but it seems there isn't.
I usually don't want to keep things like /var/cache/pacman/pkg, but since
I'm just doing some tests I didn
He guys,
i'm running in an rare error which isnt covered by an implemented usecase atm.i
have a 4 hdd raid5 array. i like to replace the 4 disks with bigger ones to
gain more usable space the NAS has only 4 drive bays so i need to use an usb
bay.
since the replace code was unreliable at least b
13 matches
Mail list logo
