Ivan Shapovalov | 31 Jul 22:49 2014
Picon

Fwd: reiser4: FITRIM ioctl -- how to grab the space?

(resend -- forgot the Cc:, sorry for spamming)

...and here is volume 2 of my neverending question series :)

A stub ioctl, placed as I described, seems to work and log a warning each time
I invoke `fstrim` on anything mounted.

Now on to space allocation. This seems pretty easy in the first approximation:
reiser4_alloc_blocks_bitmap() seems to do what's needed, finding the nearest
free extent, not the biggest one. So we could just call reiser4_alloc_blocks()
plus reiser4_dealloc_blocks(BA_DEFER) repeatedly, while allocations succeed.

However, I suppose we need to grab all free space before proceeding. There is
no primitive for grabbing all free space, so we need to read block counters,
calculate amount of space to grab and then call reiser4_grab_reserved()
(as we want to allocate everything, including the reserved space. This creates
two problems (as I see it):
- there is a race between reading block counters (under sb spinlock) and
  performing the grab (which takes the spinlock on its own);
- if anything will try to grab space during discarding, it will get an ENOSPC,
  while it's better to make the process wait until discarding is completed.

I'm not sure whether the last problem really exists (there is BA_CAN_COMMIT,
but I don't know whether is it used consistently where possible).

Could you explain these things?

Thanks,
--

-- 
Ivan Shapovalov / intelfx /
(Continue reading)

Ivan Shapovalov | 31 Jul 22:47 2014
Picon

reiser4: FITRIM ioctl -- how to grab the space?

...and here is volume 2 of my neverending question series :)

A stub ioctl, placed as I described, seems to work and log a warning each time
I invoke `fstrim` on anything mounted.

Now on to space allocation. This seems pretty easy in the first approximation:
reiser4_alloc_blocks_bitmap() seems to do what's needed, finding the nearest
free extent, not the biggest one. So we could just call reiser4_alloc_blocks()
plus reiser4_dealloc_blocks(BA_DEFER) repeatedly, while allocations succeed.

However, I suppose we need to grab all free space before proceeding. There is
no primitive for grabbing all free space, so we need to read block counters,
calculate amount of space to grab and then call reiser4_grab_reserved()
(as we want to allocate everything, including the reserved space. This creates
two problems (as I see it):
- there is a race between reading block counters (under sb spinlock) and
  performing the grab (which takes the spinlock on its own);
- if anything will try to grab space during discarding, it will get an ENOSPC,
  while it's better to make the process wait until discarding is completed.

I'm not sure whether the last problem really exists (there is BA_CAN_COMMIT,
but I don't know whether is it used consistently where possible).

Could you explain these things?

Thanks,
--

-- 
Ivan Shapovalov / intelfx /
Ivan Shapovalov | 31 Jul 16:23 2014
Picon

reiser4: FITRIM ioctl -- where to place the handler?

Hi,

I've started to iterate on the batch mode discard implementation for reiser4,
and the first question is -- where to place the ioctl handler?

From what I've been able to understand, we need something like
reiser4_ioctl_dir_common() in plugin/file_ops.c, pointer to which should
become ->{unlocked,compat}_ioctl() of directory_f_ops in plugin/object.c.

However, in this case, what is DIRECTORY_FILE_PLUGIN_ID and corresponding
entry in file_plugins array in plugin/object.c? How is it related to
directories?

I see that its ->{inode,file,as}_ops are empty, so it probably does not
participate in dispatching ioctls, but I'd like to make sure this is the case.

Thanks,
--

-- 
Ivan Shapovalov / intelfx /
Ivan Shapovalov | 31 Jul 12:19 2014
Picon

[PATCHv7 0/6] reiser4: discard support: simplified and race-free initial implementation.

v1: - initial implementation (patches 1, 2)

v2: - cleanup, fixes discovered in debug mode
    - saner logging
    - assertions
    - enablement of discard through mount option

v3: - fixed the extent merge loop in discard_atom()

v4: - squashed fix-ups into the main patch (with exception of reiser4_debug())
    - fixed bug in usage of division ops discovered while building on ARM

v5: - squashed mount option into the main patch
    - refactor based on discussion (see commit msg)
      - splitted off blocknr_list code
      - replaced ->discard_set with ->delete_set and ->aux_delete_set

v6: - actualized in-code comments
    - removed uber-verbose debug statements
    - fixed code-to-patch mapping
    - moved blocknrlist and blocknrset to kmem_cache instead of kmalloc/kfree
      (in a separate commit for ease of reviewing)
    - dropped the RFC label

v7: - squashed with PATCHv2 "perform discard before all deallocations"
    - dropped extent padding from discard_extent()
    - completed in-code comments, cosmetic fixups
    - added missing #include in block_alloc.c
    - added missing spin_unlock_atom() in discard_atom()

(Continue reading)

Noemi Alvarez | 29 Jul 10:23 2014
Picon

Hello


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 reiserfs-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bhikkhu Mettavihari | 26 Jul 10:16 2014
Picon

Formating Reiserfs 3.6 with bad-blocks

Greetings,

I have about 50 x 500GB to 2 TB hard disks in my setup.
All them are using reiserfs 3.6

When I get slow reads on a hard disk then I do:
# badblocks -b 4096 -o bad-blocks-finished-6-2.txt /dev/sdd1

# tail -f bad-blocks-finished-6-2.txt
77299721
77299722

after that I format the hard disk with this command:

mkfs.reiserfs -B /root/bad-blocks-finished-6-2.txt /dev/sdd1

But my hard disk still seems to have problems with reading certain parts.
I notice that the reading speed is going down to a very low level with
some files.

Is my method correct ?
or have I done something incorrect ?

with metta
Mettavihari
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Jose R R | 24 Jul 13:24 2014

Deleting a 5 GB directory in Reiser4 hangs system(s)

Niltze!

I have a couple of root partitions with Debian which recently have
been default-formatted with Reiser4.

I have applied at the very least Mahoney's patch set (<
http://marc.info/?l=reiserfs-devel&r=1&b=201404&w=2 >) followed by
reiser4 for 3.14.1 patch (<
http://sourceforge.net/projects/reiser4/files/reiser4-for-linux-3.x/
>) on kernels 3.14.4 and 3.15.2. Each kernel operates in a different
OS with reiser4 root fs.

Attempting to remove a ~ 5 GB directory recursively (rm -r) the
operation hangs either system.

Has the bug has been reported before? Or is it a feature ;-)

Cheers!

--

-- 
Jose R R
http://www.metztli-it.com
---------------------------------------------------------------------------------------------
NEW Apache OpenOffice 4.1.0! Download for GNU/Linux, Mac OS, Windows.
---------------------------------------------------------------------------------------------
Daylight Saving Time in USA & Canada ends: Sunday, November 02, 2014
---------------------------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Ivan Shapovalov | 21 Jul 20:19 2014
Picon

[PATCHv2 0/3] reiser4: discard support: perform discard before all deallocations.

This applies on top of PATCHv6 of "initial implementation".
The first patch has been already sent some time ago, but I've included it
here for sake of clarity.

v2: fix disk space leak in error path, fix comments and commit messages, etc.

Ivan Shapovalov (3):
  reiser4: fix reiser4_post_{commit,write_back}_hook() and their invocations.
  reiser4: discard support: use reiser4_post_write_back_hook() for discarding and completing deferred deallocations.
  reiser4: discard support: perform discard before all deallocations.

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

Edward Shishkin | 20 Jul 14:47 2014
Picon

[patch 1/1] reiser4: iterate over extents in discard_atom

. add discard_sorted_merged_extents();
. add mount options to specify erase unit and alignment;
. verify and set discard params to the super-block at mount time;
Edward Shishkin | 20 Jul 14:47 2014
Picon

[patch 0/1] reiser4: iterate over extents in discard_atom

In this version we support all erase units (not only ones, which are 
powers of 2).
I put a restriction 1MiB for erase units just to filter possible 
garbage. We can
increase this boundary, if needed.
Alignments with (bdev_discard_alignment() % s_blocksize != 0) are still 
unsupported.

I have added mount options to specify erase unit and alignment in bytes. 
This is
only for debugging purposes (to emulate real situations). Usage is the 
following:

mount /dev/xxx -o discard,discard.unit=yyy,discard.offset=zzz /mnt

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

Bhikkhu Mettavihari | 20 Jul 05:10 2014
Picon

Fwd: Reiserfs 4

Greetings

I am running about 30 ubuntu desktops and servers.
I am a regular reiserfs 3.6 user
These are production machines doing video editing
Our entire production is on Linux
Our entire backup in on Linux servers.
The fs on the backup servers is though ext3 since the guy that did the
server setup was not familiar with riser.

When do you recommend me to upgrade to riser 4

I do not like to upgrade if there is not a stable system, then I would
rather run with 3.6

with metta
Mettavihari
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane