chrisbuendia | 31 Jul 16:29 2014

A recommendation from Commission Notice - Need Account Information



Wow - you’re about to start getting a TON of 
AUTOMATED commissions deposited into your

You already have some waiting for you.  However,
we need you to finish ACTIVATING YOUR ACCOUNT:


Please take 2 minutes to do this.  If you don’t, we 
can’t deposit any more commissions into your bank!


Thank you!

-Secret Money System

(Continue reading)

Dongho Sim | 30 Jul 08:52 2014

[PATCH v2] f2fs: remove redundant lines in allocate_data_block

There are redundant lines in allocate_data_block.

In this function, we call refresh_sit_entry with old seg and old curseg.
After that, we call locate_dirty_segment with old curseg.

But, the new address is always allocated from old curseg and
we call locate_dirty_segment with old curseg in refresh_sit_entry.
So, we do not need to call locate_dirty_segment with old curseg again.

We've discussed like below:

Jaegeuk said:
 "When considering SSR, we need to take care of the following scenario.
  - old segno : X
  - new address : Z
  - old curseg : Y
  This means, a new block is supposed to be written to Z from X.
  And Z is newly allocated in the same path from Y.

  In that case, we should trigger locate_dirty_segment for Y, since
  it was a current_segment and can be dirty owing to SSR.
  But that was not included in the dirty list."

Changman said:
 "We already choosed old curseg(Y) and then we allocate new address(Z) from old
  curseg(Y). After that we call refresh_sit_entry(old address, new address).
  In the funcation, we call locate_dirty_segment with old seg and old curseg.
  So calling locate_dirty_segment after refresh_sit_entry again is redundant."

Jaegeuk said:
(Continue reading)

NeilBrown | 30 Jul 08:08 2014

[PATCH] VFS: allow ->d_manage() to declare -EISDIR in rcu_walk mode.

In REF-walk mode, ->d_manage can return -EISDIR to indicate
that the dentry is not really a mount trap (or even a mount point)
and that any mounts or any DCACHE_NEED_AUTOMOUNT flag should be

RCU-walk mode doesn't currently support this, so if there is a dentry
with DCACHE_NEED_AUTOMOUNT set but which shouldn't be a mount-trap,
lookup_fast() will always drop in REF-walk mode.

With this patch, an -EISDIR from ->d_manage will always cause mounts
and automounts to be ignored, both in REF-walk and RCU-walk.

Cc: Ian Kent <raven <at>>
Signed-off-by: NeilBrown <neilb <at>>

Hi Al,
 this patch is needed before I can make autofs4 fully support RCU-walk.
There are cases currently were directories have DCACHE_NEED_AUTOMOUNT but for which
no automount is required.


diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index a1d0d7a30165..61d65cc65c54 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
 <at>  <at>  -1053,7 +1053,8  <at>  <at>  struct dentry_operations {
(Continue reading)

JP Abgrall | 30 Jul 00:58 2014

[PATCH] ext4: Add support for FIDTRIM, a best-effort ioctl for deep discard trim

* What
This provides an interface for issuing an FITRIM which uses the
secure discard instead of just a discard.
Only the eMMC command is "secure", and not how the FS uses it:
due to the fact that the FS might reassign a region somewhere else,
the original deleted data will not be affected by the "trim" which only
handles un-used regions.
So we'll just call it "deep discard", and note that this is a
"best effort" cleanup.

* Why
Once in a while, we want to be able to cleanup most of the unused blocks
after erasing a bunch of files.
We don't want to constantly secure-discard via a mount option.

From an eMMC spec perspective, it tells the device to really get rid of
all the data for the specified blocks and not just put them back into the
pool of free ones (unlike the normal TRIM). The eMMC spec says the
secure trim handling must make sure the data (and metadata) is not available
anymore. A simple TRIM doesn't clear the data, it just puts blocks in the
free pool.
JEDEC Standard No. 84-A441
  7.6.9 Secure Erase
  7.6.10 Secure Trim

From an FS perspective, it is acceptable to leave some data behind.
 - directory entries related to deleted files
 - databases entries related to deleted files
 - small-file data stored in inode extents
 - blocks held by the FS waiting to be re-used (mitigated by sync).
(Continue reading)

Jerry | 30 Jul 13:09 2014

my subject

DOou need a loan? reply back with this info name,country,loan mount doration,your phone
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at>
More majordomo info at

Rob Jones | 29 Jul 19:39 2014

[PATCH] seq_file: Allow private data to be supplied on seq_open

Create a function seq_open_priv() that is identical to seq_open() except
that it accepts a void * parameter that it stores in the private field
of the struct seq_file.

Document seq_open_priv().

Some consumers of the seq_file interface need to pass data to their
iterators that is best obtained at the time the seq_file is opened.

At the moment these consumers have to obtain the struct seq_file pointer
(stored by seq_open() in file->private_data) and then store a pointer to
their own data in the private field of the struct seq_file so that it
can be accessed by the iterator functions.

Although this is not a long piece of code it is unneccessary boilerplate.

seq_open() remains in place and its behaviour remains unchanged so no
existing code should be broken by this patch.

Signed-off-by: Ian Molton <ian.molton <at>>
Signed-off-by: Rob Jones <rob.jones <at>>
 Documentation/filesystems/seq_file.txt |    9 +++++++++
 fs/seq_file.c                          |   30 ++++++++++++++++++++++++++++--
 include/linux/seq_file.h               |    1 +
 3 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index a1e2e0d..128ffee 100644
--- a/Documentation/filesystems/seq_file.txt
(Continue reading)

Jerry | 30 Jul 13:27 2014

my subject

DOou need a loan? reply back with this info name,country,loan mount doration,your phone
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at>
More majordomo info at

Noemi Alvarez | 29 Jul 10:23 2014


I want to keep up with you with hope for friendship if you are interested.
If you don't mind i will like you to write me back. I am waiting to read
from you, because i have something important and urgent to discuss with
you. I will also send some of my beautiful photos to you.

To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at>
More majordomo info at

Tim Chen | 28 Jul 23:51 2014

[Regression 3.16-rc kernel] -55% reduction in throughput for OLTP benchmark


We saw a large regression (-55%) in a standard OLTP benchmark
between 3.15 kernel and 3.16-rc4 kernel.

One issue was caused by the changes in async direct IO in the 
direct IO patch series between commit f6c0a192 and 62a8067a 
for the 3.16-rc kernel.  The kernel before this series at 
commit 38583f09 has no such regression.

After some investigations and instrumentation, we saw that the
problem was caused by a lot of io_wait issued from 
do_blockdev_direct_IO for async direct IO writes, which
did not happen for 3.15 kernel.  The benchmark
used to run at 97% cpu utilization now has only
35% cpu utilization with plenty of idle time.

At the end of do_blockdev_direct_IO, 

        if (dio->is_async && retval == 0 && dio->result &&
            ((rw == READ) || (dio->result == sdio.size)))
                retval = -EIOCBQUEUED;

        if (retval != -EIOCBQUEUED)

we saw for async writes, the check
for (dio->result == sdio.size) failed. The retval was not
set to -EIOCBQUEUED, causing dio_await_completion to be issued
and hence the io_waits.
(Continue reading)

Paul Smith | 28 Jul 11:43 2014


Dear Friend,

Can I invest some huge amount of money Under your care in your
country? If you are capable to assist me invest and control this fund
when I hand it over to you reply swiftly and you will be gladly

Thanks And God Bless.

Mr Paul Smith
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at>
More majordomo info at

Steven Stewart-Gallus | 28 Jul 02:11 2014

Bug 24912 - I think this one fell through the cracks a bit


I think that bug 2491 at sort of fell through
the cracks and I'm not sure as many people are aware of it as there
could be. This bug is that one can't mount bind mounts readonly but
can only remount them readonly which is insufficient for recursive
bind mounts and certain kinds of sandboxing. Also the bind mount fails
silenty without giving an error which is never a good idea.
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at>
More majordomo info at