An other Information needed ?
Am 18. April 2017 21:34:33 MESZ schrieb Jan Koester :
>
>Hi,
>
>i have to try to create a new extent-tree after checksum error not
>solveable with srub or init-csum-tree.
>Now i got this failure output from btrfs --repair:
>
>ERROR: errors found in extent allocation
On Thu, Apr 20, 2017 at 3:13 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Adam Borowski posted on Wed, 19 Apr 2017 23:07:45 +0200 as excerpted:
>
>> Too many people come complaining about losing their data -- and indeed,
>> there's no warning outside a wiki and the mailing list tribal knowledge.
>> M
Adam Borowski posted on Wed, 19 Apr 2017 23:07:45 +0200 as excerpted:
> Too many people come complaining about losing their data -- and indeed,
> there's no warning outside a wiki and the mailing list tribal knowledge.
> Message severity chosen for consistency with XFS -- "alert" makes dmesg
> pro
On Thu, Apr 20, 2017 at 10:09:39AM +0800, Qu Wenruo wrote:
>
>
> At 04/20/2017 09:58 AM, Liu Bo wrote:
> > On Thu, Apr 20, 2017 at 09:52:00AM +0800, Qu Wenruo wrote:
> > >
> > >
[...]
> > > >
> > > > If I understand it correctly, what it's missing currently is 'merge', a
> > > > straightfoward
Hi Elena,
On Thu, Apr 20, 2017 at 04:10:16PM +, Reshetova, Elena wrote:
>
> > All the objections from DaveM on the amount of cycles spent on the
> > new refcount_t apply to the block layer fast path operations as well.
>
> Ok, could you please indicate the correct way to measure the impact f
On Wed, Apr 12 2017, Jan Kara wrote:
> Hello,
>
> this is the third revision of the patch series which converts all embedded
> occurences of struct backing_dev_info to use standalone dynamically allocated
> structures. This makes bdi handling unified across all bdi users and generally
> removes so
> All the objections from DaveM on the amount of cycles spent on the
> new refcount_t apply to the block layer fast path operations as well.
Ok, could you please indicate the correct way to measure the impact for the
block layer?
We can do the measurements.
Best Regards,
Elena.
>
> Please d
On Wed 19-04-17 10:21:39, Goldwyn Rodrigues wrote:
>
>
> On 04/19/2017 01:45 AM, Christoph Hellwig wrote:
> >
> >> + if (bio->bi_opf & REQ_NOWAIT) {
> >> + if (!blk_queue_nowait(q)) {
> >> + err = -EOPNOTSUPP;
> >> + goto end_io;
> >> + }
> >>
All the objections from DaveM on the amount of cycles spent on the
new refcount_t apply to the block layer fast path operations as well.
Please don't send any more conversions until those have been resolved.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of
On 2017-04-19 13:39, Chris Murphy wrote:
http://www-rhstorage.rhcloud.com/blog/vpodzime/reporting-and-monitoring-storage-events
I think the most useful part of this would be standardized messaging.
For the exact same defect state on disk (data corruption), I get two
different formatted messages
On Thu, Apr 20, 2017 at 04:07:56PM +0800, Lu Fengqi wrote:
> Without validation of array_size, the dump-super may lead to a bad
> memory access.
>
> Signed-off-by: Lu Fengqi
1-2 applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-
changes in v2:
Not needed WARNs are removed since refcount_t warns by itself.
BUG_ONs are left as it is, since refcount_t doesn't bug by default.
This series, for block subsystem, replaces atomic_t reference
counters with the new refcount_t type and API (see include/linux/refcount.h).
By doing thi
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-
In print_chunk, validate the value of uuid_offset when read the dev_uuid of
stripe.
Signed-off-by: Lu Fengqi
---
cmds-inspect-dump-super.c | 1 +
print-tree.c | 20 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/cmds-inspect-dump-super.c b/cmds-
Without validation of array_size, the dump-super may lead to a bad
memory access.
Signed-off-by: Lu Fengqi
---
v2:
Accept David's advice, no longer use BTRFS_SUPER_INFO_SIZE instead of
sizeof(*sb).
---
cmds-inspect-dump-super.c | 11 +--
1 file changed, 9 insertions(+), 2 deleti
On Thu, Apr 13, 2017 at 10:45:09AM +0200, Marc Haber wrote:
> On Tue, Apr 11, 2017 at 06:15:02PM +0200, Adam Borowski wrote:
> > Ouch, this is generally harmless unless your disk lies about barriers.
> > Btrfs absolutely depends on them, and tends to suffer catastrophic
> > corruption if writes we
20 matches
Mail list logo