On Tue, 2015-12-08 at 23:22 +0800, Geliang Tang wrote:
> Use list_for_each_entry() instead of list_for_each() to simplify
> the code.
>
Looks good.
Reviewed-by: Vyacheslav Dubeyko
Thanks,
Vyacheslav Dubeyko.
> Signed-off-by: Geliang Tang
> ---
> fs/hfs/catalog.c |
oint variant of
bcachefs and implementation on my side for NAND flash support. I need to
be more familiar with bcachefs architecture for such decision. But,
unfortunately, I suspect that it can be not so easy to support raw flash
for bcachefs. Of course, I can be wrong.
[1] https://github.com/hg
e the return value from cmp(b, a). So a compares less than
> b and b compares less than a. One can also easily find three values
> a,b,c such that a compares less than b, b compares less than c, but a
> does not compare less than c.
>
Looks good for me. Thank you for the fix.
Reviewe
is issue was detected by using the Coccinelle software.
>
Thank you. It's the reasonable correction. Looks good for me.
Reviewed-by: Vyacheslav Dubeyko
Thanks,
Vyacheslav Dubeyko.
> Signed-off-by: Markus Elfring
> ---
> fs/hfs/bfind.c | 3 +--
> fs/hfs/brec.c |
view.
Unfortunately, I hadn't opportunity for this activity during last time.
I hope that I'll find time for this in the near future. But I can't
promise something definite.
Thanks,
Vyacheslav Dubeyko.
> [ 2435.033434] IP: memcpy (arch/x86/lib/memcpy_64.S:160)
> [ 2435.
> fs: use new inode_time definition unconditionally
>
By the way, what about NILFS2? Is NILFS2 ready for suggested approach
without any changes?
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
one small step closer to lifting the VFS limit by using
> struct inode_time in logfs.
>
I think you meant hfs/hfsplus here. I suppose that mentioning the logfs
is simple misspelling.
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linu
c#L441
(2) http://lxr.free-electrons.com/source/fs/hfsplus/super.c#L135
(3) http://lxr.free-electrons.com/source/fs/hfsplus/xattr.c#L71
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
On Mon, 2014-03-10 at 21:56 +0100, Fabian Frederick wrote:
> hfsplus_create_attr_tree_cache is only called by __init init_hfsplus_fs
>
I think that it is the reasonable fix. Looks good for me.
Reviewed-by: Vyacheslav Dubeyko
Thanks,
Vyacheslav Dubeyko.
> Signed-off-by: Fabian
. Please see. catalog.c#hfsplus_find_cat the only place it
> is called.
>
> {code}
> if (be16_to_cpu(tmp.thread.nodeName.length) > 255) {
> pr_err("catalog name length corrupted\n");
> return -EIO;
> }
> {co
fsplus_btree_key *);
> -void hfsplus_cat_build_key(struct super_block *sb,
> +int hfsplus_cat_build_key(struct super_block *sb,
> hfsplus_btree_key *, u32, struct qstr *);
> +void hfsplus_cat_build_key_with_cnid(struct super_block *sb,
The whole style of the fix is good. But
ffa
Thank you for report about the issue.
But could you share a reproducing path? Or, maybe, is it possible to
repeat your steps?
It will be great to have reproducing path.
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
o prepare next version of the patch or to prepare patch set
from two patches. And it makes sense to provide changelog of your work,
I think.
Thanks,
Vyacheslav Dubeyko.
> for (i = 0; i < argv->v_nmembs; i += n) {
> n = (argv->v_nmembs - i < maxmembs) ?
>
talking about
possible huge number then you can receive huge number from userspace
before entering in the cycle.
Thanks,
Vyacheslav Dubeyko.
> Signed-off-by: Wenliang Fan
> ---
> fs/nilfs2/ioctl.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
On Wed, 2013-12-11 at 21:08 +, Anton Altaparmakov wrote:
> Hi,
>
> On 11 Dec 2013, at 19:11, Al Viro wrote:
> > On Wed, Dec 11, 2013 at 10:49:29PM +0300, Vyacheslav Dubeyko wrote:
> >> This feature worked earlier under Linux. So, I suppose that some changes
> &
+ driver
or in VFS broke it. And it needs to investigate and fix the reported issue.
Thank you for the
report.
But I think that this patch can't be the solution of the issue. So, if you want
then
you can investigate and fix the issue. Could you do it?
Thanks,
Vyacheslav Dubeyko.
--
To
r in the background of
my main activity. Also I participate in reviewing of new HFS+ related patches.
So, it is possible to say that I am actively looking after the HFS+ file system
driver.
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linu
s then I
disagree again.
Because, as far as I can see, there are many Apple devices that it has HFS+
file system
then it makes sense to have actual support for HFS+ file system under Linux.
With the best regards,
Vyacheslav Dubeyko.
> --
> To unsubscribe from this list: send the line "un
HEADER 0x01/* The tree header node (node 0) */
> -#define HFS_NODE_MAP 0x02/* Holds part of the bitmap of used
> nodes */
> -#define HFS_NODE_LEAF0xFF/* A leaf (ndNHeight==1) node */
> -
Yes, it is really duplicate declarations.
Thank you for
On Oct 20, 2013, at 3:46 PM, Richard Weinberger wrote:
> On Sun, Oct 20, 2013 at 1:37 PM, jiaweiwei wrote:
>> On Sun, Oct 20, 2013 at 6:43 PM, Vyacheslav Dubeyko
>> wrote:
>>> Anyway, you need to use Copy-On-Write (COW) approach for such file system.
>>>
for such file system.
But there are file systems that implements snapshot approach yet: NILFS2,
ext3cow,
Next3, and so on.
Do you really want to implement something likewise snapshot feature in a file
system
from the scratch?
With the best regards,
Vyacheslav Dubeyko.
> --
> To unsub
nyway, it makes sense to prepare patch set instead of one huge patch.
Could you, please, prepare patch set?
And you should add linux-fsdevel list in CC for any discussion about
file system drivers.
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux
On Thu, 2013-07-25 at 14:35 -0400, Dhaval Giani wrote:
> On 2013-07-25 2:15 PM, Vyacheslav Dubeyko wrote:
> > On Jul 25, 2013, at 8:42 PM, Taras Glek wrote:
> >
> > [snip]
> >>> To introduce transparent decompression. Let someone else do the
> >>> com
On Thu, 2013-07-25 at 11:16 -0700, Taras Glek wrote:
>
>
> Vyacheslav Dubeyko wrote:
> > On Jul 25, 2013, at 8:42 PM, Taras Glek wrote:
> >
> > [snip]
> > > > To introduce transparent decompression. Let someone else do the
> > > > compres
has native
decompression support
for compressed files but you need to use special tool for compression of files
on HFS+. Maybe
Mac OS X has internal library that give opportunity to compress application
libraries at installation
time. But I suppose that it is simply user-space tool or lib
hash_lock);
> - BUG_ON(node);
> + if (node) {
> + printk(KERN_CRIT "new node %u already hashed?\n", num);
The error/debug subsystem of HFS/HFS+ was reworked by Joe Perches, recently.
Please, change printk() on pr_crit().
Thanks,
Vyacheslav Dubeyko.
>
On Tue, 2013-04-09 at 22:14 +0400, Alexey Khoroshilov wrote:
> __hfsplus_ext_write_extent() suppresses errors coming from hfs_brec_find().
> The patch implements error code propagation.
>
Looks good for me.
Reviewed-by: Vyacheslav Dubeyko
Tnanks,
Vyacheslav Dubeyko.
> Signed-of
gt; The patch adds checks for errors in hfs_find_init().
>
Looks good for me.
Reviewed-by: Vyacheslav Dubeyko
Tnanks,
Vyacheslav Dubeyko.
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> ---
> fs/hfs/catalog.c
On Tue, 2013-04-09 at 03:39 -0700, Joe Perches wrote:
> On Tue, 2013-04-09 at 11:08 +0400, Vyacheslav Dubeyko wrote:
> > On Mon, 2013-04-08 at 09:37 -0700, Joe Perches wrote:
> > > Joe Perches (2):
> > > hfs/hfsplus: Convert dprint to hfs_dbg
> > >
dev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#1014: FILE: fs/hfsplus/hfsplus_fs.h:44:
+ printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \
total: 1 errors, 4 warnings, 1226 lines checked
Thanks,
Vyacheslav Dubeyko.
> Signed-off-by: Joe Perches
iguity and misunderstanding (during a search for example). I
understand that we reduce constant in length. But I doubt that this
changing makes sense.
Thanks,
Vyacheslav Dubeyko.
> + hfs_dbg(BNODE_REFS, "find_init: %d (%p)\n",
> + tree->cnid, __builtin_retur
that we can have
opportunity to choose old-fashioned HFS debugging output or dynamic
debug by means of declaration of special macro definition for every
case. I mean constant for every case (static debug, dynamic debug, no
debug).
Thanks,
Vyacheslav Dubeyko.
> fs/hfs/bfind.c | 10
or
usual kernel build.
I think that adding dprint() messages in hfs_find_init() is not
necessary. But adding dprint() for __hfsplus_ext_write_extent() and
other places can be useful, from my point of view. And such messages can
be useful as for HFS+ as for HFS drivers.
With the best regards,
Vyach
anges are related to each other, so, it makes sense in one patch set.
Thanks,
Vyacheslav Dubeyko.
> Signed-off-by: Alexey Khoroshilov
> ---
> fs/hfsplus/extents.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/fs/hfsplus/exten
Hi Alexey,
On Apr 7, 2013, at 1:13 AM, Alexey Khoroshilov wrote:
> Hi Vyacheslav,
>
> On 03/30/2013 03:35 PM, Vyacheslav Dubeyko wrote:
>>> Found by Linux Driver Verification project (linuxtesting.org).
>>>
>>> Signed-off-by: Alexey Khoroshilov
ition without blocks discard step.
So, I think that it needs to investigate issue in the direction of
BLKDISCARD code on the kernel side. It makes sense to debug
f2fs_trim_device() method of mkfs.f2fs utility too. But I can't see
anything strange in this function at a glance.
With the best rega
;cat /proc/partitions" and "strace mkfs.f2fs /dev/mmcblk0p3"
outputs? I think that these outputs can be very useful for issue analysis.
By the way, can you reproduce the issue on another SD-card? Do you reproduce
the issue only under pandaboard?
Thanks,
Vyacheslav Dubeyko.
>
e->i_sb)->ext_tree, &fd);
> - __hfs_ext_write_extent(inode, &fd);
> + res = hfs_find_init(HFS_SB(inode->i_sb)->ext_tree, &fd);
> + if (res)
> + return res;
> + res = __hfs_ext_write_extent(inode, &fd);
>
From: Vyacheslav Dubeyko
Subject: [PATCH] posix_acl: fix warning in acl_by_type() function
This patch fixes warning in function ‘acl_by_type’:
include/linux/posix_acl.h:108:1: warning: control reaches end of non-void
function [-Wreturn-type].
Signed-off-by: Vyacheslav Dubeyko
---
include
From: Vyacheslav Dubeyko
Subject: [PATCH] nilfs2: fix very long mount time issue
DESCRIPTION:
It exists situation when GC can work in background alone without any other
filesystem activity during significant time. The nilfs_clean_segments() method
calls nilfs_segctor_construct() that updates
Hi,
This patch adds support of manipulation by attributes file.
With the best regards,
Vyacheslav Dubeyko.
---
From: Vyacheslav Dubeyko
Subject: [PATCH v3 5/5] hfsplus: add support of manipulation by attributes file
This patch adds support of manipulation by attributes file.
Reported-by: Hin
Hi,
This patch reworks functionality of getting, setting and deleting of extended
attributes.
With the best regards,
Vyacheslav Dubeyko.
---
From: Vyacheslav Dubeyko
Subject: [PATCH v3 4/5] hfsplus: rework functionality of getting, setting and
deleting of extended attributes
This patch
Hi,
This patch adds functionality of manipulating by records in attributes tree.
With the best regards,
Vyacheslav Dubeyko.
---
From: Vyacheslav Dubeyko
Subject: [PATCH v3 3/5] hfsplus: add functionality of manipulating by records
in attributes tree
This patch adds functionality of
Hi,
This patch adds all necessary on-disk layout declarations related to attributes
file.
With the best regards,
Vyacheslav Dubeyko.
---
From: Vyacheslav Dubeyko
Subject: [PATCH v3 2/5] hfsplus: add on-disk layout declarations related to
attributes tree
This patch adds all necessary on-disk
Hi,
This patch adds osx.* prefix for handling namespace of Mac OS X extended
attributes.
With the best regards,
Vyacheslav Dubeyko.
---
From: Vyacheslav Dubeyko
Subject: [PATCH v3 1/5] hfsplus: add osx.* prefix for handling namespace of Mac
OS X extended attributes
This patch adds osx
manipulation by records in Attributes tree.
3. It was reworked hfsplus_listxattr, hfsplus_getxattr, hfsplus_setxattr
functions in ioctl.c. Moreover, it was added hfsplus_removexattr method.
With the best regards,
Vyacheslav Dubeyko.
---
fs/hfsplus/Makefile |4 +-
fs/hfsplus/attributes.c | 39
On Sun, 2012-11-11 at 20:42 +0900, Jaegeuk Kim wrote:
> 2012-11-11 (일), 00:55 +0300, Vyacheslav Dubeyko:
> > Hi,
> >
> > On Nov 10, 2012, at 9:33 PM, Martin Steigerwald wrote:
> >
> > [snip]
> > >
> > > merkaba:~> mkfs.f2fs /dev/sdb1
&
,0G147M 1,8G8% /mnt/zeit
>
Do you really have trouble with f2fs mount without definition of filesystem
type? If so, it is a bug.
Moreover, I think that it is really inconvenient that mkfs.f2fs doesn't output
its version. I suggest to output version of f2fs utilities.
With the bes
ree->hash_lock);
> if (node) {
> - printk(KERN_CRIT "new node %u already hashed?\n", num);
> - WARN_ON(1);
> + WARN(1, KERN_CRIT "new node %u already hashed?\n", num);
> return node;
> }
> n
e(raw_super_buf);
> +free_sbi:
> + kfree(sbi);
> + return -EINVAL;
The reason of failing in fill_super() can be different but this function report
-EINVAL always, as I understand. I think that it is not fully correct way of
reporting about failing.
> +}
> +
> +static stru
__le32 is big data type for log2 (). What
> > do you think?
> >
>
> Right, but it is superblock. Should we have to consider space overhead?
>
I simply think that __le16 can be enough. So, all four fields
(log_sectorsize, log_sectors_per_block, log_blocksize,
log_blocks_p
NR_DENTRY_IN_BLOCK + BITS_PER_BYTE -
> 1) / \
> + BITS_PER_BYTE)
> +#define SIZE_OF_RESERVED (PAGE_SIZE - ((SIZE_OF_DIR_ENTRY + \
> + F2FS_NAME_LEN) * \
> + NR_DENTRY_IN_BLOCK + SIZE_OF_DENTRY_B
really needs more CPU and memory for functioning. The
f2fs keeps more metadata as VFAT, as I understand. Moreover, it manages six
active logs at runtime and GC can works in background. All of it needs in more
CPU power.
With the best regards,
Vyacheslav Dubeyko.
> Any
namically changed to the threaded log scheme according to the
> file
> +system status.
> +
> +In order to align F2FS with underlying flash-based storage, F2FS allocates a
> +segment in a unit of section. F2FS expects that the section size would be the
> +same as the unit size of garb
r, maybe, do you mean some another special optimization for VFAT?
> What about something more complex like "untar of kernel tree"?
>
Yes, it is very interesting use-case. Maybe, kernel compilation can be
complimentary synthetic benchmark. :-)
ood for Linux Forum. But do you plan to publish more detailed
description of F2FS architecture, advantages/disadvantages in the form
of article? It makes sense from my point of view.
With the best regards,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On Oct 14, 2012, at 11:09 AM, Jaegeuk Kim wrote:
> 2012-10-14 (일), 02:21 +0400, Vyacheslav Dubeyko:
>> On Oct 14, 2012, at 12:52 AM, Arnd Bergmann wrote:
>>
>>> On Friday 05 October 2012, 김재극 wrote:
>>>> +const char *media_ext_lists[] = {
&
e same defaults, but with the option of overriding it
> using
> a debugfs tool.
>
By the way, how about extended attributes? It is possible to save in extended
attribute a hint about file's content nature during creation operation or
later. Moreover, extended attribute gives possib
ider this to be a policy that should be configurable by the user.
>
I think that file extensions can't be a steady basis for categorization. It is
possible that user can use any extension as you want during file naming (for
example, save text file with png extension). Or it is possible t
mplex structure;
> > (2) sequential access is not sequential; (3) auxiliary files dominate; (4)
> > multiple threads perform
> > I/O.
> >
> > I am afraid that random modification of different part of files and I/O
> > operations from multiple
> > t
On Tue, 2012-10-09 at 14:53 -0500, Jooyoung Hwang wrote:
> On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
> > > -Original Message-
> > > From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > > Sent: Tuesday, October 09, 2012 4:23 AM
> > > To:
On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
> > -Original Message-
> > From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > Sent: Tuesday, October 09, 2012 4:23 AM
> > To: Jaegeuk Kim
> > Cc: 'Marco Stornelli'; 'Jae
Hi,
On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote:
>> -Original Message-
>> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
>> Sent: Sunday, October 07, 2012 9:09 PM
>> To: Jaegeuk Kim
>> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; '
Hi,
On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
>> -Original Message-
>> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
>> Sent: Sunday, October 07, 2012 4:10 PM
>> To: Jaegeuk Kim
>> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; A
Hi,
On Oct 7, 2012, at 12:06 AM, Jaegeuk Kim wrote:
> 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko:
>> Hi Jaegeuk,
>
> Hi.
> We know each other, right? :)
>
Yes, you are correct. :-)
>>
>>> From: 김재극
>>> To: v...@z
arious
> parameters not only for configuring on-disk layout, but also for selecting
> allocation
> and cleaning algorithms.
>
What about F2FS performance? Could you share benchmarking results of the new
file system?
It is very interesting the case of aged file system. How is GC
niques, I think. So, simplicity and easy
recoverability of user data can be a valuable feature also.
With the best regards,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo in
67 matches
Mail list logo
