Maria Caballero | 18 Sep 16:15 2014
Picon

(unknown)


Loan Offer contact us for  more details (gibonline11 <at> gmail.com<mailto:gibonline11 <at> gmail.com>)
All Details should be forward to this E-mail address for fast respond: gibonline11 <at> gmail.com<mailto:gibonline11 <at> gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dave Chinner | 17 Sep 11:28 2014

mmap writes vs truncate causing data corruption

Hi folks,

Brian, Eric and I have been tracking down a set of data corruption
problems on XFS over the past couple of days. The one that is
important to the wider developer community is the truncate/mmap
write issue that Eric isolated from a real-world application that
was triggering it.

The corruption only affects block size smaller than page size
configurations and is caused by mmapped writes to the EOF page
which has been partially truncated. If we then extend the file
again, the region of the page that was truncated and had blocks
punched out of it can be written to via mapped writes without blocks
being allocated for the hole. Hence while the page is in the page
cache, the contents of the file look OK. Unmount/mount the
filesystem, then re-read the page from disk and it will contain
zeros because there is a hole rather than data blocks.

In the XFS case, the bug was that the filesystem truncate code is
not cleaning the partial page fully during the truncate down or up,
and hence the pte remains mapped dirty in the TLB. Hence when new
data is written to the page, it doesn't trigger a write fault,
->page_mkwrite is not called and hence blocks are not allocated over
the hole. I chose to fix it on the truncate up as it was the lesser
of two evils - we can't actually fix the problem entirely because we
can't serialise page faults against truncate.

Initially I couldn't reproduce the data corruptions on ext4, but
Eric came to my rescue and provided me with an updated mremap test
that triggered corruptions. I also added another variant to the
(Continue reading)

Steve French | 17 Sep 10:14 2014
Picon

