lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <554A4668.7040804@plexistor.com>
Date:	Wed, 06 May 2015 19:50:48 +0300
From:	Boaz Harrosh <boaz@...xistor.com>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Jens Axboe <axboe@...com>
CC:	Jeff Moyer <jmoyer@...hat.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, adilger@...ger.ca,
	david@...morbit.com
Subject: Re: [PATCH v2] Support for write stream IDs

On 05/06/2015 01:09 AM, Martin K. Petersen wrote:
>>>>>> "Jens" == Jens Axboe <axboe@...com> writes:
<>
> 
> The only sensible solution is for the kernel to manage the stream
> IDs. And for them to be plentiful. The storage device is free to ignore
> them, do LRU or whatever it pleases to manage them if it has an internal
> limit on number of open streams, etc.
> 

Sometimes you do not have control over the "storage device" firmware
and/or it is already too late. But in such a case the LLD of the device
can do the state management (open/close) and translation (LRU).
If there are a lot of broken devices with the same small size that need
an LRU and/or state, bunch of LLDs can reuse a common library.

But hey yes I'm with Martin here. It sounds like a filesystem thing
and not an application thing.

>From the application side we already have the O_TMP hint and other
fadvise hits, but it is more the filesystem policy of what to do
with this.

Also current proposed solution for application is kind of a layering
violation. I set an Id at the filesystem level API: Open a file,
set an ID. But I acquire the ID from the block device under
the FS. This will never map well. In fact it calls for only a very
hard-coded hardware specific application that can use this.

Thanks
Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