NILFS2 future

Dear folks,

i've now come so far as that i can dump and read the root directory of a 
nilfs2 filesystem. One thing i am wondering of though is the file format 
stability? Are there changes on hand and if so how does the linux nilfs2 
implementation deal with it? Is the kernel code automatically converting 
the discs on write? or is there a transformation program to be provided? 

With regards,
Reinoud

Re: NILFS2 future

Hi!

On Sat, 2 Aug 2008 13:05:25 +0200, Reinoud Zandijk wrote:
> Dear folks,
> 
> i've now come so far as that i can dump and read the root directory of a 
> nilfs2 filesystem. One thing i am wondering of though is the file format 
> stability? Are there changes on hand

NILFS 2.0.0 and the later 2.0.x are the versions to fix bugs or improve
perfomance problems due to immature implementation.
So, I'd like to avoid any changes that impact either backward or forward
compatibility in this series.

However, NILFS2 has many TODOs that may impact on that, such as atime
support, acl/xattr support, redundant super block support, B-tree based
directory implementation, and so forth.
New user requirement, or discussions and development in the kernel community
may also lead to big changes.

For changes like the atime support, NILFS2 can keep the compatibility
because adding metadata files (which are used for checkpoint management or
Disk Address Translation) to NILFS2 is possible. The acl/xattr support might
be possible by using similar scheme.
(Those enhanced version of NILFS2 should be released, I think, with version
 like 2.1.y, 2.2.y ...)

In general, the filesystem that doesn't have compatibility should be
regarded as different filesystem, especially for commonly used
filesystems or those adopted in the mainline kernel.

NILFS on ARM ?

Hi,

I notice there is no obvious support for ARM.
Is NILFS suitable for small devices such as the Openmoko Freerunner? [1]
This device runs linux and has a microsd slot, volumes would typically
be between 512mb to 16gb.

I'm inexperienced with compiling and using these projects, but I think
I may try.
This [2] looks like is might be useful.

Does anyone see any potential problems?

Regards

Matt

[1] http://wiki.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware
[2] http://wiki.openmoko.org/wiki/Toolchain

Re: NILFS on ARM ?

Hi,

  I tested NLFS2.0.0 on Marvell Orion Platform.
  The kernel is kernel-image-2.6.12.6-arm1_OLP.0.1_arm.deb based on Marvell LSP.
  I carried out a load test, it works without a problem.

  But I do not understand whether the controller of flash memory and
NILFS2 go well.

2008/8/4, Matt Joyce <matt.joyce@...>:
> Hi,
>
>  I notice there is no obvious support for ARM.
>  Is NILFS suitable for small devices such as the Openmoko Freerunner? [1]
>  This device runs linux and has a microsd slot, volumes would typically
>  be between 512mb to 16gb.
>
>  I'm inexperienced with compiling and using these projects, but I think
>  I may try.
>  This [2] looks like is might be useful.
>
>  Does anyone see any potential problems?
>
>  Regards
>
>  Matt
>
>  [1] http://wiki.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware
>  [2] http://wiki.openmoko.org/wiki/Toolchain
>  _______________________________________________

NILFS 2.0.4 release

Dear NILFS users,

We have released nilfs-2.0.4, which fixes a pending hangup
problem while deleting very large files (originally reported
by Alexander Schier).

The updated package can be found at:
http://www.nilfs.org/en/download.html

Thanks,
--
Ryusuke Konishi
NILFS team NTT

Nilfs 2.0.3 bugreport

Dear folks,

i've noticed that the DAT file is not always recording its length 
correctly; at times it jumps to zero blocks recorded and is then increased 
again when files are touched. Has anyone seen this before? How do i know 
the size of the DAT file then? just only insert/append unused blocks when 
needed?

With regards,
Reinoud

Re: Nilfs 2.0.3 bugreport

Update:

On Fri, Aug 08, 2008 at 01:17:27PM +0200, Reinoud Zandijk wrote:
> i've noticed that the DAT file is not always recording its length 
> correctly; at times it jumps to zero blocks recorded and is then increased 
> again when files are touched. Has anyone seen this before? How do i know 
> the size of the DAT file then? just only insert/append unused blocks when 
> needed?

I'm not 100% sure its only the DAT file though and not the CP/SU files too. 
Most likely a locking issue?

With regards,
Reinoud

Nilfs 2.0.3 bugreport

Dear folks,

i've noticed that the DAT file is not always recording its length 
correctly; at times it jumps to zero blocks recorded and is then increased 
again when files are touched. Has anyone seen this before? How do i know 
the size of the DAT file then? just only insert/append unused blocks when 
needed?

With regards,
Reinoud

Re: Nilfs 2.0.3 bugreport

Dear Reinoud Zandijk,

On Fri, 8 Aug 2008 13:09:16 +0200, Reinoud Zandijk wrote:
> i've noticed that the DAT file is not always recording its length 
> correctly; at times it jumps to zero blocks recorded and is then increased 
> again when files are touched. Has anyone seen this before?

Sorry for my late reply,
I was almost offline for the last week (and still) on vacation.

The strange behaviour of DAT block count is caused by a bug of 
shadow DAT, a temporary inode used for GC writes;  the shadow DAT
swaps the btree state for the original DAT, but the block count was
not handed over.

Please try the following patch.
it would fix the causal bug, though it doesn't correct the value.
Actually this value is not used for DAT and other meta data files,
but it should be fixed early...

> How do i know the size of the DAT file then? just only insert/append
> unused blocks when needed?

Block count or size?
FYI, in case of size, you can know it in block unit by getting the last
key of bmap.  (nilfs_bmap_last_key() would be of some help).

Best regards,
Ryusuke
---

directory entries

Dear folks,

i wondered why directory lengths are specified in blocksize units resulting 
in the last dirent in the block to fill up the space with its rec_len. 
Searching for free space to enter a directory entry i could use 
rec_len - NILFS_DIR_REC_LEN(last_dir_enty->namelen) as free space indicator 
but i wondered if it might not be a better practice to allow zero-length 
dir entries that are used to fill up the rest of the block with its 
rec_len.

Thoughts?

With regards,
Reinoud

_______________________________________________
users mailing list
users@...
https://www.nilfs.org/mailman/listinfo/users