headers
Dan McGee | 3 Jan 2012 20:46

[PATCH] rmcp: print sensible error message on permission failure

When running as non-root, the error message seems to indicate a
checkpoint is a snapshot, rather than the actual problem, which is that
I do not have permission to delete the checkpoints.

Before:
    $ rmcp 29..35
    rmcp: 29: cannot remove snapshot
    rmcp: 30: cannot remove snapshot
    rmcp: 31: cannot remove snapshot
    rmcp: 32: cannot remove snapshot
    rmcp: 33: cannot remove snapshot
    rmcp: 34: cannot remove snapshot
    rmcp: 35: cannot remove snapshot

    To delete snapshot(s), change them into checkpoints with
    chcp command before removal.

After:
    $ ./bin/rmcp 29..35
    lt-rmcp: 29: cannot remove checkpoint: Operation not permitted
    Remaining checkpoints were not removed.

Since May 2009 the kernel has returned EBUSY instead of EPERM for
removal requests against snapshots, commit 30c25be71fcbd87fd. We should
be able to treat EPERM as expected now, as the commit message there
indicates.

Signed-off-by: Dan McGee <dan@...>
---
 bin/rmcp.c |   11 ++++++++---
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ryusuke Konishi | 5 Jan 2012 06:14
Picon
Gravatar

Re: [PATCH] rmcp: print sensible error message on permission failure

On Tue,  3 Jan 2012 13:46:00 -0600, Dan McGee wrote:
> When running as non-root, the error message seems to indicate a
> checkpoint is a snapshot, rather than the actual problem, which is that
> I do not have permission to delete the checkpoints.
> 
> Before:
>     $ rmcp 29..35
>     rmcp: 29: cannot remove snapshot
>     rmcp: 30: cannot remove snapshot
>     rmcp: 31: cannot remove snapshot
>     rmcp: 32: cannot remove snapshot
>     rmcp: 33: cannot remove snapshot
>     rmcp: 34: cannot remove snapshot
>     rmcp: 35: cannot remove snapshot
> 
>     To delete snapshot(s), change them into checkpoints with
>     chcp command before removal.
> 
> After:
>     $ ./bin/rmcp 29..35
>     lt-rmcp: 29: cannot remove checkpoint: Operation not permitted
>     Remaining checkpoints were not removed.
> 
> Since May 2009 the kernel has returned EBUSY instead of EPERM for
> removal requests against snapshots, commit 30c25be71fcbd87fd. We should
> be able to treat EPERM as expected now, as the commit message there
> indicates.
> 
> Signed-off-by: Dan McGee <dan@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan McGee | 5 Jan 2012 17:03

[PATCH] mkfs.nilfs2: support -h command line option

Signed-off-by: Dan McGee <dan@...>
---
 man/mkfs.nilfs2.8 |    9 +++++++++
 sbin/mkfs/mkfs.c  |   25 ++++++++++++++++---------
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/man/mkfs.nilfs2.8 b/man/mkfs.nilfs2.8
index f513994..b334142 100644
--- a/man/mkfs.nilfs2.8
+++ b/man/mkfs.nilfs2.8
 <at>  <at>  -36,6 +36,9  <at>  <at>  mkfs.nilfs2 \- create a NILFS2 filesystem
 .IR feature [,...]
 ]
 [
+.B \-h
+]
+[
 .B \-q
 ]
 [
 <at>  <at>  -77,6 +80,9  <at>  <at>  mkfs.nilfs2 \- create a NILFS2 filesystem
 .IR feature [,...]
 ]
 [
+.B \-h
+]
+[
 .B \-q
 ]
 [
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ryusuke Konishi | 9 Jan 2012 10:32
Picon
Gravatar

Re: [PATCH] mkfs.nilfs2: support -h command line option

On Thu,  5 Jan 2012 10:03:39 -0600, Dan McGee wrote:
> Signed-off-by: Dan McGee <dan@...>
> ---
>  man/mkfs.nilfs2.8 |    9 +++++++++
>  sbin/mkfs/mkfs.c  |   25 ++++++++++++++++---------
>  2 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/man/mkfs.nilfs2.8 b/man/mkfs.nilfs2.8
> index f513994..b334142 100644
> --- a/man/mkfs.nilfs2.8
> +++ b/man/mkfs.nilfs2.8
>  <at>  <at>  -36,6 +36,9  <at>  <at>  mkfs.nilfs2 \- create a NILFS2 filesystem
>  .IR feature [,...]
>  ]
>  [
> +.B \-h
> +]
> +[
>  .B \-q
>  ]
>  [
>  <at>  <at>  -77,6 +80,9  <at>  <at>  mkfs.nilfs2 \- create a NILFS2 filesystem
>  .IR feature [,...]
>  ]
>  [
> +.B \-h
> +]
> +[
>  .B \-q
>  ]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leszek Dubiel | 10 Jan 2012 17:22
Picon

user experience


Dubiel Vitrum is using Linux Debian system extensively to manage all 
documents in electronic form. We have ten million of files sorted in 
directories. The biggest directories contain about 100.000 files.

Currently our system works effectively by using ReiserFs, which is 
especially fast for small files and directories containing lots of 
files. But ReiserFS is not supported any more, so we are looking for a 
new file system that would handle our job as good as ReiserFS.

I installed fresh Debian, created empty partitions, formated them as 
Reiserfs, Nilfs. Then run command on each partition:

     for A in $(seq 10); do for B in $(seq 100); do for C in $(seq 
1000); do mkdir -p $A/$B/$C; done; done; done

and then run:

     find >/dev/null.

On Reiserfs it (last command, find) took 19 seconds, while on Nilfs it 
took 170 seconds. Maybe this is because system lacks b-tree directory 
management. Another limitation is that I was unable to create more than 
thirty thousand directories in one directory.

Leszek Dubiel
www.dubielvitrum.pl

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gordan Bobic | 26 Jan 2012 14:08
Gravatar

Garbage Collection Method

Hi,

Quick question about the garbage collector and what it reclaims and in 
what order.

1) Does it scan blocks from the tail of the file system forward 
sequentially?

2) Does it reclaim blocks regardless of how dirty they are? Or does it 
execute reclaiming on order of maximum dirtyness first in order to 
reduce churn (and flash wear when used on flash media)?

3) What happens when it encounters a block that isn't dirty? Does it 
skip it and reclaim the next dirty block, leaving a "hole"? Or does it 
reclaim everything up to a reclaimable block to make the free space 
contiguous?

4) Assuming this isn't already how it works, how difficult would it be 
to modify the reclaim policy (along with associated book-keeping 
requirements) to reclaim blocks in the order of dirtiest-block-first?

5) If a suitable book-keeping bitmap was in place for 4), could this not 
be used for accurate df reporting?

TIA.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Fertser | 26 Jan 2012 14:52
Picon

Odd problem starting nilfs_cleanerd due to an eMMC misbehaviour

Hi,

I'm using nilfs2 for the root filesystem on an ARM-based netbook
(Toshiba ac100) with Debian hardfloat. Custom kernel is based on 3.0.8
and nilfs-tools is 2.1.0-1 from the Debian repository.

I wanted to try the threaded i/o test from the Phoronix test suite and
somehow it happened that during the test the garbage collecting daemon
failed and never came back. So i got the filesystem 100% full and
after i noticed it i tried running the daemon manually. It didn't
start even after reboot. Suprisingly, the eMMC error went away on its
own after fully powering off the whole device, and after that the
daemon started to work properly.

I'm not sure what conclusion might be made from this but i'd still
appreciate any comments, especially the suggestions on what to do if
the error didn't "recover".

The relevant dmesg excerpts (full might be available from
http://paulfertser.info/files/failing_emmc.txt ):

[    2.837036] mmc0: new high speed MMC card at address 0001
[    2.847637] mmcblk0: mmc0:0001 MMC32G 29.8 GiB 
...
[ 5668.706475] mmcblk0: retrying using single block read
[ 5671.580366] mmcblk0: error -110 transferring data, sector 15563278, nr 122, card status 0x200900
[ 5671.603701] end_request: I/O error, dev mmcblk0, sector 15563278
[ 5674.421016] mmcblk0: error -110 transferring data, sector 15563279, nr 121, card status 0x200900
[ 5674.445322] end_request: I/O error, dev mmcblk0, sector 15563279
[ 5674.466988] NILFS: GC failed during preparation: cannot read source blocks: err=-5
(Continue reading)

Permalink | Reply | 9 comments |
headers
Christian Smith | 27 Jan 2012 17:00

Re: Garbage Collection Method

On Thu, Jan 26, 2012 at 01:08:09PM +0000, Gordan Bobic wrote:
> Hi,
>
> Quick question about the garbage collector and what it reclaims and in  
> what order.
>
> 1) Does it scan blocks from the tail of the file system forward  
> sequentially?

Yes

>
> 2) Does it reclaim blocks regardless of how dirty they are? Or does it  
> execute reclaiming on order of maximum dirtyness first in order to  
> reduce churn (and flash wear when used on flash media)?

The former.

>
> 3) What happens when it encounters a block that isn't dirty? Does it  
> skip it and reclaim the next dirty block, leaving a "hole"? Or does it  
> reclaim everything up to a reclaimable block to make the free space  
> contiguous?

It is cleaned regardless. Free space appears to always be contiguous.

>
> 4) Assuming this isn't already how it works, how difficult would it be  
> to modify the reclaim policy (along with associated book-keeping  
> requirements) to reclaim blocks in the order of dirtiest-block-first?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Smith | 27 Jan 2012 17:19

Re: Odd problem starting nilfs_cleanerd due to an eMMC misbehaviour

On Thu, Jan 26, 2012 at 05:52:03PM +0400, Paul Fertser wrote:
> Hi,
> 
> I'm using nilfs2 for the root filesystem on an ARM-based netbook
> (Toshiba ac100) with Debian hardfloat. Custom kernel is based on 3.0.8
> and nilfs-tools is 2.1.0-1 from the Debian repository.
> 
> I wanted to try the threaded i/o test from the Phoronix test suite and
> somehow it happened that during the test the garbage collecting daemon
> failed and never came back. So i got the filesystem 100% full and
> after i noticed it i tried running the daemon manually. It didn't
> start even after reboot. Suprisingly, the eMMC error went away on its
> own after fully powering off the whole device, and after that the
> daemon started to work properly.
> 
> I'm not sure what conclusion might be made from this but i'd still
> appreciate any comments, especially the suggestions on what to do if
> the error didn't "recover".

Remember, SDCards contain their own embedded controller to do the
block mapping between LBA and FLASH blocks. There may even be an ARM
based controller in the SDCard. Under the stress of a benchmark, the
firmware probably just got itself in a bit of a state and needed a
hard reset to recover.

What brand of SD Card is it? Most SD Cards are designed for low
stress low speed IO in devices such as cameras. Perhaps try a
different brand.

Christian
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gordan Bobic | 27 Jan 2012 17:26
Gravatar

Re: Garbage Collection Method

Christian,

Many thanks for your reply.

>> 1) Does it scan blocks from the tail of the file system forward  
>> sequentially?
> 
> Yes
> 
>> 2) Does it reclaim blocks regardless of how dirty they are? Or does it  
>> execute reclaiming on order of maximum dirtyness first in order to  
>> reduce churn (and flash wear when used on flash media)?
> 
> The former.
> 
>> 3) What happens when it encounters a block that isn't dirty? Does it  
>> skip it and reclaim the next dirty block, leaving a "hole"? Or does it  
>> reclaim everything up to a reclaimable block to make the free space  
>> contiguous?
> 
> It is cleaned regardless. Free space appears to always be contiguous.

Hmm, so the GC causes completely unnecessary flash wear. That's really 
bad for the most advantageous use-case of nilfs2. :(

>> 4) Assuming this isn't already how it works, how difficult would it be  
>> to modify the reclaim policy (along with associated book-keeping  
>> requirements) to reclaim blocks in the order of dirtiest-block-first?
>>
>> 5) If a suitable book-keeping bitmap was in place for 4), could this not
(Continue reading)

Permalink | Reply | 2 comments |

Gmane