On Mon, Apr 16, 2018 at 7:07 PM, Dave Chinner wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>> Thanks! As I mentioned before, this is useful. I have a follow-up
>> question. Consider the following workload:
>>
>> creat foo
>> link (foo, A/bar)
There are already 2 reports about strangely corrupted super blocks,
where csum still matches but extra garbage gets slipped into super block.
The corruption would looks like:
--
superblock: bytenr=65536, device=/dev/sdc1
-
csum_type
On 2018年04月17日 00:07, Tom Vincent wrote:
> On 12 April 2018 at 00:25, Qu Wenruo wrote:
>> I'm curious about what's the underlying disk?
>
> It's an Samsung PM951 NVMe SSD.
>
>> Is it plain physical device? Or have other layers like bcache/lvm?
>
> btrfs on LUKS
>
>>>
On 2018/04/17 2:53, David Sterba wrote:
> On Wed, Apr 11, 2018 at 02:20:49PM +0900, Misono Tomohiro wrote:
>> Use btrfs_delete_subvolume() to refactor btrfs_ioctl_snap_destroy().
>> The permission check is still done in btrfs_ioctl_snap_destroy(). Also,
>> call of d_delete() is still required
On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
> Thanks! As I mentioned before, this is useful. I have a follow-up
> question. Consider the following workload:
>
> creat foo
> link (foo, A/bar)
> fsync(foo)
> crash
>
> In this case, after the file system recovers, do we
On 2018年04月17日 01:27, David Sterba wrote:
> On Mon, Apr 16, 2018 at 04:53:10PM +0900, Misono Tomohiro wrote:
>> On 2018/04/12 22:13, David Sterba wrote:
>>> On Tue, Apr 03, 2018 at 03:30:34PM +0800, Qu Wenruo wrote:
I didn't see this patch merged in your misc-next branch but only the
Hello
Greeetings to you please did you get my previous email regarding my
investment proposal last week friday ?
MS.Zeliha ömer faruk
zeliha.omer.fa...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
On Wed, Apr 11, 2018 at 10:59:09AM +0300, Nikolay Borisov wrote:
> When the delayed refs for a head are all run, eventually
> cleanup_ref_head is called which (in case of deletion) obtains a
> reference for the relevant btrfs_space_info struct by querying the bg
> for the range. This is
On 16.04.2018 21:53, David Sterba wrote:
> On Wed, Apr 11, 2018 at 11:21:20AM +0300, Nikolay Borisov wrote:
>> do_chunk_alloc implements logic to detect whether there is currently
>> pending chunk allocation (by means of space_info->chunk_alloc being
>> set) and if so it loops around to the
On Thu, Apr 12, 2018 at 10:29:23AM +0800, Anand Jain wrote:
> uuid_mutex lock is not a per-fs lock but a global lock. The main aim of
> this patch-set is to critically review the usage of this lock, and delete
> the unnecessary once. By doing this we improve the concurrency of
> device operations
On Mon, Apr 16, 2018 at 09:55:45PM +0200, René Rebe wrote:
> Hi,
>
> On 04/16/2018 06:48 PM, David Sterba wrote:
> > The warnings are valid, there's unaligned access introduced by patch
> >
> > 23b5ec74943f44378b68c0edd8e210a86318ea5e
> > btrfs: fix readdir deadlock with pagefault
> >
> > The
On Mon, Apr 16, 2018 at 09:00:38PM +0800, Qu Wenruo wrote:
>
>
> On 2018年04月16日 20:55, Anand Jain wrote:
> >
> >
> > On 04/16/2018 10:02 AM, Qu Wenruo wrote:
> >> There are already 2 reports about strangely corrupted super blocks,
> >> where csum type and incompat flags get some obvious
On Mon, Apr 16, 2018 at 10:02:27AM +0800, Qu Wenruo wrote:
> There are already 2 reports about strangely corrupted super blocks,
> where csum type and incompat flags get some obvious garbage, but csum
> still matches and all other vitals are correct.
>
> This normally means some kernel memory
On Wed, Apr 11, 2018 at 11:21:20AM +0300, Nikolay Borisov wrote:
> do_chunk_alloc implements logic to detect whether there is currently
> pending chunk allocation (by means of space_info->chunk_alloc being
> set) and if so it loops around to the 'again' label. Additionally,
> based on the state
On Wed, Apr 11, 2018 at 11:21:19AM +0300, Nikolay Borisov wrote:
> The second if is really a subcase of ret being less than 0. So
> introduce a generic if (ret < 0) check, and inside have another if
> which explicitly handles the -ENOSPC and any other errors. No
> functional changes.
>
>
On Wed, Apr 11, 2018 at 11:21:18AM +0300, Nikolay Borisov wrote:
> Locks should generally be released in the oppposite order they are
> acquired. Generally lock acquisiton ordering is used to ensure
> deadlocks don't happen. However, as becomes more complicated it's
> best to also maintain proper
On Wed, Apr 11, 2018 at 11:21:17AM +0300, Nikolay Borisov wrote:
> Currently __endio_write_update_ordered uses labels to implement
> what is essentially a simple while loop. This makes the code more
> cumbersome to follow than it actually has to be. No functional
> changes. No xfstest regressions
On Wed, Apr 11, 2018 at 02:20:49PM +0900, Misono Tomohiro wrote:
> Use btrfs_delete_subvolume() to refactor btrfs_ioctl_snap_destroy().
> The permission check is still done in btrfs_ioctl_snap_destroy(). Also,
> call of d_delete() is still required since btrfs_delete_subvolume()
> does not call
Hi,
On 04/16/2018 06:48 PM, David Sterba wrote:
The warnings are valid, there's unaligned access introduced by patch
23b5ec74943f44378b68c0edd8e210a86318ea5e
btrfs: fix readdir deadlock with pagefault
The directory entries (struct dir_entry) are copied to a temporary
buffer as they fit, ie.
On Mon, 16 Apr 2018, Chris Murphy wrote:
> Adding linux-usb@ and linux-scsi@
> (This email does contain the thread initiating email, but some replies
> are on the other lists.)
>
> On Mon, Apr 16, 2018 at 5:43 AM, Austin S. Hemmelgarn
> wrote:
> > On 2018-04-15 21:04,
On Mon, Apr 16, 2018 at 04:53:10PM +0900, Misono Tomohiro wrote:
> On 2018/04/12 22:13, David Sterba wrote:
> > On Tue, Apr 03, 2018 at 03:30:34PM +0800, Qu Wenruo wrote:
> >> I didn't see this patch merged in your misc-next branch but only the
> >> remaining patches.
> >>
> >> However without
Adding linux-usb@ and linux-scsi@
(This email does contain the thread initiating email, but some replies
are on the other lists.)
On Mon, Apr 16, 2018 at 5:43 AM, Austin S. Hemmelgarn
wrote:
> On 2018-04-15 21:04, Chris Murphy wrote:
>>
>> I just ran into this:
>>
>>
On Mon, Apr 16, 2018 at 04:52:16PM +0200, René Rebe wrote:
> I just installed the latest #t2sde test build on a sparc64 system with
> btrfs rootfs - you know, just for the fun of testing, and in contrast
> to my x86 and ppc systems I get tons of unaligned access warnings, in
> the form of:
>
> [
On 12 April 2018 at 00:25, Qu Wenruo wrote:
> I'm curious about what's the underlying disk?
It's an Samsung PM951 NVMe SSD.
> Is it plain physical device? Or have other layers like bcache/lvm?
btrfs on LUKS
>> btrfs check
> Full output please.
On 16/04/18 12:43, Austin S. Hemmelgarn wrote:
On 2018-04-15 21:04, Chris Murphy wrote:
I just ran into this:
https://github.com/neilbrown/mdadm/pull/32/commits/af1ddca7d5311dfc9ed60a5eb6497db1296f1bec
This solution is inadequate, can it be made more generic? This isn't
an md specific
And then there are SAN devices managed by multipath, were the timeouts
should maybe even lower. I know in the scsi layer there are some
extra retries going on and that that actual timeout hits at 5x the
base timeout. So there kind of is a soft timeout on SAN devices at
the base timeout.
On Mon, Apr 16, 2018 at 12:39 AM, Amir Goldstein wrote:
> On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram
> wrote:
> [...]
>> Consider the following workload:
>>
>> creat foo
>> link (foo, A/bar)
>> fsync(foo)
>> crash
>>
>> In this case, after
On Sat, Apr 14, 2018 at 02:49:52AM +0200, David Sterba wrote:
> On Fri, Apr 13, 2018 at 04:28:55PM -0400, Josef Bacik wrote:
> > From: Josef Bacik
> >
> > Since we're allocating under atomic we could every easily enomem, so if
> > that's the case and we can block then loop around
On Mon, Apr 16, 2018 at 12:52 AM, Theodore Y. Ts'o wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>>
>> I don't think this is what the paper's ext3-fast does. All the paper
>> says is if you have a file system where the fsync of a file persisted
>> only
Hi,
I just installed the latest #t2sde test build on a sparc64 system with btrfs
rootfs - you know, just for the fun of testing, and in contrast to my x86 and
ppc systems I get tons of unaligned access warnings, in the form of:
[0.00] Btrfs loaded, crc32c=crc32c-generic
[0.00]
Hi,
The following seems to be a crash consistency bug on btrfs, where in
the link count is not persisted even after a fsync on the original
file.
Consider the following workload :
creat foo
link (foo, A/bar)
fsync(foo)
---Crash---
Now, on recovery we expect the metadata of foo to be persisted
Hi,
I'm using
# btrfs version
btrfs-progs v4.16
In btrfs-subvolume(8), I find the description of the `snapshot`
command unclear:
snapshot [-r] |[/]
I find the preference of `|` is unclear. From the text passage
If only is given, the subvolume will be named the basename
On 2018年04月16日 20:55, Anand Jain wrote:
>
>
> On 04/16/2018 10:02 AM, Qu Wenruo wrote:
>> There are already 2 reports about strangely corrupted super blocks,
>> where csum type and incompat flags get some obvious garbage, but csum
>> still matches and all other vitals are correct.
>>
>> This
On 04/16/2018 10:02 AM, Qu Wenruo wrote:
There are already 2 reports about strangely corrupted super blocks,
where csum type and incompat flags get some obvious garbage, but csum
still matches and all other vitals are correct.
This normally means some kernel memory corruption happens,
On Mon, Apr 16, 2018 at 12:28:59PM +0100, Filipe Manana wrote:
> On Mon, Apr 9, 2018 at 2:05 PM, Eryu Guan wrote:
> > On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote:
> >> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan wrote:
> >> > On Wed, Mar
On 2018-04-15 21:04, Chris Murphy wrote:
I just ran into this:
https://github.com/neilbrown/mdadm/pull/32/commits/af1ddca7d5311dfc9ed60a5eb6497db1296f1bec
This solution is inadequate, can it be made more generic? This isn't
an md specific problem, it affects Btrfs and LVM as well. And in fact
On Mon, Apr 9, 2018 at 2:05 PM, Eryu Guan wrote:
> On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote:
>> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan wrote:
>> > On Wed, Mar 28, 2018 at 12:55:30PM +0100, fdman...@kernel.org wrote:
>> >> From:
Adds comments about BTRFS_FS_EXCL_OP to existing comments
about the device locks.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 16
1 file changed, 16 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index
On 04/04/2018 02:34 AM, David Sterba wrote:
Balance cannot be started on a read-only filesystem and will have to
finish/exit before eg. going to read-only via remount. Cancelling does
not need to check for that.
In case the filesystem is forcibly set to read-only after an error,
balance will
Thanks.
If you see no problems, then its probably locally on my machine.
On Thu, Apr 12, 2018 at 5:10 PM, David Sterba wrote:
> On Wed, Apr 11, 2018 at 01:22:23PM +0300, Ilan Schwarts wrote:
>> Hi
>> While trying to compile my kernel module on suse 12.2 kernel
>>
Hi all,
I maintain kernel module on top of VFS.
When action executes, e.g vfs_rename, i get dentry object.
I need to get the fsid from the dentry object.
Since I maintain the same code for alot of suse distro and kernels
(11.4, 12.0, 12.1, 12.2), i have many #if macros,
My question is in SLES
On 2018/04/12 22:13, David Sterba wrote:
> On Tue, Apr 03, 2018 at 03:30:34PM +0800, Qu Wenruo wrote:
>> I didn't see this patch merged in your misc-next branch but only the
>> remaining patches.
>>
>> However without this patch, btrfs qgroup reserved space will get
>> obviously increased as
On 04/04/2018 02:34 AM, David Sterba wrote:
Replace a WARN_ON with a proper check and message in case something goes
really wrong and resumed balance cannot set up its exclusive status.
The check is a user friendly assertion, I don't expect to ever happen
under normal circumstances.
Also
43 matches
Mail list logo