[SMB3][PATCHv3 Add mfsymlinks support for SMB2.1/SMB3

Updated version of the mfsymlinks patches are in cifs-2.6.git for-next
branch and have tested out fine at the SMB3 plugfest here this week

http://git.samba.org/?p=sfrench/cifs-2.6.git;a=shortlog;h=refs/heads/for-next

--

-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

James Hogan | 16 Sep 14:07 2014
James Hogan <james.hogan <at> imgtec.com>

Subject: [PATCH] vfs: workaround gcc <4.6 build error in link_path_walk()

[PATCH] vfs: workaround gcc <4.6 build error in link_path_walk()

Commit d6bb3e9075bb (vfs: simplify and shrink stack frame of
link_path_walk()) introduced build problems with GCC versions older than
4.6 due to the initialisation of a member of an anonymous union in
struct qstr without enclosing braces.

This hits GCC bug 10676 [1] (which was fixed in GCC 4.6 by [2]), and
causes the following build error:
  fs/namei.c: In function 'link_path_walk':
  fs/namei.c:1778: error: unknown field 'hash_len' specified in initializer

This is worked around by adding explicit braces.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[2] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=159206

Fixes: d6bb3e9075bb (vfs: simplify and shrink stack frame of link_path_walk())
Signed-off-by: James Hogan <james.hogan <at> imgtec.com>
Cc: Linus Torvalds <torvalds <at> linux-foundation.org>
Cc: Alexander Viro <viro <at> zeniv.linux.org.uk>
Cc: Geert Uytterhoeven <geert <at> linux-m68k.org>
Cc: linux-fsdevel <at> vger.kernel.org
Cc: linux-metag <at> vger.kernel.org
---
At least for metag it's feasible to fix the compiler, since backporting
the fix to GCC 4.2.4 isn't actually very difficult. I don't know about
other users of GCC <4.6 though.
---
 fs/namei.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(Continue reading)

Picon

bdev_inode_switch_bdi WARN_ON_ONCE on write_inode_now

After the warning described in
	"mark_buffer_dirty WARN_ON_ONCE on buffer_uptodate"

shutting down the system triggered a different WARN_ON_ONCE,
reporting that write_inode_now failed.

[22138.654946] EXT4-fs (sdu): previous I/O error to superblock detected
[22138.657435] Buffer I/O error on dev sdu, logical block 0, lost sync page write
[22138.660216] EXT4-fs error (device sdu): ext4_put_super:792: Couldn't clean up the journal
[22138.686148] ------------[ cut here ]------------
[22138.688406] WARNING: CPU: 0 PID: 15793 at fs/block_dev.c:67 bdev_inode_switch_bdi+0x81/0x90()
[22138.691568] Modules linked in: ftdi_sio usbserial nfsd nfs_acl exportfs autofs4 rpcsec_gss_krb5
auth_rpcgss nfsv4 nfs fscache lockd sunrpc cpufreq_ondemand pcc_cpufreq dm_mirror dm_region_hash
dm_log uinput ipv6 iTCO_wdt iTCO_vendor_support microcode serio_raw pcspkr sb_edac edac_core hpilo
hpwdt lpc_ich mfd_core ioatdma dca dm_mod wmi sg tg3 ptp pps_core ext4(E) jbd2(E) mbcache(E) sd_mod(E)
crc_t10dif(E) crct10dif_common(E) pata_acpi(E) ata_generic(E) ata_piix(E) hpsa(E) mpt3sas(E)
scsi_transport_sas(E) raid_class(E)
[22138.715231] CPU: 0 PID: 15793 Comm: umount Tainted: G        W   EL 3.17.0-rc4+ #3
[22138.718904] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 09/08/2013
[22138.721423]  0000000000000043 ffff8803ea14fda8 ffffffff815a8b3f 0000000000000043
[22138.725253]  0000000000000000 ffff8803ea14fde8 ffffffff8105267c ffffffff8181ca12
[22138.728817]  ffff88042e0f75b8 ffff88042e0f7530 ffffffff81a8d9a0 ffff88042c80d000
[22138.732579] Call Trace:
[22138.733623]  [<ffffffff815a8b3f>] dump_stack+0x49/0x62
[22138.735595]  [<ffffffff8105267c>] warn_slowpath_common+0x8c/0xc0
[22138.737952]  [<ffffffff810526ca>] warn_slowpath_null+0x1a/0x20
[22138.740080]  [<ffffffff811cfcd1>] bdev_inode_switch_bdi+0x81/0x90
[22138.742708]  [<ffffffff811d0fbf>] __blkdev_put+0x7f/0x1c0
[22138.744745]  [<ffffffff815aa519>] ? mutex_unlock+0x9/0x20
[22138.747487]  [<ffffffff811d1156>] blkdev_put+0x56/0x140
(Continue reading)

Steve French | 15 Sep 20:39 2014
Picon

[PATCH] [SMB3] Add mfsymlinks support for SMB2.1/SMB3. Part 1 create symlink

Adds support on SMB2.1 and SMB3 mounts for emulation of symlinks
via the "Minshall/French" symlink format already used for cifs
mounts when mfsymlinks mount option is used (and also used by Apple).
http://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks
This first patch adds support to create them.  The next patch will
add support for recognizing them and reading them.  Although CIFS/SMB3
have other types of symlinks, in the many use cases they aren't
practical (e.g. either require cifs only mounts with unix extensions
to Samba, or require the user to be Administrator to Windows for SMB3).
This also helps enable running additional xfstests over SMB3 (since some
xfstests directly or indirectly require symlink support).

Signed-off-by: Steve French <smfrench <at> gmail.com>
CC: Stefan Metzmacher <metze <at> samba.org>
---
 fs/cifs/link.c      | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 fs/cifs/smb2ops.c   |  2 ++
 fs/cifs/smb2proto.h |  4 +++-
 3 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/fs/cifs/link.c b/fs/cifs/link.c
index a5c2812..11657f6 100644
--- a/fs/cifs/link.c
+++ b/fs/cifs/link.c
 <at>  <at>  -28,6 +28,7  <at>  <at> 
 #include "cifsproto.h"
 #include "cifs_debug.h"
 #include "cifs_fs_sb.h"
+#include "smb2proto.h"

(Continue reading)

Diana | 15 Sep 18:56 2014
Picon

H

Please Revert back, your assistance is needed.
---------------------------------------
The Exhibitor at innoTrans, Berlin 2014
Hall : 15.1 / Stand no : 109 
http://www.virtualmarket.innotrans.de/?Action=showCompany&id=346242
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alvin Abitria | 15 Sep 01:41 2014
Picon

[HELP] blkid process slows down (due to driver kthread?)

Hello,

I'm currently creating a Linux driver for block devices.  This has
been going on for some time, and I just recently changed the driver
design from bio-mode to request-mode (I used to handle struct bio but
now I'm operating on struct request) and it made the functionality
simpler, but the change also presented some new issues of which I'm
requesting advice.  I'm also using a kthread for background
maintenance and periodic flushing of entries in my driver-device
circular buffers.

One of those issues that I'm having difficulty handling or fully
understanding is regarding the slowness and presence of sbin/blkid
process after entering commands that alter partition or filesystem
type.  With my current design, whenever I run fdisk or mkfs or just
any command that modify the partition/FS type, upon checking running
processes via the ps -ef terminal command, the blkid process runs
afterwards and will take around a minute or two before completing and
updating drive info in Disk Utility (which the user sees).  This is of
course too long to wait, and I have to wait before entering another
command that modify the partition/FS type, or else the drive info gets
messed up, partition table is lost, etc.

I found out that when I came back to my previous bio-mode driver
(which did not have kthread) that this blkid task also runs after the
same commands as above, but finishes very quickly!  I just became
aware of blkid because of its recently observed slowness, and not then
because it easily completes.  And so I decided to play with my driver
code, removing stuffs to see which code segment causes slow blkid, and
eventually found that the presence of kthread correlates to the
(Continue reading)

Steve French | 14 Sep 23:22 2014
Picon

[PATCH] [CIFS] Fix setting time before epoch (negative time values)

xfstest generic/258 sets the time on a file to a negative value
(before 1970) which fails since do_div can not handle negative
numbers.  In addition 'normal' division of 64 bit values does
not build on 32 bit arch so have to workaround this by special
casing negative values in cifs_NTtimeToUnix

Looks like fs/ntfs/time.h has the same bug

Samba server also has a similar bug (being tracked by Samba
bugzilla 7771), but Windows server works fine with this.

Signed-off-by: Steve French <smfrench <at> gmail.com>
---
 fs/cifs/netmisc.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/fs/cifs/netmisc.c b/fs/cifs/netmisc.c
index 6834b9c..3cb7403 100644
--- a/fs/cifs/netmisc.c
+++ b/fs/cifs/netmisc.c
 <at>  <at>  -925,11 +925,22  <at>  <at>  cifs_NTtimeToUnix(__le64 ntutc)
     /* BB what about the timezone? BB */

     /* Subtract the NTFS time offset, then convert to 1s intervals. */
-    u64 t;
+    s64 t = le64_to_cpu(ntutc) - NTFS_TIME_OFFSET;
+
+    /*
+     * Unfortunately can not use normal 64 bit division on 32 bit arch, but
+     * the alternative, do_div, does not work with negative numbers so have
(Continue reading)

Al Viro | 14 Sep 21:47 2014
Picon

[git pull] vfs fixes

double iput() on failure exit in lustre, racy removal of spliced dentries
from ->s_anon in __d_materialise_dentry() plus a bunch of assorted RCU pathwalk
fixes.  Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (5):
      [fix] lustre: d_make_root() does iput() on dentry allocation failure
      move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon)
      fix bogus read_seqretry() checks introduced in b37199e
      don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
      be careful with nd->inode in path_init() and follow_dotdot_rcu()

Diffstat:
 drivers/staging/lustre/lustre/llite/llite_lib.c |    2 +-
 fs/dcache.c                                     |    8 +++-
 fs/namei.c                                      |   52 ++++++++++++++---------
 3 files changed, 39 insertions(+), 23 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Vadim Kochan | 13 Sep 00:17 2014
Picon

spin_lock when create pseudo inode

Hi,

In fs/inode.c:
...

struct inode *new_inode_pseudo(struct super_block *sb)
{
    struct inode *inode = alloc_inode(sb);

    if (inode) {
        spin_lock(&inode->i_lock);
        inode->i_state = 0;
        spin_unlock(&inode->i_lock);
        INIT_LIST_HEAD(&inode->i_sb_list);
    }
    return inode;
}
...

Do we really need spin_lock for inode->i_state = 0 ? Why not:
    atomic_set(&inode->i_state, 0);

Regards,
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane